摘要：摘要在第二屆研發(fā)效能嘉年華專場上，來自阿里巴巴集團研發(fā)效能張燎原為聽眾帶來了跨越敏捷閑魚研發(fā)效能升級之路的精彩分享。根據(jù)敏捷思想，閑魚團隊對現(xiàn)有的軟件開發(fā)方式進行轉(zhuǎn)型提效。

摘要： 在2018第二屆研發(fā)效能嘉年華專場上，來自阿里巴巴集團研發(fā)效能張燎原為聽眾帶來了《跨越敏捷 — 閑魚研發(fā)效能升級之路》的精彩分享。在分享中，他從以業(yè)務(wù)為導(dǎo)向的跨職能協(xié)作、按需求進行協(xié)作和流動、讓功能服務(wù)關(guān)聯(lián)目標(biāo)、度量數(shù)據(jù)服務(wù)轉(zhuǎn)型提效四個方面詳細闡述了閑魚敏捷轉(zhuǎn)型之路。

在2018第二屆研發(fā)效能嘉年華專場上，來自阿里巴巴集團研發(fā)效能張燎原為聽眾帶來了《跨越敏捷 — 閑魚研發(fā)效能升級之路》的精彩分享。在分享中，他從以業(yè)務(wù)為導(dǎo)向的跨職能協(xié)作、按需求進行協(xié)作和流動、讓功能服務(wù)關(guān)聯(lián)目標(biāo)、度量數(shù)據(jù)服務(wù)轉(zhuǎn)型提效四個方面詳細闡述了閑魚敏捷轉(zhuǎn)型之路。

以下是精彩視頻內(nèi)容整理：

VUCA時代瀑布開發(fā)方式的弊端

當(dāng)今時代又被成為VUCA時代，在這樣一個時代里，越來越多的企業(yè)和組織都面臨著軟件開發(fā)的轉(zhuǎn)型。根據(jù)摩爾定律和反摩爾定律，企業(yè)應(yīng)該盡可能地縮減產(chǎn)品的研發(fā)周期。

然而，在絕大多數(shù)軟件開發(fā)過程中，傳統(tǒng)的軟件開發(fā)策略采用的是瀑布式開發(fā)方式，尤其是一些傳統(tǒng)型企業(yè)，通常會保留幾個月去做需求分析，再花費幾個月的時間去做設(shè)計、開發(fā)、測試，到最終發(fā)布，整體周期可能很長。而最早決定做什么是在產(chǎn)品的需求分析階段，也就是在產(chǎn)品項目知識最缺乏的時候進行的決定，這就是一個悖論，即在知識積累最少時，為產(chǎn)品的未來做來決定，決定產(chǎn)品的未來發(fā)展方向。

因此，在這種環(huán)境下，我們不能再采用傳統(tǒng)的方式進行軟件開發(fā)，而需要更新開發(fā)策略：在開始階段進行初始決策，在一個迭代周期之后，根據(jù)用戶的反饋、對產(chǎn)品的認知以及技術(shù)環(huán)境和市場環(huán)境的變化進行知識積累，此時再根據(jù)所積累的知識逐步進行增量決策和調(diào)整，也就是說迭代之后交付出去的產(chǎn)品特性能夠幫助我們驗證市場、用戶，幫助我們持續(xù)調(diào)整，進而使得我們在下一個迭代過程中再次試水，這種持續(xù)地反饋，讓我們不斷調(diào)整去適應(yīng)變化的能力，即敏捷力。

顯然，絕大多數(shù)互聯(lián)網(wǎng)產(chǎn)品都應(yīng)該按照敏捷的方式進行開發(fā)。根據(jù)敏捷思想，閑魚團隊對現(xiàn)有的軟件開發(fā)方式進行轉(zhuǎn)型、提效。

閑魚轉(zhuǎn)型提效策略

閑魚轉(zhuǎn)型提效策略首先明確了211目標(biāo)，即2周交付周期、2周開發(fā)周期以及1小時發(fā)布時長。對于確定的目標(biāo)，將其分解，利用交付散點、累積流圖、缺陷趨勢、發(fā)布效率等過程度量對其進行衡量。對其抓手，主要是從三方面展開：

·需求側(cè)：明確目標(biāo)、打法、功能，確定產(chǎn)品需求組織，將需求拆分、針對性溝通；

·交付協(xié)作側(cè)：保障業(yè)務(wù)價值流順暢，梳理工作流程，圍繞業(yè)務(wù)組織協(xié)作；

·反饋調(diào)整側(cè)：在整個開發(fā)過程中，需要不斷地進行反饋調(diào)整，可以通過效能度量、業(yè)務(wù)運營數(shù)據(jù)等進行復(fù)盤調(diào)整。

下面我們具體來進行分析。首先看一下團隊協(xié)作方面：

業(yè)務(wù)為導(dǎo)向的跨職能合作

在互聯(lián)網(wǎng)開發(fā)過程中，常常會發(fā)生一些讓人苦笑不得的事情：例如我產(chǎn)品設(shè)計已經(jīng)設(shè)計好了，剩下的就交給你們了，或是我代碼已經(jīng)全部編寫，剩下的就交給你你們了等等。這種就是我們在軟件開發(fā)過程中各種職能豎井的協(xié)作方式。在傳統(tǒng)的軟件開發(fā)過程中，經(jīng)常是以職能為單位進行相互協(xié)作。

如上圖所示，產(chǎn)品在其豎井里進行產(chǎn)品設(shè)計、開發(fā)在其豎井里進行開發(fā)、測試和運維也分別對應(yīng)著自己的職能豎井，彼此之間協(xié)作是靠“梯子”來完成，可想而知，在傳遞過程中效率是極其低下的。組織協(xié)作之間為了提高效率，通常會做一大批產(chǎn)品需求交付給開發(fā)，開發(fā)再將這一批需求開發(fā)完成后交給測試，測試再...在整個過程中產(chǎn)生了批量。在整個協(xié)作過程中，絕大多數(shù)時間都是在等待，從用戶視角觀察，真正處理事情的時間很少（如上圖綠色線條所示），整體效率相當(dāng)?shù)拖隆?/p>

在不同工作職能之間往往還存在博弈關(guān)系，例如產(chǎn)品經(jīng)理希望開發(fā)的功能越多越好，所需時間越短越好，而開發(fā)人員則希望盡可能減少開發(fā)需求，并增加開發(fā)時間以實現(xiàn)功能完善。那這個問題應(yīng)該如何解決呢？

我們采用的解決方案是從職能之間的拋接變成以業(yè)務(wù)為導(dǎo)向的跨職能合作，將項目所涉及的人員按業(yè)務(wù)進行區(qū)分，例如A業(yè)務(wù)包含自己的PD、UED、前端、后端和測試。這種以業(yè)務(wù)為目標(biāo)的組織方式，所涉及的人員的目標(biāo)就變成了從完成對應(yīng)的任務(wù)，到盡快交付特定業(yè)務(wù)需求；另外，這種組織方式使得開發(fā)、測試、前端等之間的溝通變得順暢，大家基于相同的上下文進行探討，提高了溝通效率。之所以仍保留職能團隊，是為了促進個人的技能培養(yǎng)。因此，從業(yè)務(wù)交付角度出發(fā)，以業(yè)務(wù)能導(dǎo)向組建跨職能團隊；從人員技能培養(yǎng)方向出發(fā)，以職能為導(dǎo)向組建職能團隊。另外，我們也提倡在一段相對固定的時間內(nèi)，團隊成員比較固定在某一業(yè)務(wù)團隊、服務(wù)某一特定業(yè)務(wù)，這種方式使得每個業(yè)務(wù)都有相對固定的人員配置，資源調(diào)配就更不容易出現(xiàn)瓶頸。；同時也支持一定的跨業(yè)務(wù)的人員流動，以保證人員對業(yè)務(wù)知識廣度的積累。

這是從人員的組織角度出發(fā)以業(yè)務(wù)為導(dǎo)向進行的跨職能合作，下面我們將從協(xié)作的角度出發(fā)來分析提效策略。

按需求進行協(xié)作和流動

在軟件開發(fā)的協(xié)作過程中，存在大量細節(jié)和合作，整體過程中很難去區(qū)分關(guān)鍵點所在。因此，可視化就顯得尤為有必要。

在閑魚提效轉(zhuǎn)型過程中，我們設(shè)計、制作了很多塊上圖所示的板。在上圖所示的白板上，首先明確了協(xié)作工作流，如需求開發(fā)過程中所經(jīng)歷的階段、上下游之間的關(guān)系；另外一點是所有步驟均是以需求為單位進行協(xié)作。板上藍色框中表示整體工作流，紅色五角星是確定每個需求的流轉(zhuǎn)規(guī)則。

為什么以需求為單位進行協(xié)作和流動？首先，我們交付給客戶的是業(yè)務(wù)價值、特性、功能。最早采用的任務(wù)板方式，發(fā)現(xiàn)所有人都很忙，每天做了很多事，但是一回溯，發(fā)現(xiàn)需求沒有完成。因此，關(guān)注任務(wù)板不如關(guān)注價值板，因此我們制定了上圖所示的需求價值版，關(guān)注價值的流動，讓價值更快的流動出去。價值板包括很多階段，上圖紅色框中包括橫向五條甬道，它表示在開發(fā)過程中，開發(fā)團隊最多只支持五個需求的并行開發(fā)。之所以限制并行的數(shù)量是為了提高縮短開發(fā)周期，使得需求更快速流動。

橙色框在價值板上呈現(xiàn)的是發(fā)版節(jié)奏，涵蓋web和移動端；圖中綠色框中表示的是可視化資源池，資源池中的每個人對應(yīng)兩個點，表示參與兩個需求，清晰地展現(xiàn)人員在需求上的配置。通過價值板，我們能夠清楚地看到需求累積的位置，上圖顯示需求累積在選擇階段，并且在視覺出現(xiàn)了中斷，這樣就很容易地可視化所有問題并定位。此外，通過價值板還可以關(guān)注發(fā)布版本的節(jié)奏，每天站會時從右往左溝通，是否有需求發(fā)布、灰度、測試、走查、開發(fā)，形成拉動的過程（優(yōu)先級自上而下）。最左下角是未來可能開發(fā)的產(chǎn)品和需求，提前確目標(biāo)和打法，提前組織和溝通。

有了這么一塊價值板之后，效果怎么樣呢？

上圖是之前和現(xiàn)在每天晨會的對比圖。之前是項目經(jīng)理同步項目進度和狀態(tài)，絕大數(shù)人都在做自己的事；而現(xiàn)在，以業(yè)務(wù)為導(dǎo)向的團隊在一塊板前做晨會，團隊中每一個人都在協(xié)調(diào)需求的流轉(zhuǎn)。

看板視圖取自云效公有云(https://www.aliyun.com/produc...

當(dāng)團隊成員處于異地工作時，在一塊物理板前開晨會不太現(xiàn)實。針對此類問題，我們將物理板升級為云效電子板，內(nèi)容同物理板相似，使得遠程同步變得更為簡潔。通過價值板的方式，我們將工作流程可視化出來，通過晨會、板上限制并行數(shù)目等方式控制價值流動。

那么價值板上需求和業(yè)務(wù)目標(biāo)存在什么關(guān)系呢？需求之間有哪些關(guān)系呢？業(yè)務(wù)目標(biāo)和需求之間的關(guān)系是什么呢？下面將從功能服務(wù)關(guān)聯(lián)目標(biāo)的角度回答這些問題。

讓功能服務(wù)關(guān)聯(lián)目標(biāo)

如上圖所示的過河，不同的人采用不同的方式，過河是目標(biāo)，從河上過是架橋、從河下過是挖隧道，如果打法不一致，顯然會對不齊。

在軟件開發(fā)過程中，我們也會面臨類似的問題，因為業(yè)務(wù)職能和開發(fā)職能面對的語言不同，業(yè)務(wù)職能面對是領(lǐng)域方面的概念，而開發(fā)面對的是某一設(shè)計模型、算法等。這時，如何打破業(yè)務(wù)職能和開發(fā)職能之間理解、溝通和協(xié)作的隔閡就顯得尤為重要了；另一個挑戰(zhàn)是業(yè)務(wù)目標(biāo)和產(chǎn)品功能之間的關(guān)系較為模糊，不一致。比如業(yè)務(wù)目標(biāo)是轉(zhuǎn)化率提高百分之三十，那么對應(yīng)的產(chǎn)品功能應(yīng)該增加什么呢？它們彼此之間的聯(lián)系是什么呢？

我們可以通過黃金圈法則的方法表示從業(yè)務(wù)目標(biāo)到產(chǎn)品功能項。如圖所示，在黃金圈的最內(nèi)層是Why，中間層是How，最外層是What。其中Why表示業(yè)務(wù)目標(biāo)，How表示的是業(yè)務(wù)打法或業(yè)務(wù)場景；What表示產(chǎn)品功能。通過Why、How、What的方式進行梳理，我們可以確定所開發(fā)的產(chǎn)品功能的業(yè)務(wù)目標(biāo)，也能夠很好確定功能需求的開發(fā)順序。

上圖是根據(jù)黃金圈規(guī)則制定的具體案例。從業(yè)務(wù)大圖中確定產(chǎn)品路徑，在產(chǎn)品路徑中根據(jù)業(yè)務(wù)目標(biāo)分解成若干個關(guān)鍵指標(biāo)，識別關(guān)鍵功能，要實現(xiàn)比如搜索相關(guān)性提高多少倍等關(guān)鍵指標(biāo)，針對不同的方式，采用的方式也不盡相同，這里分別列出來Why、How和What。這一路徑圖通常貼在價值板的旁邊，定期組織業(yè)務(wù)團隊同步目前所處的業(yè)務(wù)目標(biāo)、打法和功能，實現(xiàn)團隊的對齊。

前三部分更多講的是業(yè)務(wù)團隊、協(xié)作和功能識別，最后來看一下如何實現(xiàn)持續(xù)改進。

度量數(shù)據(jù)服務(wù)轉(zhuǎn)型提效

沒有度量的洞察，管理無異于盲人摸象。因此我們需要完整的度量數(shù)據(jù)或能夠提供洞察的數(shù)據(jù)來幫助我們識別所管理的對象。

更多數(shù)據(jù)度量維度參考云效度量功能

回到交付響應(yīng)周期/開發(fā)響應(yīng)周期上來，通過需求在不同階段的流動過程，很容易確定需求的前置時間、在某個階段的耗時。上圖左側(cè)顯示的是需求占用的時間較長（藍色表示需求時間、綠色表示開發(fā)時間），而右側(cè)圖需求階段和開發(fā)階段是1：1的關(guān)系，那么我們就需要思考為什么在需求側(cè)耗時這么久。

另外一個衡量方式是交付頻率、缺陷和累積分布。

交付頻率、缺陷和累積分布

更多數(shù)據(jù)度量維度參考云效度量功能

上圖分別是交付頻率、缺陷和累積流圖。需求交付散點圖中每一個點代表一個需求發(fā)布，縱軸表示發(fā)布時累積時間長度，橫軸表示發(fā)布的時間點；左側(cè)需求累計圖表示需求在不同階段累積的數(shù)量，高度表示積壓的在制品的數(shù)量，橫向可以確定其在某個階段的前置時間長度；缺陷趨勢圖中紅色柱子表示新發(fā)現(xiàn)的缺陷數(shù)目，綠色柱子表示當(dāng)天修復(fù)的缺陷數(shù)目，隨著時間推移累積而成。

度量或指標(biāo)存在兩面性，有時選擇的指標(biāo)不夠好時，對團隊整體的殺傷性非常大，因此應(yīng)該選擇好的度量或指標(biāo)。那么，如何確定好的度量或指標(biāo)呢？

更多數(shù)據(jù)度量維度參考云效度量功能

好的度量一是應(yīng)該簡單，不復(fù)雜；第二好的度量應(yīng)該表達是一個完整“故事”，而非某個信息點；第三好的度量應(yīng)該能夠觸發(fā)一個行動。正如需求在電子看板中呈現(xiàn)，在云效中，也可以將度量數(shù)據(jù)可視化，如上圖所示，可以展示需求累積流圖、有效缺陷平均關(guān)閉時長、缺陷趨勢圖、需求研發(fā)階段平均停留時長等數(shù)據(jù)，通過這些數(shù)據(jù)能夠幫助我們在研發(fā)效能進行改進。

未來發(fā)展規(guī)劃

建立功能業(yè)務(wù)閉環(huán)

對于產(chǎn)品交付之后的反饋機制，我們?nèi)栽谂χ?。下一步的工作一是建立功能業(yè)務(wù)閉環(huán)，首先確定產(chǎn)品階段目標(biāo)和打法；之后快速進行功能需求交付；此后再根據(jù)運營數(shù)據(jù)的反饋和分析，再確定下一階段的產(chǎn)品目標(biāo)和打法，形成功能業(yè)務(wù)閉環(huán)。

持續(xù)集成發(fā)布體系

未來的另一個工作重點是建立持續(xù)集成發(fā)布體系，主要包括如下工作：

·缺陷回顧分析機制的建立（RCA/EDA）；

·持續(xù)集成/發(fā)布管道的梳理完善；

·持續(xù)測試分層

·自動化

通過上述機制保障，能夠顯著提高產(chǎn)品發(fā)布效率。