本文要點：
- 持續交付是現代軟件開發的標準技術。但是，持續交付的指標測量還不是很流行的做法。
- Steve Smith在《衡量持續交付》中引入的持續交付指標，可用來從穩定性和速度方面衡量持續交付的表現。
- 將持續交付指標引入開發團隊後，就可以針對部署管道思考新的改進方案，因爲實體組裝團隊的價值流需要針對穩定性和速度來做優化。
- 持續交付指標提供了一個開發流程優化框架，開發團隊可以在其中設置穩定性和速度目標，並跟蹤進度。
- 在開發團隊中引入持續交付指標需要搭配一個近實時的工具，用來透明地執行原始數據收集和指標計算的任務。
數據驅動決策系列文章概述了數據驅動決策如何支持軟件交付中的三大活動——產品管理、開發和運營。
簡介
軟件產品交付組織需要愈加頻繁地交付複雜的軟件系統。軟件交付工作涉及的主要活動包括產品管理、開發和運營（這裏我們的確指的是活動，而不是在談各個部門，後者是我們不推薦的說法）。在每項活動中，都必須快速做出許多決定以推進交付。在產品管理中，決策主要涉及功能優先級。在開發中，它關聯的是開發流程的效率。在運營中，它主要針對的是可靠性。
可以根據團隊成員的經驗來做出決策。另外可以基於數據做出決策。這將帶來更加客觀和透明的決策流程。尤其是隨着交付速度的提升和交付團隊數量的增加，保持透明的組織就能讓所有人無需耗時的同步會議，也可以一直走在同樣的軌道上。
在本文中，我們探討了持續交付指標中的數據如何支持開發工作中的活動，以及如何將這些數據用於快速的數據驅動決策。反過來，這會提高產品開發組織的透明度並削弱其官僚風氣，最終就能取得更好的業務成果，例如用戶對軟件更高的參與度和更高的應計收益等。
我們報告了持續交付指標在西門子醫療公司開發活動中的應用案例，這是一個由分佈於三個國家的16個軟件交付團隊組成的大型分佈式軟件交付組織。
流程指標，而非人員KPI
爲了以數據驅動的方式引導開發活動，我們需要一種使用數據來表達開發工作中主要活動的方式。這種數據需要被視爲正在發生的事情的流程指標，而不是用於員工評估的人員關鍵績效指標（KPI）。這是很重要的，因爲如果這種指標被用於員工評估，那麼員工可能傾向於以對自己有利的方式來調整要評估的數據。
重點在於，產品交付組織的領導者要將這種數據視爲流程指標，而不是評估員工KPI的方法，以實現穩定的數據質量和數據評估過程。
持續交付指標
開發工作中的主要活動是構建產品。在這種環境下，一旦知道了要構建什麼產品，開發活動中的一個核心問題就變成了“如何高效地製造產品？”
通過分析軟件開發團隊的價值流，可以衡量開發流程的效率。價值流具體來說就是代碼→構建→部署，可以在團隊的部署管道上看到。
價值流中價值流動的速度是可測量的。同樣，也可以測量價值流的穩定性。所謂的穩定性和速度這兩大持續交付指標做的就是這些事情。這些指標是在Steve Smith的《測量持續交付》中定義的。
藉助穩定性和速度這兩大持續交付指標，團隊就可以對自己的價值流和對應的瓶頸一目瞭然。他們可以找到最大的瓶頸並投入時間來消除它（與約束理論相一致）。
穩定性持續交付指標分爲構建穩定性和部署穩定性。速度的持續交付指標分爲代碼吞吐量、構建吞吐量和部署吞吐量。（注意：Steve Smith將速度定義爲變更的前置時間和變更間隔時間的組合。這是對Nicole Forsegren、Jezz Humble和Gene Kim在《加速》中只關注前置時間的定義的擴展。）應該爲每個團隊的部署管道持續生成所有指標，從而可視化團隊的價值流。
構建穩定性指標包括構建失敗率和構建失敗恢復時間。
部署穩定性指標包括部署失敗率和部署失敗恢復時間。
代碼吞吐量指標包括主分支提交前置時間和主分支代碼提交頻率。
構建吞吐量指標包括構建前置時間和構建頻率。
部署吞吐量指標包括部署前置時間和部署頻率。
所有這些指標都是越低越好（也就是更好的交付效率）。
構建穩定性指標：
- 構建失敗率越低越好。
- 構建故障恢復時間越低越好。
部署穩定性指標：
- 部署失敗率越低越好。
- 部署失敗恢復時間越低越好。
代碼吞吐量指標：
- 主分支提交前置時間越低越好。
- 主分支代碼提交頻率越高越好（但以兩次成功提交之間的間隔來衡量，則間隔越小越好）。
構建吞吐量指標：
- 構建前置時間越低越好。
- 構建頻率越高越好（以兩次成功構建之間的間隔來衡量，則間隔越小越好）。
部署吞吐量指標：
- 部署前置時間越低越好。
- 部署頻率越高越好（以兩次成功部署之間的間隔來衡量，則間隔越小越好）。
這樣以來，在圖表上繪製持續交付指標時，就很容易將良好的行爲與瓶頸區分開來。在圖上接近X軸的位置代表良好的行爲。圖上較高的值都代表了團隊價值流中的瓶頸。
也就是說，在顯示持續交付指標的圖表的幫助下，開發團隊就可以輕鬆發現自身開發/測試/部署流程中的瓶頸，並制定數據驅動的優先級決策，以決定在哪些方面進行技術改進以提升開發/測試/部署流程的效率。。
使用持續交付指標來優化自身開發/測試/部署流程的團隊，會精心選擇最有用的領域進行技術改進投資，例如測試自動化、部署自動化、TDD流程改進和BDD流程改進等。不使用持續交付指標的團隊可能不會投資改進自身的開發流程，或者只在發生重大故障後才進行投資，或者會根據團隊中主要人員的意見來進行投資。
啓用指標
在定義了持續交付指標之後，我們很清楚，只有在可以向團隊提供足夠支持的情況下，將其引入由16個開發團隊組成的組織中才是有意義的。
我們開發了一款內部專屬工具，可幫助開發團隊輕鬆地查看自身價值流中的瓶頸。
該工具可以使用團隊部署管道內的代碼存儲庫、持續集成構建代理和部署環境中可用的信息來可視化團隊的價值流。我們從Azure DevOps服務（例如Azure，Repos和Azure Pipelines）查詢所有這些信息。我們改變了Azure DevOps默認的30天存儲設置，改爲保留365天的歷史記錄。
軟件交付團隊的目標是擁有穩定和快速的價值流。基於此，該工具將價值流分爲兩部分顯示：價值流穩定性（在左側）和價值流速度（在右側）。
除了價值流可視化之外，該工具還可以自動執行價值流分析。它可以單獨檢測出價值流的穩定性和速度指標中的最大瓶頸，並以紅色顯示。這樣，團隊就可以立即集中精力解決瓶頸，而無需瞭解其他那麼多的可用數據。
此外，該工具還能自動生成緩解瓶頸的建議。這些建議能夠幫助團隊解決價值流的穩定性和速度方面的最大瓶頸。
除了解決瓶頸的自動化建議之外，我們還希望將這款工具與團隊的Slack頻道連接起來。這樣，團隊就能在月底收到一份工具截圖，其中概述了當月價值流的穩定性和速度表現。要獲取更多詳細信息的話，與截圖一併提供的還有一個指向該工具的鏈接。
我們還將與所有團隊一起舉辦小型研討會，幫助他們熟悉如何將持續交付指標用於設定和追蹤穩定性和速度目標。
採用
我們將持續交付指標引入了一個由16個開發團隊組成的組織中，這些團隊負責的是“teamplay"——這是西門子醫療團隊提供的一項醫療領域的全球化數字服務（有關“teamplay”的更多信息，請參見《西門子醫療團隊在teamplay中採用持續交付方法》）。
這項任務需要大量的解釋工作，因爲它引入了一種從價值流分析的角度來看待軟件開發的新方法，而這在軟件領域並不是常見的事情。這種新方法將部署管道視爲價值流的載體或生產線，而價值流將針對穩定性和速度表現進行優化。
我們從與數據收集相關的團隊收到了許多反饋，以確保原始數據是健全（sound）的。例如：
- 僅考慮主分支構建，而不考慮拉取請求構建
- 特別要包含拉取請求的前置時間，以瞭解拉取請求的審覈等待時間是否存在瓶頸
- 除了跨所有管道環境累積的部署前置時間和部署間隔時間外，還分別爲每個管道環境提供各自的指標
- 等等。
到現在，持續交付指標已深入到少數開發團隊的工作中。有了持續交付指標工具中的可視化概述，團隊非常高興能第一次親眼看到他們自身價值流（代碼→構建→部署）的速度和穩定性表現。
這裏的一個關鍵見解是，開發團隊在工作時並不一定會知道價值在部署管道中的流動情況，也就是速度和穩定性的表現。也就是說，開發人員並不知道他們的工作方式如何影響他們的價值流。
持續交付指標工具提供了價值流的概覽，並充當了開發團隊開發流程的穩定性和速度表現的實時反饋迴路。
有一支團隊看到了他們的部署穩定性指標後，便意識到了頻繁發生的部署失敗，同時也注意到了非常快的部署失敗恢復時間。接下來的幾天內這支團隊大大減少了部署失敗次數。這裏團隊的意識是價值流改善的關鍵動力。改進本身並不難實現。
下面是一個示例，說明了團隊如何大致瞭解其價值流的穩定性和速度表現，並進一步深入研究已確定的瓶頸細節。
團隊價值流的穩定性和速度表現的概述。最大的瓶頸以紅色顯示：
這支團隊價值流中發現的瓶頸有：
- 部署失敗率
- 部署故障恢復時間（中位數）
- 主分支提交前置時間（中位數和標準差）
- 構建間隔時間（中位數）
下面顯示了對"部署失敗率"和"部署失敗恢復時間"瓶頸的深入分析：
在"部署失敗率"趨勢上我們可以看到，從9月開始失敗率一直在穩步上升，最近達到了近100％。同樣，最近的"部署失敗恢復時間"也大幅增加。這意味着部署管道最近幾乎都是紅色狀態。這是團隊要解決的最大瓶頸，消除它後才能讓價值順利地流向團隊管道上的生產環境。
下面顯示了"主分支提交前置時間"瓶頸的深入分析：
在“主分支提交前置時間”趨勢上，我們可以看到與過去相比，最近幾天的表現有所改善。因此這裏的目標是保持現狀。
下面顯示了對"構建間隔時間"瓶頸的深入分析：
在“構建間隔時間”趨勢上，與過去相比，最近幾周我們也看到了良好的改進。在這裏，目標同樣是保持現狀。
優先級
我們的團隊需要更多關於持續交付指標的經驗，以便始終如一地使用手頭的數據作爲優先級決策的輸入。數據分爲多種形式：
- 大多數/中間/最不穩定的管道，表現爲
- 失敗率
- 恢復時間
- 最快/中間/最慢的管道，表現爲
- 管道環境之間的前置時間
- 環境中各個活動之間的間隔時間
既然有了數據，開發團隊（尤其是產品所有者）就必須考慮這些數據，以做出最佳的優先級決策。優先級決策的權衡包括：
- 投資功能以提高產品效率和/或
- 根據CD指標數據投資提升開發效率和/或
- 投資提升服務可靠性
未來的話題
或許我們可以使用機器學習技術，基於部署管道上先前環境中的穩定性和速度數據來預測管道環境中的穩定性和速度表現。這是我們將來可以探索的內容。
此外，我們可能會根據CD指標數據自動在某些管道環境中實施部署。
總結
總而言之，如果團隊使用持續交付指標來優化其開發流程，那麼該團隊便能夠以數據驅動的方式逐步優化其工作方式。隨着時間的流逝，團隊就可以達到一種狀態，也就是他們可以有效地構建功能，而不會在價值流中遇到較大的瓶頸。
最後，持續交付指標旨在爲持續改進通用軟件交付流程提供一種數據驅動的方法。它能夠幫助開發流程中的決策過程實現非政治化和透明化。
本文是“軟件產品交付組織的數據驅動決策”系列文章的一部分。本系列概述了數據驅動的決策如何支持軟件交付中的三大活動——產品管理，開發和運營。上一篇文章闡明瞭產品管理中由數據驅動的決策。未來的文章將闡明運營中的數據驅動決策以及產品管理、開發和運營中數據驅動決策的組合。
致謝
許多人爲本文背後的思想做出了貢獻。Kiran Kumar Gollapelly，Krishna Chaithanya Pomar和Bhadri Narayanan ARR幫助實現了最初由Frances Paulisch資助的持續交付指標工具。感謝西門子醫療負責“teamplay”的整個團隊引入和採用本文中的方法。
作者介紹：
Vladyslav Ukis 先後畢業於德國Erlangen-Nuremberg大學以及英國曼徹斯特大學的計算機科學專業。他一畢業就加入西門子醫療，並一直致力於軟件架構、企業架構、創新管理、私有和公共雲計算、團隊管理和工程管理。最近幾年，他一直在西門子醫療數字生態系統平臺和應用（Siemens Healthineers Digital Ecosystem Platform and Applications）“teamplay”上推動持續交付和DevOps轉型。
原文鏈接：
Data-Driven Decision Making – Product Development with Continuous Delivery Indicators
相關閱讀：