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

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

今天丰泊，阿里巴巴云效平臺敏捷教練團隊負責(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ì)問題并不是階段，而是批量炎辨。需求批量地在一起進行設(shè)計捕透，然后是批量地開發(fā)，批量地測試碴萧、交付等等乙嘀。批量有什么問題? 首先，批量讓價值交付延遲破喻，所有需求在最后的階段才能交付虎谢，價值交付比較晚。

價值交付比較晚又怎么樣曹质？看這幅圖婴噩。左邊是Intel的創(chuàng)始人摩爾，摩爾定律的提出者咆繁。摩爾定律告訴我們讳推，18個月之后，用同樣的錢能買到多一倍的東西玩般，比如計算能力银觅、存儲量、晶元數(shù)等等坏为。而右邊這位是Google執(zhí)行董事長施密特究驴，他提出了反摩爾定律镊绪，表述為：“如果18個月之后我們只能賣出跟今天一樣的東西，我們就只能得到一半的收入洒忧『拢”

反摩爾定律是摩爾定律的一個簡單推論，它告訴我們熙侍，越遲交付的價值也是越低的價值榄鉴。對硬件公司這很關(guān)鍵，甚至決定它們的的宿命——技術(shù)進步必須跟得上摩爾定律蛉抓，否則利潤就會被摩爾定律吞噬庆尘，讓產(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ì)是哥攘，更小批量的快速交付，從而更早獲取更多價值，和獲取市場競爭的先機逝淹。

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

第二點茉兰，我們再看一個坐標(biāo)圖，這個坐標(biāo)是項目的時間歷程欣簇，最左是項目開始规脸，最右是項目結(jié)束⌒苎剩縱坐標(biāo)是團隊擁有的這個項目和產(chǎn)品的知識燃辖，比如說用戶要什么，采取什么樣的產(chǎn)品方案网棍，應(yīng)該做什么樣的功能，以怎樣的形式來協(xié)作妇智，選擇什么樣的技術(shù)方案等等滥玷。

我們想問一下團隊（包括產(chǎn)品也包括開發(fā)、業(yè)務(wù)）什么時候?qū)τ诋a(chǎn)品和項目的知識最充分巍棱、最多惑畴？大家的答案都很一致，項目結(jié)束的時候航徙。這顯而易見如贷，我們在項目進程中積累了知識，特別是當(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)品的認知，增量地決策和調(diào)整渠羞。

產(chǎn)品開發(fā)過程中斤贰，技術(shù)環(huán)境、市場環(huán)境堵未、競品策略腋舌、團隊認知都會發(fā)生變化。面對變化的環(huá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)化自己的工作第练，形成效率豎井翔试。由于批量的原因，需求等待整個批量完成复旬，才能集中進入下一階段。從單個需求的角度看冲泥，需求大部分時間都處于等待狀態(tài)驹碍。

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

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

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

定義

管理學(xué)之父德魯克說：“如果你不能度量它隅很，你就無法改進它撞牢。”對于持續(xù)交付能力，這同樣適用屋彪。

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

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

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

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

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

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

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

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

第四：內(nèi)建質(zhì)量的能力罢荡，也就是整個交付過程的質(zhì)量。它包含兩個細分的指標(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ì)量的能力的具體度量方法拜效，我們后面還會詳細介紹。

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

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

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

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

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

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

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

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

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

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

第三：需求的到達和交付速率羡疗。指單位時間內(nèi)到達和交付需求的數(shù)目。圖中别洪，從3月1日到3月30日叨恨，4周時間交付需求數(shù)目從10個增加到50個，共交付40個需求挖垛，到達速率 = 40 / 4 = 10 （個/周）痒钝。從4月1日到4月30日秉颗，4周時間交付需求數(shù)目從10個增加到30個，共交付20個需求午乓，到達速率 = 20 / 4 = 5 （個/周）站宗。從累積流圖上還可以看出不同階段的產(chǎn)出速率，以及它們的變化趨勢益愈。

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

我們再看另一幅圖表——缺陷趨勢圖蜂大，它反映了團隊引入、發(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ǔ)。 上圖的左右兩個部分比較了兩種交付模式下的缺陷趨勢圖藏否。

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

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

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