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

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

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

以下是精彩視頻內容整理：

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

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

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

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

顯然，絕大多數互聯網產品都應該按照敏捷的方式進行開發(fā)。根據敏捷思想，閑魚團隊對現有的軟件開發(fā)方式進行轉型、提效。

閑魚轉型提效策略

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

·需求側：明確目標、打法、功能，確定產品需求組織，將需求拆分、針對性溝通；

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

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

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

業(yè)務為導向的跨職能合作

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

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

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

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

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

按需求進行協作和流動

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

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

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

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

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

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

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

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

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

讓功能服務關聯目標

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

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

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

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

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

度量數據服務轉型提效

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

更多數據度量維度參考云效度量功能

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

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

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

更多數據度量維度參考云效度量功能

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

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

更多數據度量維度參考云效度量功能

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

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

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

對于產品交付之后的反饋機制，我們仍在努力中。下一步的工作一是建立功能業(yè)務閉環(huán)，首先確定產品階段目標和打法；之后快速進行功能需求交付；此后再根據運營數據的反饋和分析，再確定下一階段的產品目標和打法，形成功能業(yè)務閉環(huán)。

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

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

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

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

·持續(xù)測試分層

·自動化

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