本文從開發流程角度分析了持續交付的實現，開發人員的溝通問題會拖延發布日期，必須客觀地觀察，才能了解成員之間的問題和流程缺陷，可視化的系統有助於找到問題所在，並在最短時間內解決，使用工具或系統管理工作數據是有效提高效率的方式之一。
如今，許多企業組織都在實施持續交付的做法。但想要提高持續交付的效率，很多時候會覺得是在構建自動化測試和環境部署的時候出了問題，不過我們認為還有其他因素導致我們發布軟件版本時有些壓力和阻礙，只是不確定問題是什么。
我們開始觀察每一個軟件版本發布過程並記錄下看到的內容。例如，完成流程的每個步驟所花費的時間，是人為手動還是自動化發布，參與項目協作的人數有多少，以及發現導致新版本延遲發布的問題。一旦我們有足夠的數據，我們就可以開始分析它並尋找解決方式，這些會成為我們要解決的最重要的問題。
在觀察時保持客觀是很重要的，不要讓自己的偏見掩蓋實際發生的事實，特別是在嘗試改進項目流程和系統時非常有價值。
為什么要專注於改善我們的發布流程
原因是顯而易見的，在軟件版本發布時常常不像我們預計的那樣順暢，既不能無阻礙又無法實現頻繁發布，從而影響了我們的交付能力。
在改進的過程中，能與技術專家共同合作能更快優化發布流程。與專家合作的好處在於他們尊重數據和事實，並且也非常熱衷於讓事情變得更好。同時上文提到的收集了大量數據，就可以顯示出我們的問題，這意味着我們專注於解決實際問題而不是假設。例如，數據顯示我們在測試分段環境中部署的插件比我們想象的要少得多，因此我們就可以輕而易舉地處理這個阻止我們輕松部署的問題。
穩定發布不代表所有東西都必須在現在發布
如果某些改進真的非常重要，那在最快的時間內發布是不可置疑的。問題在於，當我們想要選擇本周的候選版本時，由於各種原因，團隊認為需要包含最后一分鍾的“緊急”更改。這意味着推遲選擇發布候選版本以及對發布周期的連鎖效應，或者工作必須加班加點，即便趕在最后發布了，有時也會影響版本質量。
我們開始有這樣的疑問，“為什么它必須在這個版本中出去？”，“如果我們本周不發布更改會怎么樣？”或“它能等到下一個版本嗎？”。要獲取答案其實非常困難，因為對於團隊來說開發已經是一個壓力很大的情況，這些疑問的提出會被視作阻止他們進行更改。但事實上，當我們試圖頻繁地發布更改，更新迭代時，但其實是可以等待下一周時，它確實是違反了原則。因為我們會忘記了一點，軟件版本發布的關鍵是穩定。
通過討論並提出這些問題，我們意識到有些變化根本不緊急，因此不需要趕工。這樣做的好處是我們的版本更加順暢，需要修復錯誤的程序更少了，顯然發布的壓力也減少了，然后我們可以更專注於如何進行周期性規律地發布。
使用數據來識別問題和改變習慣
改變習慣是很難，因為習慣是長期這樣做的結果，但你必須努力停止舊習慣並用新習慣取而代之。選擇合適的時機發布可以突出發現我們的發布周期中的問題，並有助於解決修復問題。
我們可以嘗試一些方法來幫助我們養成良好的習慣。例如，如果參與發布過程的人員將發送電子郵件作為主要通信方法的話，那一般會有數小時的延遲。必須了解到，在收件人閱讀並理解電子郵件之前，發件人其實還沒有傳達任何信息。如果收件人正在開會，或者每天只會定期檢查電子郵件，那么可能會延遲更久才能看到它。
為了改變這種電子郵件習慣，我們引入了一段時間的“物理提示”。在公眾區域設立一個項目展示板，在上面寫了候選版本號，每個人都可以補充和查看，信息會像漣漪一樣擴散到所有人。那你就會知道整個發布周期里你的任務，以及目前的各任務進度。這也會激勵你趕緊去做任何你應該做的事情，這也有助於推動版本發布流程。
展示板有另一個好處，讓人們面對面交談，相互了解並開始感覺像一個團隊。它幫助我們降低了因溝通不暢導致的流程拖延的風險，使我們團隊合作，並幫助我們形成了更好的溝通習慣。
總而言之，通過更有用的習慣來取代無效的習慣，展示板只是其中一個例子，你可以找到更多適合的“好習慣”。同時，一旦找到好習慣，那么就會形成行為雪球，在滾動中不斷地變大，你甚至可以在這個好習慣的基礎上再進行優化。如果你想了解更多，我強烈推薦可以在網上搜索 Helen Lisowski 的“Good of Good（Agile）Habits”研討會。
應用科學思維方式來理解問題
當我第一次開始觀察發布時，為了改進它們，我們可能不知道如何理解問題。這時候與經驗豐富的敏捷專家，精益和系統思想家合作的好處就顯現出來了。事實證明，我的整個觀察，收集數據和分析的方法，都應用科學思維方式來理解問題的話會事半功倍。
如何應用科學的思維方式來理解問題，包括你認為接下來會發生什么，並根據實際發生的事情調整你的后續步驟。它有四個主要步驟：
第1步：
設定你的此次發布的目的和內容，有哪些是挑戰，有哪些是日常。對我們來說，大部分會是按需發布，但這並不意味着我們每分鍾都會發布，我們可以需要找到一種順暢無bug的方式發布我們想要的改進。
第2步：
了解項目當前的開發進度和發布狀況。這就是收集和分析的數據的來源，我們基本上有一個電子表格形式的價值流程圖。
第3步：
建立階段性的小目標，即您的第一個里程碑。從你當前的狀態到你的最終目標往往是一個太大的跳躍，為了取得進展，確定一個更容易實現的中間目標是有幫助的。比如對我們來說，可以將發布周期從15天減少到10天，而不是直接把目標定在3天。
第4步：
確定並執行以達到目的。這是同樣需要數據分析，數據向我們展示了我們最大的問題是等待發布的隊列時間過長。隊列是“死”時間，在此期間沒有任何事情發生，我們只是在等待下一個過程發生。所以我們就可以將第一個改進重點放在減少或消除隊列時間上。
通過上面描述知道我們要通過科學思維方式來實現改變，這里有一個例子，我們嘗試將一個環境插件自動化安裝到我們的測試板塊。這聽起來像是一個自動化過程，但是經過判斷后，我們認為它是破壞的構建，主要原因是只支持手動進行部署，那么手動部署讓工作的效率降低，結合數據分析，手動部署會讓開發人員分心，導致發布進度被延遲。所以為了自動化流程 ，那必須延遲或者放棄這個環境插件的安裝。
目前運用工具來實現自動化進程是最快提升測試效率的一種辦法，市面上也有很多能實現自動化測試功能的工具或者平台，國內有 EOLINKER，國外有POSTMAN 等等。所以對於在國內的環境，運用好的自動化工具，能幫你更好地實現項目運轉，提高開發測試效率。有興趣的點擊了解 EOLINKER。
改善版本的非技術方面的好處
顯而易見的好處是縮短了周期時間。周期為10天，我們兩周內不能發布超過一次。在進行了幾次執行之后，當然我們不會滿足，繼續優化自動化交付，往后再減少一半，直到可以在一天內發布。
其他一些重要的好處包括：
- 更好的溝通和工作關系
- 自動部署到測試暫存環境意味着團隊可以更快地完成測試，從而減少周期時間和反饋循環
- 改善我們糟糕的自動化測試
- 將發布的成本從15天減少到1天，減少到1人等
- 發布后需要修復缺陷的補丁較少
總結
- 可視化的系統和數據有助於找到問題所在，並在最短時間內解決
- 當試圖說服管理層將時間和資源投入項目時，客觀數據和分析圖表非常有用
- 放式辦公室並不意味着他們溝通良好，設立展示板之類的辦法可以促進團隊合作
當對持續交付復盤時，很容易只關注持續交付的技術部分，畢竟，這是大多數人和開發資源所關注的地方。但是，也請查看整個發布周期，根據在項目自動化的流程和所需時間，找到在此期間其他非技術因素阻礙了發布。了解發布周期流程中的所有步驟，找到問題並改進，再確保團隊的溝通方法有效並合作，才能有助於實現持續交付。
參考資料：Sylvia MacDonald,Continuous Delivery - It’s Not All about Tech!
地址：https://www.infoq.com/articles/continuous-delivery-not-about-tech/