轉(zhuǎn)載:https://mp.weixin.qq.com/s/Qf00OxEbwv4wiHS5oG0-uQ

阿里妹導(dǎo)讀：從本質(zhì)上講，敏捷開發(fā)的一個重要目標(biāo)是建立持續(xù)價值交付的能力。這種能力最終必須服務(wù)于業(yè)務(wù)的創(chuàng)新，促進(jìn)業(yè)務(wù)的成功。

今天，阿里巴巴云效平臺敏捷教練團(tuán)隊負(fù)責(zé)人、資深技術(shù)專家何勉老師，將從敏捷開發(fā)的目標(biāo)、定義這兩個維度帶我們探索敏捷研發(fā)的冰山一角（本文內(nèi)容來自阿里巴巴內(nèi)部培訓(xùn)課程整理）。

敏捷開發(fā)業(yè)務(wù)目標(biāo)

我們經(jīng)常會說敏捷模式，那什么開發(fā)模式是不敏捷呢？對，我們通常說“瀑布”是不敏捷的。

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

瀑布開發(fā)的本質(zhì)問題并不是階段，而是批量。需求批量地在一起進(jìn)行設(shè)計，然后是批量地開發(fā)，批量地測試、交付等等。批量有什么問題? 首先，批量讓價值交付延遲，所有需求在最后的階段才能交付，價值交付比較晚。

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

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

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

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

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

第二點，我們再看一個坐標(biāo)圖，這個坐標(biāo)是項目的時間歷程，最左是項目開始，最右是項目結(jié)束?？v坐標(biāo)是團(tuán)隊擁有的這個項目和產(chǎn)品的知識，比如說用戶要什么，采取什么樣的產(chǎn)品方案，應(yīng)該做什么樣的功能，以怎樣的形式來協(xié)作，選擇什么樣的技術(shù)方案等等。

我們想問一下團(tuán)隊（包括產(chǎn)品也包括開發(fā)、業(yè)務(wù)）什么時候?qū)τ诋a(chǎn)品和項目的知識最充分、最多？大家的答案都很一致，項目結(jié)束的時候。這顯而易見，我們在項目進(jìn)程中積累了知識，特別是當(dāng)向用戶交付產(chǎn)品后，用戶反饋：“我要的不是這個啊，我說的明明是……”，這時候你瞬間狂漲知識，并感嘆道“你怎么不早說呢？”。這中間可能有溝通問題，但更多可能的是，用戶這時才清楚或能夠描述他們要的是啥，更有甚者，我們可能一開始連用戶是誰也未必能準(zhǔn)確地定義。產(chǎn)品和業(yè)務(wù)開發(fā)本來就是一個探索的過程，開始時一定是最無知的時刻。

再問一個問題。項目中的大部分決策，是什么時間做出的呢？大家的答案也很明確——項目開始的時刻。這里埋藏了一個重大的悖論，我們在最無知的時刻，做出了最重要而且是絕大部分的決策，并把它作為隨后執(zhí)行的依據(jù)。面對不確定的技術(shù)、市場環(huán)境，傳統(tǒng)開發(fā)模式已無法適應(yīng)要求，悖論越發(fā)突出。

對于這一悖論，敏捷的對策還是迭代。開始時，我們會做出一些初始的決策，比如說總體目標(biāo)是什么，大概的策略和打法是什么，從哪里開始，怎么檢驗等等。但這些只是初始決策，定義了大致的方向。在整個開發(fā)過程，我們迭代交付需求，獲取市場的反饋和最新的信息，并基于這些反饋和信息，積累和修正對產(chǎn)品的認(rèn)知，增量地決策和調(diào)整。

產(chǎn)品開發(fā)過程中，技術(shù)環(huán)境、市場環(huán)境、競品策略、團(tuán)隊認(rèn)知都會發(fā)生變化。面對變化的環(huán)境，我們必須承認(rèn)自己的無知，在開發(fā)過程主動有效地學(xué)習(xí)，不斷地汲取反饋，靈活地調(diào)整。這也是敏捷的第二個業(yè)務(wù)目標(biāo)，有效學(xué)習(xí)和靈活響應(yīng)變化。

綜合上面提到的敏捷開發(fā)的兩個業(yè)務(wù)目標(biāo)，我們就可以給敏捷開發(fā)下一個定義了。敏捷指的是創(chuàng)建一個組織更快（早）的交付價值，和更有效學(xué)習(xí)和靈活應(yīng)變的能力。

從能力的角度，敏捷的核心是持續(xù)交付價值的能力，以及以持續(xù)交付為基礎(chǔ)的快速反饋學(xué)習(xí)能力。為了具備這樣的能力，產(chǎn)品的開發(fā)和交付方式需要做出根本變化。這幅圖從概念上體現(xiàn)了，傳統(tǒng)批量式的開發(fā)方式到敏捷的持續(xù)交付方式的轉(zhuǎn)變。

傳統(tǒng)開發(fā)方式下，需求成批量的流經(jīng)各個階段和組織部門，如產(chǎn)品、UED、開發(fā)、測試、運營等直至交付，各個職能各自優(yōu)化自己的工作，形成效率豎井。由于批量的原因，需求等待整個批量完成，才能集中進(jìn)入下一階段。從單個需求的角度看，需求大部分時間都處于等待狀態(tài)。

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

通過敏捷實施，我們希望整個組織協(xié)調(diào)一致，更緊密協(xié)作，縮短交付周期。圖中左半部分是理想的敏捷開發(fā)模式，它體現(xiàn)了敏捷開發(fā)的基本目標(biāo)——持續(xù)價值交付和快速反饋、學(xué)習(xí)，這其中持續(xù)價值交付是基礎(chǔ)。

問題是如何才能建立和改進(jìn)持續(xù)價值交付能力呢？

定義

管理學(xué)之父德魯克說：“如果你不能度量它，你就無法改進(jìn)它?！睂τ诔掷m(xù)交付能力，這同樣適用。

有效的度量體系應(yīng)該圍繞核心問題展開。在這里，這個根本問題就是團(tuán)隊的持續(xù)價值交付能力如何？我們將用五組指標(biāo)來回答這一問題，它們分別是：

第一：發(fā)布能力，具體包含兩個細(xì)分指標(biāo)，分別是：

1）發(fā)布頻率，也就是團(tuán)隊平均多長時間發(fā)布一次需求。它約束了團(tuán)隊對外響應(yīng)的最大可能；

2）發(fā)布前置時間，也就是從代碼提交，到功能上線所需要花費的時間。如果時間開銷很大，團(tuán)隊就不太可能去加大發(fā)版的頻率。

第二：需求響應(yīng)周期，它包含兩個細(xì)分的指標(biāo)，分別是：

1）交付周期時間，也就是從用戶提出需求并被確認(rèn)，到需求上線所要經(jīng)歷的時長。它反映團(tuán)隊（包含業(yè)務(wù)、開發(fā)、運營等職能）對客戶問題或業(yè)務(wù)機(jī)會的整體響應(yīng)速度；

2）開發(fā)周期時間：從開發(fā)團(tuán)隊理解并確認(rèn)需求，到需求可以上線所經(jīng)歷的時長。它反映研發(fā)的響應(yīng)能力。

第三：交付的吞吐率，也就是單位時間內(nèi)交付的需求的個數(shù)。

第四：內(nèi)建質(zhì)量的能力，也就是整個交付過程的質(zhì)量。它包含兩個細(xì)分的指標(biāo)，分別是：

1)開發(fā)過程中缺陷的創(chuàng)建和修復(fù)時間的分布。我們希望缺陷能夠及時且持續(xù)地發(fā)現(xiàn)，并且在發(fā)現(xiàn)后盡快修復(fù)；

2）缺陷庫存，我們希望能在整個開發(fā)過程中控制缺陷庫存量，讓產(chǎn)品始終處于接近可發(fā)布狀態(tài)，奠定持續(xù)交付的基礎(chǔ)。關(guān)于內(nèi)建質(zhì)量的能力的具體度量方法，我們后面還會詳細(xì)介紹。

第五：對外交付質(zhì)量。它包含兩個細(xì)分的指標(biāo)，分別是：

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

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

好的度量體系應(yīng)該回答一個根本問題，并為此講述完整的故事。為回答團(tuán)隊交付能力如何這一問題， 上面5組指標(biāo)，分別從響應(yīng)能力、效率和質(zhì)量三個方面提供一個完整的故事。其中，持續(xù)發(fā)布能力和需求響應(yīng)周期這兩組指標(biāo)反映的是響應(yīng)能力，也就是價值的流動效率；交付吞吐率這一指標(biāo)反映的是團(tuán)隊效率，也就是資源的產(chǎn)出效率；內(nèi)建質(zhì)量的能力和對外交付質(zhì)量這兩組指標(biāo)是質(zhì)量指標(biāo)。這些指標(biāo)綜合起來，讓我們可以全面了解當(dāng)前交付等能力，與目標(biāo)的差距，以及改進(jìn)的機(jī)會。

以上是度量體系的總體設(shè)計，我們把周期時間作為衡量團(tuán)隊響應(yīng)能力的核心指標(biāo)。這幅圖更直觀地展示了兩個周期時間的計算方式，以看板的工作流為基礎(chǔ)，客戶周期時間的起點是從需求被選擇開始，到需求發(fā)布結(jié)束；開發(fā)周期時間則從待開發(fā)開始，到待發(fā)布結(jié)束。

基于上面的度量指標(biāo)體系，我們選擇和設(shè)計了相關(guān)的圖表，來呈現(xiàn)這些度量。下面我們介紹其中的一些例子。

第一是累積流圖。累積流圖再現(xiàn)了團(tuán)隊協(xié)作交付價值的過程，它的橫坐標(biāo)為日期，縱坐標(biāo)為各階段累積完成的需求數(shù)目。從左至右的各條線，反映各個階段累積處理完成的需求數(shù)量。例如：圖中最上面這條線是已經(jīng)就緒的需求的個數(shù)，最下面這條線是已經(jīng)上線的需求的個數(shù)，中間這條線分別是已經(jīng)開發(fā)的、開發(fā)結(jié)束的、已經(jīng)測試的、測試結(jié)束的等等。

累積流圖綜合反映了平均交付周期、在制品數(shù)量、到達(dá)和交付速率三類指標(biāo)。

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

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

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

累積流圖再現(xiàn)了團(tuán)隊協(xié)作和交付過程，從中我們能夠解讀出團(tuán)隊的開發(fā)模式，演變趨勢和改進(jìn)機(jī)會等。例如：從圖中上邊線階梯可以看到批量計劃模式，而4月開始計劃的批量變得更小，發(fā)布頻率加大，相應(yīng)的并行的在制品的數(shù)目也變少了，周期時間隨之變短了，交付的效率（交付線的斜率）也有所提高。

我們再看另一幅圖表——缺陷趨勢圖，它反映了團(tuán)隊引入、發(fā)現(xiàn)及移除缺陷的行為模式。圖形的橫坐標(biāo)是日期，橫坐標(biāo)上方紅色豎條代表當(dāng)天發(fā)現(xiàn)缺陷的數(shù)量；橫坐標(biāo)下方綠色豎條代表當(dāng)天解決的缺陷的數(shù)量；橙色曲線代表缺陷存量。通過缺陷趨勢圖希望引導(dǎo)用戶的行為是：持續(xù)且盡早發(fā)現(xiàn)缺陷并及時移除它們，從而控制缺陷庫存，保證系統(tǒng)隨時處于接近可發(fā)布狀態(tài)，奠定持續(xù)交付的基礎(chǔ)。 上圖的左右兩個部分比較了兩種交付模式下的缺陷趨勢圖。

左半部分：“迭代”前期團(tuán)隊集中設(shè)計、編碼引入缺陷，但由于并未即時的集成和驗證，缺陷未被即時發(fā)現(xiàn)。到了項目后期團(tuán)隊開始集成和測試，缺陷集中爆發(fā)。小瀑布模式過程質(zhì)量差，帶來大量的返工、延期、趕工和交付質(zhì)量問題。該模式下，產(chǎn)品的交付時間依賴于何時缺陷被充分移除，無法做到持續(xù)交付，降低了團(tuán)隊對外的響應(yīng)能力。

右半部分：在整個迭代過程中，團(tuán)隊以小粒度的需求為單位開發(fā)、集成、測試，即時發(fā)現(xiàn)并解決問題。這樣，缺陷庫存得到控制，系統(tǒng)始終處于接近可發(fā)布狀態(tài)，做到持續(xù)發(fā)布，提高團(tuán)隊對外的響應(yīng)能力。缺陷趨勢圖可以從一個側(cè)面反映團(tuán)隊的開發(fā)及交付模式，衡量團(tuán)隊的持續(xù)交付能力，引導(dǎo)團(tuán)隊向持續(xù)交付演進(jìn)。

好的度量應(yīng)該為回答一個根本問題，講述完整的故事。我們回答的問題是團(tuán)隊持續(xù)交付能力及其改進(jìn)機(jī)會，并針對這個問題講述了完整的故事。也正是基于以上的體系， 云效項目域?qū)Χ攘矿w系做了一次重構(gòu)。上面的圖是一個概念說明，大家可以去使用，我們也會根據(jù)大家的反饋，持續(xù)優(yōu)化度量體系的設(shè)計。