什麼是真正的敏捷開發？阿里資深技術專家內部分享公開

阿里妹導讀：從本質上講，敏捷開發的一個重要目標是建立持續價值交付的能力。這種能力最終必須服務於業務的創新，促進業務的成功。

今天，阿里巴巴雲效平臺敏捷教練團隊負責人、資深技術專家何勉老師，將從敏捷開發的目標、定義這兩個維度帶我們探索敏捷研發的冰山一角（本文內容來自阿里巴巴內部培訓課程整理）。

敏捷開發業務目標

我們經常會說敏捷模式，那什麼開發模式是不敏捷呢？對，我們通常說“瀑布”是不敏捷的。

瀑布開發模式把開發分成一系列階段，如需求、設計、開發、測試，就像上圖它畫出來的，看起來很像瀑布，所以叫瀑布開發。問題是需求的交付難道不都是要經歷這些階段嗎？

瀑布開發的本質問題並不是階段，而是批量。需求批量地在一起進行設計，然後是批量地開發，批量地測試、交付等等。批量有什麼問題? 首先，批量讓價值交付延遲，所有需求在最後的階段才能交付，價值交付比較晚。

價值交付比較晚又怎麼樣？看這幅圖。左邊是Intel的創始人摩爾，摩爾定律的提出者。摩爾定律告訴我們，18個月之後，用同樣的錢能買到多一倍的東西，比如計算能力、儲存量、晶元數等等。而右邊這位是Google執行董事長施密特，他提出了反摩爾定律，表述為：“如果18個月之後我們只能賣出跟今天一樣的東西，我們就只能得到一半的收入。”

反摩爾定律是摩爾定律的一個簡單推論，它告訴我們，越遲交付的價值也是越低的價值。對硬體公司這很關鍵，甚至決定它們的的宿命——技術進步必須跟得上摩爾定律，否則利潤就會被摩爾定律吞噬，讓產品或公司走向滅亡。

軟體或網際網路服務又怎樣呢？ IBM在上世紀90年代，意識到不能做一家硬體公司，轉而主攻服務和軟體行業，它的確過了一段好日子。然而，很快網際網路時代到來了，軟體和服務行業的創新一下子加速了。這時，相對硬體公司，反摩爾定律在軟體和網際網路服務公司的作用是有過之而無不及的，時間的遲早可能不僅僅決定價值的多少，有時錯過整時間窗，可能會一無所獲。

反摩爾定律告訴我們，越遲交付的價值也是越低的價值。所以對於軟體開發來說，瀑布模式延遲了價值交付，得到的價值也更少。相對瀑布，我們提出了迭代交付，我們把開發分成迭代，每個迭代交付一部分價值，更早交付的價值往往意味著更多的價值。就這一點來說，迭代相對瀑布的本質是，更小批量的快速交付，從而更早獲取更多價值，和獲取市場競爭的先機。

所以敏捷開發有第一個目標就是更快的交付價值，這裡的快指的不是絕對速度，而是更早的交付。

第二點，我們再看一個座標圖，這個座標是專案的時間歷程，最左是專案開始，最右是專案結束。縱座標是團隊擁有的這個專案和產品的知識，比如說使用者要什麼，採取什麼樣的產品方案，應該做什麼樣的功能，以怎樣的形式來協作，選擇什麼樣的技術方案等等。

我們想問一下團隊（包括產品也包括開發、業務）什麼時候對於產品和專案的知識最充分、最多？大家的答案都很一致，專案結束的時候。這顯而易見，我們在專案程式中積累了知識，特別是當向使用者交付產品後，使用者反饋：“我要的不是這個啊，我說的明明是……”，這時候你瞬間狂漲知識，並感嘆道“你怎麼不早說呢？”。這中間可能有溝通問題，但更多可能的是，使用者這時才清楚或能夠描述他們要的是啥，更有甚者，我們可能一開始連使用者是誰也未必能準確地定義。產品和業務開發本來就是一個探索的過程，開始時一定是最無知的時刻。

再問一個問題。專案中的大部分決策，是什麼時間做出的呢？大家的答案也很明確——專案開始的時刻。這裡埋藏了一個重大的悖論，我們在最無知的時刻，做出了最重要而且是絕大部分的決策，並把它作為隨後執行的依據。面對不確定的技術、市場環境，傳統開發模式已無法適應要求，悖論越發突出。

對於這一悖論，敏捷的對策還是迭代。開始時，我們會做出一些初始的決策，比如說總體目標是什麼，大概的策略和打法是什麼，從哪裡開始，怎麼檢驗等等。但這些只是初始決策，定義了大致的方向。在整個開發過程，我們迭代交付需求，獲取市場的反饋和最新的資訊，並基於這些反饋和資訊，積累和修正對產品的認知，增量地決策和調整。

產品開發過程中，技術環境、市場環境、競品策略、團隊認知都會發生變化。面對變化的環境，我們必須承認自己的無知，在開發過程主動有效地學習，不斷地汲取反饋，靈活地調整。這也是敏捷的第二個業務目標，有效學習和靈活響應變化。

綜合上面提到的敏捷開發的兩個業務目標，我們就可以給敏捷開發下一個定義了。敏捷指的是建立一個組織更快（早）的交付價值，和更有效學習和靈活應變的能力。

 

從能力的角度，敏捷的核心是持續交付價值的能力，以及以持續交付為基礎的快速反饋學習能力。為了具備這樣的能力，產品的開發和交付方式需要做出根本變化。這幅圖從概念上體現了，傳統批量式的開發方式到敏捷的持續交付方式的轉變。

傳統開發方式下，需求成批量的流經各個階段和組織部門，如產品、UED、開發、測試、運營等直至交付，各個職能各自優化自己的工作，形成效率豎井。由於批量的原因，需求等待整個批量完成，才能集中進入下一階段。從單個需求的角度看，需求大部分時間都處於等待狀態。

上圖的右半部分表達了這一過程，單個需求的實際處理的時間很短（圖中折線中上面綠色的短線），它們大部分時間都處於等待狀態（圖中折線下面紅色的長線），最終表現出的實際交付週期很長。

通過敏捷實施，我們希望整個組織協調一致，更緊密協作，縮短交付週期。圖中左半部分是理想的敏捷開發模式，它體現了敏捷開發的基本目標——持續價值交付和快速反饋、學習，這其中持續價值交付是基礎。

問題是如何才能建立和改進持續價值交付能力呢？

定義

管理學之父德魯克說：“如果你不能度量它，你就無法改進它。”對於持續交付能力，這同樣適用。

有效的度量體系應該圍繞核心問題展開。在這裡，這個根本問題就是團隊的持續價值交付能力如何？我們將用五組指標來回答這一問題，它們分別是：

第一：釋出能力，具體包含兩個細分指標，分別是：

1）釋出頻率，也就是團隊平均多長時間釋出一次需求。它約束了團隊對外響應的最大可能；

2）釋出前置時間，也就是從程式碼提交，到功能上線所需要花費的時間。如果時間開銷很大，團隊就不太可能去加大發版的頻率。

第二：需求響應週期，它包含兩個細分的指標，分別是：

1）交付週期時間，也就是從使用者提出需求並被確認，到需求上線所要經歷的時長。它反映團隊（包含業務、開發、運營等職能）對客戶問題或業務機會的整體響應速度；

2）開發週期時間：從開發團隊理解並確認需求，到需求可以上線所經歷的時長。它反映研發的響應能力。

第三：交付的吞吐率，也就是單位時間內交付的需求的個數。

第四：內建質量的能力，也就是整個交付過程的質量。它包含兩個細分的指標，分別是：

1)開發過程中缺陷的建立和修復時間的分佈。我們希望缺陷能夠及時且持續地發現，並且在發現後儘快修復；

2）缺陷庫存，我們希望能在整個開發過程中控制缺陷庫存量，讓產品始終處於接近可釋出狀態，奠定持續交付的基礎。關於內建質量的能力的具體度量方法，我們後面還會詳細介紹。

第五：對外交付質量。它包含兩個細分的指標，分別是：

1)單位時間（線上）問題數目；

2）（線上）問題平均解決時長。

好的度量體系應該回答一個根本問題，併為此講述完整的故事。為回答團隊交付能力如何這一問題， 上面5組指標，分別從響應能力、效率和質量三個方面提供一個完整的故事。其中，持續釋出能力和需求響應週期這兩組指標反映的是響應能力，也就是價值的流動效率；交付吞吐率這一指標反映的是團隊效率，也就是資源的產出效率；內建質量的能力和對外交付質量這兩組指標是質量指標。這些指標綜合起來，讓我們可以全面瞭解當前交付等能力，與目標的差距，以及改進的機會。

以上是度量體系的總體設計，我們把週期時間作為衡量團隊響應能力的核心指標。這幅圖更直觀地展示了兩個週期時間的計算方式，以看板的工作流為基礎，客戶週期時間的起點是從需求被選擇開始，到需求釋出結束；開發週期時間則從待開發開始，到待發布結束。

基於上面的度量指標體系，我們選擇和設計了相關的圖表，來呈現這些度量。下面我們介紹其中的一些例子。

第一是累積流圖。累積流圖再現了團隊協作交付價值的過程，它的橫座標為日期，縱座標為各階段累積完成的需求數目。從左至右的各條線，反映各個階段累積處理完成的需求數量。例如：圖中最上面這條線是已經就緒的需求的個數，最下面這條線是已經上線的需求的個數，中間這條線分別是已經開發的、開發結束的、已經測試的、測試結束的等等。

累積流圖綜合反映了平均交付週期、在製品數量、到達和交付速率三類指標。

第一：平均交付時間。交付時間指需求交付之前從開始到結束所經歷的時間。圖中，到3月26日這一天累積計劃了40個需求，而到5月15日這一天累積交付了40個需求。假設需求符合先入先出（先計劃的先交付）的規律，那麼第40個需求的交付週期時間就是 5月15日 - 3月26日 = 50（天）。之所以要在交付時間之前加上“平均”，是因為並非所有的需求都是先進先出。從累積流圖上還可以進一步看出交付時間在各個階段的分佈。

第二：在製品的數量。在製品（Work in Process）指正在處理的需求的數目，也就是所有開始但還沒有完成的需求的數目。如：上圖中4月15日這一天，累積開始的需求有61個，累積上線的需求是8個。在製品數量 = 61- 8 = 53（個），它們已經開始，但還沒有交付。從累積流圖上還可以進一步看出在製品在各個階段的分佈，如開發中的，待測試的，測試中的等。

第三：需求的到達和交付速率。指單位時間內到達和交付需求的數目。圖中，從3月1日到3月30日，4周時間交付需求數目從10個增加到50個，共交付40個需求，到達速率 = 40 / 4 = 10 （個/周）。從4月1日到4月30日，4周時間交付需求數目從10個增加到30個，共交付20個需求，到達速率 = 20 / 4 = 5 （個/周）。從累積流圖上還可以看出不同階段的產出速率，以及它們的變化趨勢。

累積流圖再現了團隊協作和交付過程，從中我們能夠解讀出團隊的開發模式，演變趨勢和改進機會等。例如：從圖中上邊線階梯可以看到批量計劃模式，而4月開始計劃的批量變得更小，釋出頻率加大，相應的並行的在製品的數目也變少了，週期時間隨之變短了，交付的效率（交付線的斜率）也有所提高。

我們再看另一幅圖表——缺陷趨勢圖，它反映了團隊引入、發現及移除缺陷的行為模式。圖形的橫座標是日期，橫座標上方紅色豎條代表當天發現缺陷的數量；橫座標下方綠色豎條代表當天解決的缺陷的數量；橙色曲線代表缺陷存量。通過缺陷趨勢圖希望引導使用者的行為是：持續且儘早發現缺陷並及時移除它們，從而控制缺陷庫存，保證系統隨時處於接近可釋出狀態，奠定持續交付的基礎。 上圖的左右兩個部分比較了兩種交付模式下的缺陷趨勢圖。

左半部分：“迭代”前期團隊集中設計、編碼引入缺陷，但由於並未即時的整合和驗證，缺陷未被即時發現。到了專案後期團隊開始整合和測試，缺陷集中爆發。小瀑布模式過程質量差，帶來大量的返工、延期、趕工和交付質量問題。該模式下，產品的交付時間依賴於何時缺陷被充分移除，無法做到持續交付，降低了團隊對外的響應能力。

右半部分：在整個迭代過程中，團隊以小粒度的需求為單位開發、整合、測試，即時發現並解決問題。這樣，缺陷庫存得到控制，系統始終處於接近可釋出狀態，做到持續釋出，提高團隊對外的響應能力。缺陷趨勢圖可以從一個側面反映團隊的開發及交付模式，衡量團隊的持續交付能力，引導團隊向持續交付演進。

好的度量應該為回答一個根本問題，講述完整的故事。我們回答的問題是團隊持續交付能力及其改進機會，並針對這個問題講述了完整的故事。也正是基於以上的體系， 雲效專案域對度量體系做了一次重構。上面的圖是一個概念說明，大家可以去使用，我們也會根據大家的反饋，持續優化度量體系的設計。

阿里內部分享現場

嘉賓簡介：何勉老師，阿里巴巴雲效平臺敏捷教練團隊負責人、資深技術專家，國內最早的精益產品開發實踐者之一，暢銷書《精益產品開發：原則、方法與實施》作者。專注於精益產品交付、精益創業創新及精益產品設計等領域，幫助組織提升研發效能。曾成功幫助阿里內部多個事業部、華為、平安科技、招行以及多家創業公司建立或引入精益產品開發和創新方法。

在釘釘搜尋群號：23192180，或者用釘釘掃描下方二維碼，即可加入阿里研發效能&敏捷開發交流群，與作者何勉老師、行業同仁交流、探討。

你可能還喜歡

點選下方圖片即可閱讀

1024，什麼會引起程式設計師的強烈舒適？

分散式系統的基本問題：可用性與一致性

阿里巴巴為什麼選擇Apache Flink？

關注「阿里技術」

把握前沿技術脈搏