幾年前看過《持續交付(發布可靠軟件的系統方法)》，感觸不是很深，最近看了這本書的譯者喬梁編寫的《持續交付2.0》，結合工作中的種種，又有一種相見恨晚的感覺。可見好書是需要經常翻閱的，每次都會帶來新的收獲和思考。

全書圍繞著雙環模型展開，介紹了持續交付，快速實現客戶業務價值的一系列的方法論和實踐工具。本文將結合實際工作中遇到的問題來談談這些方法論和工具。

雙環模型

• 第一個環被稱為探索環，主要就是搞清楚客戶背后真實的業務目的，不只是要實現什么，怎么實現，而是要了解背后真正的原因，才能給出更合理的解決方案，通過溝通討論出一個最小的可驗證方案，以便能快速驗證可行性，探索環也是持續交付2.0中新增的一個環

• 第二個環被稱為驗證環，驗證環的主要工作內容就是以最可靠的質量和最快的速度，將最小可行性解決方案從描述性語言轉換成可運行的軟件包，并將其部署到生產環境中運行。

信息偏差

即便是再熟悉，再有默契的人，溝通同一個事物的時候也會產生理解上的偏差。我覺得在探索環中需要做到信息的一致性，即便不能完全一致，后面的驗證環也能快速出成果給客戶確認，因為足夠小，可以及時地調整方向，把風險降到最低。

信息偏差不止是客戶和我們之間，在團隊內部也經常會出現，我們在安排任務時不管是口頭描述還是有詳細的文檔，總會出現結果和期望有偏差的情況。樊登講過的日本企業交代任務的方式我覺得可以嘗試一下：

• 1、交代清楚事項

• 2、讓員工復述一遍（有的軟件公司成為反向交底）

• 3、和員工討論做此事的目的

• 4、讓員工考慮有沒有什么風險

• 5、要求員工提出個人見解

看似很麻煩，但可以確保雙方的想法能達到一致，減少后續返工的風險，其實就是磨刀不誤砍柴工。

開發軟件的目的是創造客戶價值，所以，我們不應該僅僅關注快速開發軟件功能，還應該關注我們所交付的軟件的功能正確性。

流水線工作方式

雙環中有很多的步驟，每個步驟環環相扣，從探索環業務需求的輸入到驗證環產出可以運行到成果，這是一個閉環，這個閉環的周期越短風險就會越小。從輸入到輸出，整個流程像流水線一樣運轉時，效率是最高的。就像敏捷中的看板文化一樣，隨著時間的推移，一個個的用戶故事從最左邊逐步移動到最右邊。如果中間某個環境出現堆積或者斷層，都說明可能出現問題了，需要停下來解決。

最近一個項目中需要做數據遷移，由于數據量和遷移的范圍非常大，項目經理召集了公司很多其他項目組成員進行協助，項目經理按照自己熟悉的技術規劃了遷移方式，學習成本比較高，對于初級開發或測試人員來說，短時間內很難上手，導致進度緩慢。

后來我們領導提出了更合理的方式，就是將遷移任務根據技術的難易程度分解成了幾個大的步驟，各種水平的人都有事可做，并可以很快上手，最終高效完成了任務，這就是流水線效率的體現。

聚焦

書中講到了四大原則：

• 堅持少做

• 持續分解問題

• 堅持快速反饋

• 持續改進并衡量

四個原則概括下就是要「聚焦」，特別是在時間緊任務重的情況下，更是要聚焦，只有聚焦了，雙環模型的周期才會縮短。

案例一

最近團隊有幾個同事在開發一個獨立的類郵件模塊，功能涉及到收發郵件、刪除郵件、收藏等功能。客戶第一階段關注的是，先要有這樣一個功能模塊，功能可以后面完善。聚焦的做法就是，快速完成郵件的收發功能，在交付期前有多的時間再完善刪除郵件、收藏等功能。到了交付期，刪除和收藏功能沒有完成，不影響我收發功能的發布。

如果一開始將收發、收藏、刪除等同時并行在做，可能到了最后時間，每個功能點都完成了一部分，但卻不能交付客戶。

案例二

我們開發的產品是一個功能強大的快速搭建平臺，最近一客戶使用我們平臺來搭建業務功能，上線時間非常緊迫，這時就應該聚焦有哪些必須（阻礙業務）的功能目前還不能實現，利用探索環提交到產品團隊，討論出最小可行解決方案，然后在驗證環快速出成果交付客戶驗證。

這時如果客戶關注點在平臺的非核心功能（主業務無關），提出各種優化需求和新增需求，這樣就本末倒置了，最終上線會有極大的風險。

安燈（Andon）系統

「Andon」是一個信號燈，豐田公司要求員工，在生產流水線上遇到麻煩，都可以拉這個信號燈，生產線會立即停下來，直到問題解決，流水線才恢復運行，不讓問題流到下一個環節。

安燈系統最重要的是讓每一個員工都有質量意識，軟件開發團隊的中的成員往往就缺少這種意識，為了能早點完成任務，常常忘記完成這些任務的最終目的。

在這里分享一個小故事：

說有一人在路邊看見地里有兩人，一個人在前面挖坑，后面的人又用土把挖的坑埋上，由于好奇和不解，上前詢問，兩人回答，他們在種樹，只不過負責放樹苗的人今天請假沒來。

從本職工作來說兩人都完成的挺好，但沒有價值。仔細想想一想，我們有時候是不是就像上面挖坑的人或是填坑的人一樣？所以團隊的每個人都應該為結果負責，都要能在適當的時候勇敢地拉下這個信號燈。

工具

持續交付在實踐過程中離不開自動化工具，大體可以分為自動化構建和自動化測試。

自動化構建

不同大小的公司，或者處于不同階段的團隊，會采取不同的工具，適合自己的才是最好的，之前寫過的幾篇文章可以給大家參考：

1、GitLab 配合 Jenkins 打造自動化部署
2、在團隊中使用 Gitlab 中的 Merge Request 工作模式
3、在 CentOS7 中安裝 GitLab
4、敏捷下的需求和代碼分支管理
5、不斷進化的分支和需求管理

在上面的文章中有介紹我們是采用 GitLab 的 Merge Request 模式，對應到書中的分支策略，就是是主干開發，主干發布，因為每一個 Merge Request 分支的周期非常短，最終還是合并到主分支進行構建發布。但這種方式有一個問題，當同時并行任務過多時，合并時容易混亂。后面會嘗試主干開發，分支發布的方式。

自動化測試

自動化測試大體可以分為單元測試和端到端測試，單元測試對開發人員的要求比較高，要保證持續交付高質量的產品，單元測試非常重要，我們現在也在規劃和完善。

端到端測試目前已經在使用中，在之前的文章《端到端測試實踐：Jenkins 集成TestCafe 》有所介紹。

總結

持續集成2.0這本書中有很多的干貨，本文我只是找了幾個我認為比較重要的點進行了描述，總之就一個目的，我們要快速地、正確地、高質量地把任務完成，并交付客戶。

總結

以上是生活随笔為你收集整理的读《持续交付2.0》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。