建站
咨詢
售后
建站咨詢
新聞中心
在 什么是真正的敏捷開發(fā)?文章里，我們講述了什么是真正意義的敏捷開發(fā)，如何去衡量。今天，阿里資深技術(shù)專家何勉老師，繼續(xù)帶領(lǐng)我們探索，如何以流動(dòng)效率為抓手，提升持續(xù)交付的能力。
提升持續(xù)交付能力
最近我們?cè)诎⒗飪?nèi)部做團(tuán)隊(duì)效能改進(jìn)時(shí)，提出了稱之為“2-1-1”的愿景，得到了不少部門的認(rèn)可。什么是211呢?“2”指的是交付周期2周——85%以上的需求可以在2周內(nèi)交付;第一個(gè)“1”指的是開發(fā)周期1周——85%以上的需求可以在1周內(nèi)開發(fā)完成;第二個(gè)“1”指的是發(fā)布前置時(shí)間1小時(shí)——提交代碼后可以在1小時(shí)內(nèi)完成發(fā)布。
今天，很多團(tuán)隊(duì)離“211”還是有距離的，特別是這個(gè)“2”，它涉及到整個(gè)組織各職能，和部門的協(xié)調(diào)一致，緊密協(xié)作。一小時(shí)的發(fā)布前置時(shí)間，則需要持續(xù)交付流水線，產(chǎn)品架構(gòu)體系和自動(dòng)化測(cè)試、部署等有力保障。達(dá)成“211”并不容易，但它體現(xiàn)了組織提升持續(xù)交付和快速響應(yīng)能力的目標(biāo)，樹立了持續(xù)改進(jìn)的方向，因此我們才把它作為愿景。
注：以上理念也將落地到研發(fā)工具云效(阿里內(nèi)部叫Aone)，從交付流程、交付結(jié)果、交付質(zhì)量等數(shù)據(jù)也可在云效的度量功能中查看。
問題是我們?nèi)绾尾拍苓_(dá)成這一目標(biāo)呢?讓我們先看一幅漫畫。
這是一個(gè)酒吧，路燈下醉漢在找什么東西，很長(zhǎng)時(shí)間過去了，警察一直看著他，終于忍不住走上前，問道：“你在找啥?”醉漢說：“找我的鑰匙。”警察看了一下鑰匙好像不在這，就問：“鑰匙是丟在這嗎?”醉漢說：“不是。”警察奇怪地問道：“那你為什么在這找?”醉漢回答道：“只有這兒能看到啊 ?！?/p>
鑰匙(key)英文也有關(guān)鍵的意思。光照亮的地方卻不是關(guān)鍵所在。我講這個(gè)故事，是為了說明研發(fā)中一個(gè)常見的問題——在光照亮的地方，而不是關(guān)鍵所在的地方尋找答案，當(dāng)然不會(huì)有結(jié)果。那研發(fā)過程的關(guān)鍵所在究竟在哪里呢?
《The Principles of product development flow》一書的作者Don指出：“在產(chǎn)品開發(fā)中，問題的關(guān)鍵幾乎從來不是停滯的資源，而是停滯的需求。”這是什么意思呢?產(chǎn)品開發(fā)的最終目的是交付價(jià)值，那我們就必須讓價(jià)值交付的過程順暢起來，也就是讓價(jià)值流動(dòng)順暢起來。計(jì)劃、管理、協(xié)調(diào)活動(dòng)，以及資源的配置等等，都應(yīng)該服務(wù)于價(jià)值的流動(dòng)。價(jià)值流動(dòng)是目的，資源忙起來不是。
現(xiàn)實(shí)中我們更多關(guān)注資源是否停滯，人是否閑著，但真正的問題并不在這兒。真正的問題是需求的停滯，需求在各個(gè)階段的積壓——如分析階段、測(cè)試階段、發(fā)布階段等等。需求不能順暢流動(dòng)才是真正的問題所在，也就是我們所說的關(guān)鍵所在。
為什么我們往往對(duì)需求的積壓很少關(guān)注?因?yàn)樗茈y看到，不是光照亮的地方。我們很難覺察(至少很難即時(shí)察覺)需求的停滯、積壓和返工，而那才是改進(jìn)價(jià)值交付的關(guān)鍵所在。
要改進(jìn)端到端的流程，我們必須看到價(jià)值端到端的流動(dòng)過程，在哪里出現(xiàn)了積壓和停滯。為此，改進(jìn)的第一步，就是要讓光照亮關(guān)鍵所在——可視化端到端的價(jià)值流動(dòng)過程，基于價(jià)值流發(fā)現(xiàn)流動(dòng)過程中的問題。
看一個(gè)例子，它是來自某個(gè)產(chǎn)品團(tuán)隊(duì)看板。看板中藍(lán)色卡片的是需求。讓光照亮關(guān)鍵所在，就是要讓需求流動(dòng)的端到端過程可視化。需求從“選擇”開始，所謂選擇是指從眾多的市場(chǎng)機(jī)會(huì)中選擇這些需求開始開發(fā)。選擇之后是流程中的其他階段，比如需求的設(shè)計(jì)、開發(fā)、測(cè)試、驗(yàn)收等，直至發(fā)布，這是一個(gè)端到端的過程。
我們單獨(dú)看“開發(fā)中”這個(gè)階段，在這里需求被分解成為任務(wù)——圖中黃色紙條。任務(wù)與其所屬于的需求處于同一行中，我們把這樣的行稱為泳道。泳道的首列(藍(lán)色紙條)是需求，下屬任務(wù)(黃色卡片)按模塊組織在一起，如前端、后端或其他依賴的外部模塊，其中任務(wù)的最后一列代表完成狀態(tài)，所有任務(wù)完成后，需求進(jìn)入下一階段——待測(cè)試。
端到端可視化需求的流動(dòng)過程，從需求被選擇開始，直到發(fā)布結(jié)束。這讓我們能即時(shí)看到問題，如：需求是否順暢流動(dòng)，是否發(fā)生了停滯和積壓，是否有瓶頸。這就是所謂：光照亮了問題所在。
除此之外，我們還要保障價(jià)值流動(dòng)的過程質(zhì)量，把交付質(zhì)量?jī)?nèi)建到開發(fā)過程中，而不是依賴最后環(huán)節(jié)的測(cè)試。為了做到內(nèi)建質(zhì)量，我們需要明確定義需求流動(dòng)的標(biāo)準(zhǔn)，上圖顯示了需求進(jìn)入開發(fā)環(huán)節(jié)要滿足的輸入標(biāo)準(zhǔn)，在這個(gè)例子中，它被定義為：
1)需求的用戶使用流程和驗(yàn)收規(guī)則清晰定義;
2)依賴方能夠被識(shí)別;
3)大的需求拆分成在兩周以內(nèi)或者一周以內(nèi)的小需求，等等。
我們還可以定義其它階段的規(guī)則，如開發(fā)輸出(也就是轉(zhuǎn)測(cè)試)的規(guī)則。這也是照亮關(guān)鍵所在一部分。
照亮關(guān)鍵所在，看到需求端到端流動(dòng)的過程，以及流動(dòng)中的問題和瓶頸是第一步。更關(guān)鍵是看到問題后要怎樣做?以可視化端到端的價(jià)值流動(dòng)為基礎(chǔ)，我們希望價(jià)值能夠順暢流動(dòng)，從左到右，不要發(fā)生停滯和積壓。如何做到呢?讓我們?cè)倏匆粋€(gè)故事。
圖中這位叫潘季馴，他是明朝治理黃河的水利專家，被稱為“千古治黃第一人”，我們今天要講的就是他治理黃河的故事。治黃河難，難在泥沙不斷淤積。清淤是治理黃河的傳統(tǒng)辦法，問題是清了又會(huì)淤，年復(fù)一年。大批的河工聚集，又為造反提供條件，元朝的覆滅就與之關(guān)系甚大。不治則生靈涂炭，治則勞民傷財(cái)，這是擺在歷代統(tǒng)治者面前的兩難決定，明朝也不例外。
嘉靖到萬歷年間潘季馴四次臨危受命治理黃河，取得前所未有的成效，并總結(jié)了切實(shí)可行的方略，其中最為重要的思想就是“束水攻沙”。什么是“束水攻沙”呢?潘季馴在治理黃河時(shí)既沒有蠻力清淤，也不是一味地加高、加寬河堤。他反其道而行，收窄河堤——在大堤(稱為遙堤)內(nèi)再修筑一道更窄的堤(稱為縷堤)，遙堤用以防潰，縷堤用以束水。河堤收窄了，水流的速度就會(huì)加快，將沉積的泥沙帶走，這就是所謂"束水攻沙"。
“束水攻沙”與產(chǎn)品開發(fā)有什么關(guān)系呢?“束水”加快了水的流速，也帶走了泥沙。對(duì)應(yīng)的，產(chǎn)品開發(fā)中我們也要限制并行需求的數(shù)量，同樣是為了縮短需求從開始到完成的平均交付周期——加快流速，并即時(shí)發(fā)現(xiàn)和處理交付過程中的問題——帶走泥沙。我們來看具體的例子。
在上圖中，泳道數(shù)約束了并行需求的數(shù)目。并行需求減少，需求流動(dòng)的速度隨之加快，從而縮短開發(fā)和交付周期。更重要的是，限制并行能更快暴露問題。有限泳道中的需求發(fā)生阻塞，很容易被發(fā)現(xiàn)。團(tuán)隊(duì)必須盡快解決阻塞的問題，才能開始新的需求。而即時(shí)解決問題又促進(jìn)了價(jià)值的順暢流動(dòng)。
基于端到端的價(jià)值流，團(tuán)隊(duì)可以更好地管理價(jià)值流動(dòng)。以站會(huì)為例，團(tuán)隊(duì)在站會(huì)上，會(huì)去審視需求的狀態(tài)。這里面有兩個(gè)策略，一種是從左向右審視，還有一個(gè)從右往左審視，大家認(rèn)為哪個(gè)合適?對(duì)，大家都說從右往左。為什么呢?因?yàn)槲覀儜?yīng)該聚焦于完成而不是開始，我們應(yīng)該聚焦于盡快地交付，比如測(cè)試中的需求是不是有缺陷，并優(yōu)先解決這些缺陷，好讓需求盡快上線;開發(fā)中的需求，有沒有阻礙，并即時(shí)解決這些阻礙，完成它們。只有這樣，新的等待開發(fā)的需求才能夠開始。
站會(huì)的核心是通過審視價(jià)值流動(dòng)，關(guān)注需求流動(dòng)中的缺陷、阻礙、停滯、等待和瓶頸，即時(shí)發(fā)現(xiàn)和解決這些問題，促進(jìn)需求更流暢流動(dòng)。站會(huì)只是一個(gè)例子，圍繞看板的其他活動(dòng)，比如說度量數(shù)據(jù)分析和改進(jìn)行動(dòng)的制定，都是為了促進(jìn)價(jià)值流動(dòng)，而價(jià)值的順暢流動(dòng)是響應(yīng)能力、質(zhì)量和效率的保障。
(此電子看板截圖來自阿里云云效)
上面舉例用的都是物理看板，是為了讓大家更有體感。現(xiàn)在絕大部分團(tuán)隊(duì)，不管是阿里云，技術(shù)中臺(tái)還是閑魚，用的都是云效電子看板。經(jīng)過持續(xù)的優(yōu)化，電子看板操作體驗(yàn)已經(jīng)與物理看板接近。并且具備物理看板不具備的優(yōu)勢(shì)，比如：前面講到的數(shù)據(jù)度量都可以自動(dòng)生成，這對(duì)于發(fā)現(xiàn)問題和改進(jìn)很有意義，還有就是與其他系統(tǒng)如文檔和發(fā)布工具的無縫集成。這是優(yōu)酷電子看板的截圖。
看板幫助團(tuán)隊(duì)暴露問題，具體的改進(jìn)行動(dòng)還是要落實(shí)到不同方面的。我們可以用湖水巖石效應(yīng)來描述這一過程。這是一個(gè)湖，湖里有一些石頭。湖水比較深時(shí)，石頭都隱藏在湖面之下，但其影響是在的;當(dāng)湖面降低，石頭就會(huì)漸次暴露出來。
在產(chǎn)品開發(fā)中，石頭暗喻的是問題，而湖水的深度暗喻交付周期長(zhǎng)短(或并行需求的數(shù)目)。當(dāng)需求的交付周期長(zhǎng)時(shí)，問題被隱藏，我們看到的是平整的水面。只有水位降低，問題才會(huì)暴露。
以某個(gè)中間件團(tuán)隊(duì)的效能改進(jìn)過程為例。他們?cè)炔捎眯∑俨嫉哪Ｊ?，沒有持續(xù)集成和有效自動(dòng)化，以月度為周期交付產(chǎn)品，需求在月初集中開始，在月底集中轉(zhuǎn)測(cè)試和發(fā)布，對(duì)外交付質(zhì)量和效率一直不讓人滿意，內(nèi)部的協(xié)作也有很多問題，每次發(fā)布都異常痛苦，延期的情況時(shí)有發(fā)生，但大家對(duì)問題根源和解決方案卻各執(zhí)一詞。
在精益和敏捷開發(fā)實(shí)施過程中，我們首先做的是可視化價(jià)值流動(dòng)，并以此為基礎(chǔ)逐步減小并行需求的數(shù)目，力求需求的持續(xù)流動(dòng)——持續(xù)小批量的輸入、開發(fā)、轉(zhuǎn)測(cè)試和交付。在減小批量的過程中，問題逐漸暴露。
在這個(gè)案例中，為了做到小批量的流動(dòng)，首先暴露的是需求分析和拆分的問題，也就是如何將需求拆分成可以獨(dú)立測(cè)試、驗(yàn)證和交付的小的單元。通過引入“實(shí)例化需求”(一種需求澄清、分析和拆分的方法)等方法，這一問題得到了解決，開發(fā)和測(cè)試移交的批量明顯減小了。
很快新的問題又出現(xiàn)了，測(cè)試環(huán)境或移交給測(cè)試的版本總是不可用，需求還是不能順暢流動(dòng)，這時(shí)持續(xù)交付流水線的建設(shè)的重要性就凸顯出來。當(dāng)然持續(xù)交付流水線的建設(shè)也并不是一步實(shí)現(xiàn)的，一開始我們只是打通了管道，并引入了最基本的自動(dòng)驗(yàn)證，保證測(cè)試隨時(shí)都有一個(gè)可用的環(huán)境和版本可用。接下來才是自動(dòng)化對(duì)關(guān)鍵功能的覆蓋。在其后組織協(xié)調(diào)溝通，技術(shù)架構(gòu)等問題也漸次暴露。
過程中，我們感受到最大的好處是，盡管解決問題的過程還是比較痛苦，但我們可以集中精力一個(gè)時(shí)間解決一個(gè)被暴露的真實(shí)問題，而解決它們也會(huì)帶來立即可感知的受益，這大大提升了團(tuán)隊(duì)持續(xù)投入解決問題的動(dòng)力。
這個(gè)團(tuán)隊(duì)，多年未能解決的問題，在短短三、四個(gè)月內(nèi)被一一解決，在沒有投入額外資源的情況下，研發(fā)效能得到根本改善，質(zhì)量、響應(yīng)能力都有了質(zhì)的提升。我對(duì)此也深有感觸——研發(fā)效能改進(jìn)實(shí)踐的技術(shù)難度，并不比我們平時(shí)做的業(yè)務(wù)系統(tǒng)難。但為什么總是得不到實(shí)施呢?這個(gè)團(tuán)隊(duì)有做對(duì)了什么。
這里面的根本問題不是能力問題，也不是意識(shí)和態(tài)度問題。更重要的是：要讓團(tuán)隊(duì)看見問題，并且提供合適的路徑，一個(gè)時(shí)間解決一個(gè)問題，并且解決問題后要能看到立即的想過。
核心有兩個(gè)：
第一：“看見”，它的關(guān)鍵是看見系統(tǒng)，看見價(jià)值的端到端流動(dòng)，以此為基礎(chǔ)看到問題和改進(jìn)機(jī)會(huì);
第二：“路徑”，它的關(guān)鍵是小步快走，但每一步都要有可感知的成果。
圖中巖石的高低，從概念上反映了隨著并行的降低，問題逐漸暴露的大致順序。對(duì)不同的團(tuán)隊(duì)，問題和次序會(huì)不同。但相同的是，通過水位的降低，問題被漸次暴露和解決，產(chǎn)品交付的響應(yīng)能力、效率和質(zhì)量也會(huì)得到提升。我們的目標(biāo)并不是要把水位降到最低，而是要發(fā)現(xiàn)問題，讓需求能以較小的粒度順暢流動(dòng)，實(shí)現(xiàn)順暢和高質(zhì)量和持續(xù)的交付價(jià)值。
總結(jié)一下持續(xù)交付實(shí)踐。它關(guān)注從需求到開發(fā)、測(cè)試直至部署和運(yùn)維這些環(huán)節(jié)。它的目標(biāo)可以總結(jié)為兩個(gè)：
第一：讓價(jià)值順暢流動(dòng),這個(gè)我們已經(jīng)講了很多。之前講的實(shí)踐都能促進(jìn)價(jià)值的順暢流動(dòng)，如：看板、反饋改進(jìn)這些管理實(shí)踐，故事地圖、驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)這類技術(shù)實(shí)踐。
第二：讓流動(dòng)過程更加高效,這個(gè)我們前面沒有強(qiáng)調(diào)。補(bǔ)充一下，其核心是讓團(tuán)隊(duì)成員只需要關(guān)注帶來真正價(jià)值的業(yè)務(wù)邏輯，而不需要在其他工作上花費(fèi)過多時(shí)間。
我們看看除了業(yè)務(wù)邏輯，團(tuán)隊(duì)還會(huì)被那些工作影響?又如何減少這些工作?這里我們列舉了其中的一些：
可靠的交付流水線：讓團(tuán)隊(duì)不用擔(dān)心驗(yàn)證和部署的環(huán)境，步驟及流程。
容器技術(shù)(如Docker)：讓團(tuán)隊(duì)不必過多考慮構(gòu)建分發(fā)及運(yùn)行環(huán)境的問題。
Kubernetes：讓團(tuán)隊(duì)不用過多考慮容器應(yīng)用的部署、運(yùn)行、擴(kuò)縮容等工作。
Sevice Mesh：讓團(tuán)隊(duì)不用過多考慮分布式服務(wù)的通信。
Severless：讓團(tuán)隊(duì)不用過多考慮服務(wù)器的實(shí)體資源。
…
持續(xù)交付價(jià)值的能力是互聯(lián)網(wǎng)時(shí)代研發(fā)效能的核心。我們介紹了提升持續(xù)交付能力的度量，以及以流動(dòng)效率為抓手提升持續(xù)交付能力的實(shí)踐和路徑。
問題是，建立了持續(xù)交付能力就可以保證業(yè)務(wù)的成功嗎?顯然不是。持續(xù)交付能力是快速交付價(jià)值、獲取反饋并靈活調(diào)整的基礎(chǔ)。我們還必須以把持續(xù)交付能力轉(zhuǎn)化為有效的業(yè)務(wù)創(chuàng)新，帶來真正的業(yè)務(wù)成功。
【本文為專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
分享名稱：如何在2周內(nèi)交付85%以上需求？阿里工程師這么做
本文鏈接：http://www.dlmjj.cn/article/djciihh.html
