持续交付 2.0
《持續交付 2.0》讀書筆記
軟件工程發展概述
“軟件工程”這一學科出現于 1968 年，當時正值第一次軟件危機。第一次軟件危機是落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一系列嚴重問題的現象。人們試圖借鑒建筑工程領域的工程方法來解決這一問題，以實現“按預算準時交付所需功能的軟件項目"的愿望。
瀑布軟件開發方法
瀑布軟件開發方法是將軟件開發過程定義為多個階段，每個階段均有嚴格的輸入和輸出標準，項目管理者希望通過這種重計劃、重流程、 重文檔的方式來解決軟件危機。很多人將具有以上 3 個特征的軟件開發方法統稱為“重型軟件開發方法”。
敏捷軟件開發方法
敏捷軟件開發方法強調發揮人的主觀能動性，提倡面對面溝通、擁抱變化、通過迭代和增量開發盡早交付有價值的軟件。此時，很多團隊已認識到，軟件開發實際上是一個不斷迭代學習的過程，即軟件工程師需要快速學習并理解領域知識，并將其轉化成數字世界的表達形式，通過與業務專家的交流討論來學習并持續迭代這個過程。一個軟件交付計劃被劃分成多個迭代，強調在每個迭代結束時應該得到可運行的軟件。
與瀑布軟件開發方法只在項目交付后期才能看到可運行的軟件相比，敏捷軟件開發方法在這方面有很大的進步。“持續集成”作為敏捷開發方法中的一個工程實踐，率先被更廣泛的 IT 組織所接受，即便那些沒有采納敏捷開發方法的團隊也會使用它，因為其強調的頻繁自動化構建和自動化測試減少了質量保障團隊的重復工作量，也排除了開發團隊與質量保障團隊之間的溝通障礙。
DevOps 運動
2010 年“The Agile Admin”網站上發表的一篇題為 “What is DevOps”（什么是 DevOps）的文章中指出：“DevOps是一組概念集合的代稱，雖然并非全部都是新概念，但它們已經催化為一種運動，并迅速在整個技術社區中傳播。”
DevOps 是運維工程師和開發工程師參與整個服務生命周期（從設計到開發再到生產支持）的一組實踐。
DevOps 在維基百科上的定義也在隨著時間的推進而不斷變化著。截止到 2017 年，其定義為：DevOps 是一種軟件工程文化和實踐，旨在統一整合軟件開發和軟件運維。
DevOps 運動的主要特點是強烈倡導對構建軟件的所有環節（從集成、測試、發布到部署和基礎架構管理）進行全面的自動化和監控。
DevOps 的目標是縮短開發周期，提高部署頻率和更可靠地發布，與業務目標保持一致。
DevOps 并非一個標準、一種模式或者一套固定方法，而是一種 IT 組織管理的發展趨勢，也就是說，通過多種方式打破 IT 職能部門之間的隔閡，改變 IT 組織內部的原有合作模式，使之更緊密結合，從而促進業務迭代速度更快。 這種發展趨勢將會引起 IT 組織內部原有角色與分工的變化，甚至范圍更大，會影響到相關的業務組織。對互聯網公司來說，其軟件產品對業務發展起到極其關鍵的作用，業務結果與 IT 效能強關聯，因此順應這一發展趨勢的動力更加明顯和迫切。
持續交付 1.0
“持續交付 1.0” 是一種能力，也就是說，能夠以可持續方式，安全快速地把代碼變更（包括特性、配置、缺陷和試驗）部署到生產環境上，讓用戶使用。具體請看 #持續交付 1.0
“持續交付 1.0” 提供的很多原則及方法是 DevOps 運動的具體實操指引，它們可以為企業的 IT 團隊將 DevOps 運動落地實施提供非常具體的指導。
持續交付 2.0
“持續交付 1.0” 關注于“從提交代碼到產品發布”的過程，但是，一些軟件功能在開發完成之后，對用戶或者業務來說，并沒有產生什么影響，有些功能根本沒有用戶來使用。可是，這些功能的確花費了團隊的很多精力才設計實現。這是一種巨大的浪費。這種“無用”的功能生產得越多，浪費就越大。
我們是否可以找到一些方法，讓我們付出的努力對業務改善更加有效，或者只用很少的成本就可以驗證對業務無效呢？
精益思想
《精益創業》的核心理念是開發新產品時，先做出一個簡單的原型 - 最小化可行產品（Minimum Viable Product, MVP ），原型的目標不是馬上產出一個完美的產品，而是為了驗證商業假設，得到用戶反饋后，持續迭代，快速修正。
精益思想是指導企業根據用戶需求，定義企業生產價值，按照價值流來組織全部生產活動，使價值在生產活動之間流動起來，由需求拉動產品的生產，從而識別整個生產過程中不經意間產生的浪費，并消除之。
在精益管理理論中，“浪費”是指從客戶角度出發，對優質產品與良好服務不增加價值的生產活動或管理流程。例如，無效果的功能特性、沒人看的文檔、軟件缺陷、機械性的重復工作等。
盡管“消除所有浪費”幾乎是不可能的，但是，我們仍舊要全面貫徹“識別和消除一切浪費”的理念，持續不斷地優化流程與工作方式，達到高質量、低成本、無風險地快速交付客戶價值的目的。
雙環模型
“持續交付 2.0” 是一種產品研發管理思維框架。它將精益創業與 “持續交付 1.0” 相結合，強調業務與 IT 間的快速閉環，以“精益思想”為指導，全面貫徹“識別和消除一切浪費” 的理念，通過一系列工作原則與實踐，幫助企業以一種可持續方式，高質量、低成本、無風險地快速交付客戶價值。
對企業來說，開發軟件產品的目標是創造客戶價值。因此，我們不應該僅僅關注快速開發軟件功能，同時還應該關注我們所交付的軟件的業務正確性，以及如何以有限的資源快速驗證和解決業務問題。也就是說，不斷探索發現真正要解決的業務問題，提出科學的目標，設計最小可行解決方案。通過快速實現解決方案并從真實反饋中收集數據，以驗證該問題是否得以解決。這是一個從業務問題出發，到業務問題解決的完整業務閉環，簡稱為持續交付 “8” 字環。
它由兩個相連的環組成：第一個環為“探索環”，其主要目標是識別和定義業務問題，并制訂出最小可行解決方案進入第二個環，第二個環為“驗證環”，其主要目標是以最快速度交付最小可行方案，可靠地收集真實反饋，并分析和驗證業務問題的解決效果，以便決定下一步行動。
探索環包含 4 個可持續循環步驟，分別是提問、錨定、共創和精煉。
提問，即定義問題。通過有針對性的提問，找出客戶的具體需求，并找出具體需求后的原因，即具體需求后要解決的根本問題。在提問中形成團隊期望達成的業務目標或者想要解決的業務問題。如果問題無法清晰定義，那么找到的答案自然就會有偏差。因此，在尋找答案之前，應該先清晰地定義問題。
錨定，即定義結果目標指示器。針對問題進行信息收集，經過分析，去除干擾信息，識別問題假設，得到適當的衡量指標項，并用其描述現在的狀況，同時討論并定義我們接下來的行動所期望的結果。
共創，即共同探索和創造解決或驗證該問題的多種具有可行性的解決方案。
精煉，即對所有的可行試驗方案進行選擇，找到最小可行性解決方案，它既可能是單個方案，也可能是多個方案的組合。
驗證環也包含 4 個可持續循環的步驟，分別是構建、運行、監測和決策。
構建：是指根據非數字化描述，將最小可行性解決方案準確地轉換成符合質量要求的軟件包。
運行：是指將達到質量要求的軟件包部署到生產環境或交到用戶手中，并使之為用戶提供服務。
監測：是指收集生產系統中產生的數據，對系統進行監控，確保其正常運行。同時將業務數據以適當的形式及時呈現出來。
決策：是指將收集到的數據信息與探索環得出的對應目標進行對比分析，做出決策，確定下一步的方向。
探索環就像是一部車子的前輪，把握前進方向。驗證環則像車子的后輪，使車子平穩且驅動快速前進。它們之間相互促進，探索環產生的可行性方案規模越小，越能夠提高驗證環的運轉速度，如果價值驗證環能夠提高運轉速度，則有利于探索環盡早得到真實反饋，有利于快速決策，及時對前進方向進行驗證或調整。
4 個核心原則
“持續交付 2.0” 是指企業能夠以可持續發展的方式，在高質量、低成本及無風險的前提下，不斷縮短持續交付 “8” 字環周期，從而與企業外部頻繁互動，獲得及時且真實的反饋，最終創造更多客戶價值的能力。
下面逐一介紹縮短持續交付 “8” 字環周期的 4 個核心工作原則：
堅持少做 - 無論公司實力如何，想做的事情永遠超過自己的交付能力，需求永遠做不完。然而，做得多就一定有效嗎？我們應該抵住“通過大量計劃來構建最佳功能”的誘惑，堅持少做，想辦法對新創意盡早驗證。
持續分解問題 - 復雜的業務問題中一定會包含很多不確定因素，它們會影響問題解決的速度和質量。在實施解決方案之前，通過對問題的層層分解，可以讓團隊更了解業務，更早識別出風險。企業應該堅信，即便是很大的課題或者大范圍的變更，也可以將其分解為一系列小變更，快速解決，并得到反饋，從而盡早消除風險。與其設計一大堆特性，再策劃一個持續數月的一次性發布，不如持續不斷地嘗試新想法，并各自獨立發布給用戶。
堅持快速反饋 - 當把問題分解以后，如果我們仍舊只是一味地埋頭苦干，而忽視對每項已完成工作的結果反饋，那么就失去了由問題分解帶來的另一半收益，確認風險降低或解除。只有通過快速反饋，我們才能盡早了解所完成工作的質量和效果。
持續改進并衡量 - 無論做了什么樣的改進，如果無法以某種方式衡量它的結果，就無法證明真的得到了改進。在著手解決每個問題之前，我們都要找到適當的衡量方式，并將其與對應的功能需求放在同等重要的位置上，一起完成。
持續交付七巧板
討論了 “持續交付2.0” 的指導思想、工作理念和核心原則。大家很容易意識到，它對適應快速變化的市場環境和激烈的市場競爭是非常有效的。那么，企業如何讓“持續交付 2.0”成為一種組織能力，成為組織的 DNA，持續發揮作用，從而領先競爭對手，成為自己的一種競爭優勢呢？
持續交付雙環模型的實施與改進將涉及企業內的多個部門與不同的角色，無法由某個部門獨立實施，必須在整個組織范圍內貫徹執行 “持續交付 2.0” 的思想、理念與原則。
企業需要在組織管理機制、基礎設施以及軟件系統架構 3 個方面付諸行動，而每一個方面都包含多項內容，如下圖。
每個企業的實施路徑可能各不相同，所需要的周期也各有長短，對各方面的能力需求也不完全一致。正如中國傳統玩具七巧板一樣，每個企業都應根據自己的意愿和訴求，拼出屬于自己的持續交付實踐地圖。
小結
“持續交付 2.0” 建立在 “持續交付 1.0” 的“可持續地快速發布軟件服務”及精益創業的"最小化可行產品”兩種理念基礎之上，強調要以業務為導向，從一開始就將業務問題進行分解，并通過不斷的科學探索與快速驗證，減少浪費的同時，快速找到正確的業務前進方向，簡稱為“雙環模型”。因此，其涉及組織中的多個團隊，需要各個團隊之間緊密合作，才能縮短 “8” 字環的周期。
“持續交付 2.0” 的 4 個核心工作原則是堅持少做、持續分解問題、堅持快速反饋和持續改進并衡量。只有這樣，才能不斷縮短持續交付 “8” 字環的運行周期，提升用戶反饋速度，從而提高業務的敏捷性。這要求管理者跳出原有軟件交付管理思維模式，擺脫“害怕失敗”的恐懼感，擁抱“科學探索-快速驗證”思維方法，快速試錯，提升持續交付能力，進而發展現有業務，并快速開創新業務。
推薦閱讀
#持續交付 1.0
加入讀者圈子
總結
- 上一篇： 全球使命系列诚意之作《全球使命VR》即将
- 下一篇： instagram动态网页图片内容爬取（