持续交付2.0(一至三章)
讀喬梁先生《持續交付2.0》摘要,前三章持續交付、價值探索環、快速驗證環。
一、持續交付2.0
1.1 軟件工程發展
1、瀑布軟件開發
傳統的瀑布軟件開發模型每個階段都花費屬于的實際那,需要花費大量的經歷確定需求的范圍,審核繁雜的需求規格說明書,確定需求范圍復雜。
2、敏捷軟件開發
提倡面對面溝通,擁抱變化,提倡通過迭代和增量開發今早交付有價值的軟件,軟件開發實際是一個不斷迭代學習的階段。
- 瀑布只有在項目交付后期才可以看到軟件的實際運行。
- 敏捷開發采用迭代模型,但是軟件發布之間的間隔較長。需求變更&研發效率是主要矛盾,部署發布&運維矛盾較小。
3、DevOps發展
DevOps目前沒有統一的定義,正如每個人理解敏捷是不一樣的。目標是縮短開發周期,提高部署頻率和剛可靠的發布,與業務目標一致。
4、持續交付1.0
部署流水線:
組織角色觸達:
5、持續交付與持續部署。部署是技術領域的,交付是業務決策。交付可理解為上線、發布,部署可能有多次,而在業務需要時,才會交付。
1.2 持續交付2.0
1、精益思想
《精益創業》線產生最小化的可行性產品,而非玩么牛的產品,在經過快速迭代與持續修正,資源耗盡前實現市場需求。
- 精益創業是“開發–測量–認知”的驗證學習過程。
- 按照價值流來組織全部生產活動是價值在生產活動之間流動,需求拉動產品的生產,識別生產過程中不經意間的浪費產生。
- 業務生產活動分為增加價值的活動和不增加價值的活動,后者歸為“浪費”活動中,浪費活動分為必要的增值活動和純粹的浪費。{有價值,無價值[必要浪費,不必要浪費]}。EG:流水線上的裝配工作是增值活動,質量檢查是非增值活動,因材料不足而生產等待和質量缺陷的返工都是不必要的浪費。
2、雙環模型【★】
產品研發管理思維框架,是產品與研發的快速閉環,以“精益思想”為指導,全面貫徹“識別和消除一切浪費”的理念。有可持續方式、高質量、低成本、無風險的快速交付客戶價值。
”8“字環,第一個為**“探索環”,目標為識別和定義業務問題,制定最小可行解決方案;第二個為“驗證環”**,目標為一最快速度交付最小可行環,可靠的收集真實反饋,并分析和驗證業務問題的解決效果。,以確定下一步的行動。
探索環:
驗證環:
3、四個核心原則:
二、價值探索環
2.1 探索環的意義
1、探索環的目標與價值假設
就是持續事變和定義這些有價值的假設,選擇并驗證其中風險最高的或者最易驗證的價值假設,并截止價值驗證環得到數據反饋,以便深入理解用戶需求,把我業務前進方向。假設來源:
EG:持續交付工具GoDC,設計200多個功能特性,一半都廢棄掉,說明假設的不成立。該產品實際一直秉承“持續交付2.0”,調整功能策略,實現成功。
2.2 探索環的四個關鍵
1、提問
不斷提問,澄清客戶需求背后真正要實現的目標。
EG:舉辦DevOps的沙龍,客戶要咖啡。問了一堆要什么口味的咖啡、多熱的咖啡、什么時間、中杯大杯。
其實問的都是“做什么”和“怎么做”,而沒有去問及原因。客戶真正的訴求是擔心困意而錯過聽講。此時,我們的解決方案有多種,比如錄制視頻,即使參與者中途離場,也可以回顧內容。
2、錨定
避免模糊不清的目標,這樣會影響團隊的交流。清晰的描述目標讓我們知道自己當前的位置,清晰的目標是具體且可衡量的,有時間限定。若沒有時間限定,則將會成為一個愿景,無法直接知道企業日常生產管理的活動。
EG:某App用戶量當前為20萬,年底愿景為200萬。
所以我們可以根據新聞信息流服務(Feed流),我們期望用戶喜歡該App,那么可以推斷:
根據分析可以得出三個衡量指標:推薦朋友數、單位時間內的用戶數、單個用戶的平均使用時長。制定指標后,各個團隊根據自身職責制定目標如:提高API的請求響應速度、后臺穩定性等等。
目標選擇應該尊新:
3、共創
解決方案基于假定條件或者猜想,提供兩種分析方法:
量化式影響地圖(目標–角色–影響–方案–量化、Why-Who-How-What)。
EG:以20萬到200萬為例。涉及到的角色有App使用者、推廣渠道、客服團隊、產品研發和運營、內容提供商及更多角色。
以推廣渠道商為例
- 影響:App的展示位置、App的曝光量、App審核速度
- 方案:購買展位、搜索優化、規范更新
- 量化:App的下載指標
用戶陸行地圖(可視化的方式,講用戶與產品或服務之間的活動按照業務流進行展示)
- 地圖包含:用戶接觸點、接觸階段、用戶痛點、用戶情緒
- 制作步驟:定義用戶、定義任務或階段、用戶與服務接觸點的互動行為、用戶的動機、用戶心理
共創的兩周
共創的兩個陷阱、極端:分析癱瘓(過度分析,無法決策)、直覺決策(匆忙判斷,直覺反應)
4、精煉
篩選最小可行性方案。
2.3 工作原則
1、分解快速驗試錯
與“一次到位式”的解決方式不同。采用低成本的快速驗證,多次嘗試,多種方法,多種成功方式。
2、一次只驗證一點
驗證方案只是手段,非目標。
3、允許失敗
2.4、共創和精煉常用方法
1、裝飾窗方法
EG:提現的功能,產品為評估到實現周期較長,則可以線用一個虛假的按鈕,如用戶點擊“提現”時,提示“功能未實現,請預留手機信息,實現后第一時間提心您”,從而收集用戶點擊意愿,快速收集用戶反饋,決定是否做該功能。
2、最小可行特性法
EG:還是提現的功能,可以提示“功能開通成功”,后臺收集用戶信息,通過人工財務方式,實現該功能,并不涉及到系統的開發。用來短時間內收集用戶意愿,驗證用戶是否喜歡該功能。
3、特區法
制定用戶范圍內進行試驗,驗證某個功能是否有效,不會影響特區意外的用戶體驗。一般用于資源有限、成本敏感的場景。
EG:還是提現的功能,按照裝飾窗方法,若120個用戶提交手機信息,功能實現后,可以根據120用戶手機號發送短信,包含提現的連接,查看用戶點擊該鏈接完成提現的人數(如:33個商戶提現成功,7個商戶提現1次,1個商戶提現8次)。
4、定向探索法
是指某種特定行為的特定用戶群體,依據改用戶的具體行為模式,設計調查提綱,針對性探索其背后的動機。根據特區法的不同商戶提現結果,分別設計調查問卷,理解用戶行為。
5、稻草人法
與裝飾窗方法的區別是不開發任何真實功能,假裝該功能已經實現。采用人工或其他方式,模擬實現,獲得用戶反饋。
6、最小可行產品法
通常在產品0-1的過程中使用。如Zappos最早就是開發一個UI界面,然后用戶下單后,手工發貨。
三、快速驗證環
3.1 驗證環的目標
借助各種方法和工具,讓質量可靠的解決方案以最快的速度達到客戶手中,收集分析真實的反饋。
3.2 驗證環的四個關鍵
1、構建:講自然語言描述轉換為計算機可以執行的軟件。
- “時間盒”管理法。涉及交付物、交付質量、截止時間,了解項目狀態,風險并解決。
- 任務分解。持續交付2.0核心工作原則,包含需求拆分和開發任務拆分。
- 持續驗證。每當完成意一項開發任務或者需求,立即對交付質量進行驗證,而非多項交付一起驗證。持續驗證會耗費較高成本,可以采用“持續集成”或者“自動化測試”方式,降低回歸成本。
2、運行:將軟件包部署生產環境,并對外提供服務。
- 如何無感的升級版本是重要課題,主要矛盾在開發和運維之間。
3、監控:收集數據源并統計展示,及時發現生產問題和業務指標異常的數據。
4、決策:收集真實的業務數據反饋結果之后,根據探索環中確定的相應指標進行分析對比,驗證是否符合最初預期。
3.3 工作原則
包含:質量內建、消除等待、盡量并行、檢測一切。
1、質量內建。從生產過程的第一個環節開始,就注重產出物的質量,并在每個環節開展質量保證。與后期大規模檢查概念完全相反。
2、消除等待。精益思想中關于“浪費”有定義,“等待”的本質就是非必要浪費。正確做法是擴大“瓶頸”的處理能力,本質解決為需求顆粒均勻化,構建各環節工作量相近的需求。 同時進行任務的自動化建設。
3、重復任務自動化。如測試環境搭建、回歸測試、應用發布和部署,都可以通過優化流程和自動化措施降低事物性成本和人為造成的失誤。
4、檢測一切。檢測收集數據,便于確認生產環境軟件正常運行(應用健康檢測),也便于收集有效業務數據,驗證探索環的假設(業務健康假設)。
總結
以上是生活随笔為你收集整理的持续交付2.0(一至三章)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: redis主从、哨兵、集群概念
- 下一篇: AHU算法课-DP动态规划