【以下為分享實錄，有删節】
我們為什麼要提升研發效能
随着5G、人工智能、IOT等新技術的迅猛發展，企業的業務都将構架在軟體和網際網路之上。軟體傳遞能力成為企業的核心競争力，随着市場競争的加劇，企業對研發效能的期望越來越高。
然而新技術、新業态的不斷湧現，又使企業的業務變得越來越複雜，各個團隊之間的協作也越來越困難，企業的研發效能呈現降低趨勢。“期望”與“現實”之間産生了巨大的“Gap”，正是我們要努力的方向。這就是為什麼我們要提升研發效能的根本原因。
提升研發效能的方向：持續地順暢高品質傳遞有效價值
為了提升研發效能，我們首先要知道是什麼影響了研發效能——我們究竟面臨怎樣的挑戰？這裡有三個“不等于”：
局部效率 ≠ 高效傳遞
如何提升“研發效率”，很自然想到是讓大家都忙起來，也就是提升營運、産品和技術人員（包括開發、測試和運維）的效率或延長工作時間。大家都忙起來，局部的效率可能是提高了，但這就意味着高效傳遞嗎？
很多時候，營運、産品、技術各自為戰，雖然都很忙碌，但是卻“不出活”。這個“活”不是由我們定義的，而是由使用者來定義的。使用者不會因為你的繁忙買單，隻會因為你的傳遞買單。
高效傳遞 ≠ 持續高效
我們如果做到了“高效傳遞”，就可以做到“持續高效”嗎？其實也不一定。有可能是你的團隊突擊加班了，暫時提升了傳遞效率，但是無法做到持續高效。也有可能你暫時産出了軟體，卻留下了一系列的技術債。軟體的品質很差，也沒有相應的測試去維護，也沒有去建立工程能力，還是不會持續高效的。
高效傳遞 ≠ 業務成功
即使我們做到了“高效傳遞”，甚至“持續高效”，那麼業務就一定會成功嗎？其實也不一定。你可能傳遞了很多需求，但這些不是使用者真正要的，使用者絕不會長久為此買單。你能不能吸引使用者、并留住使用者，産生利潤，這才是業務成功的關鍵。真正的業務成功，是要能解決使用者真正的問題，是以高效傳遞也不等于業務成功。
精益和靈活的方案是需要解決上面的三個問題：
• 從局部效率到高效傳遞，我們需要做到：順暢高品質傳遞。
• 從高效傳遞到持續高效，我們需要做到：持續地順暢高品質地傳遞。對于代碼設計和品質的長期維護和提高，持續工程能力的積累，持續傳遞實踐的實施等。
• 從高效傳遞到業務成功，我們需要做到：持續地順暢高品質傳遞有效價值。
至此，我們定義了問題，也分解了問題，并明确了方向：持續地順暢高品質地傳遞有效價值。
精益靈活研發實踐架構
精益靈活研發實踐架構分為三層，第一層是戰略和目标，主要包含使用者訴求、願景目标和戰略規劃。第二層是産品規劃層，這裡需要業務、産品、技術之間的靈活協作，将戰略和目标層的業務訴求形成業務訴求條目後錄入業務需求池，然後通過業務設計、産品設計、産品傳遞等環節，傳遞有效價值，并根據業務驗證結果，建立業務回報進行調整，最終達成業務結果。第三層是團隊傳遞層，在這一層需要産品和技術團隊高效協作，持續澄清，開發和驗證需求，并通過自動化傳遞流水線和持續傳遞機制實作快速傳遞需求。
如何實作精益靈活研發呢？我們需要做到以下四步：
第一步，我們需要打通端到端的業務價值流。什麼叫“端到端”呢？就是要關注從使用者的需求到使用者問題的解決這一全過程，而不是中間的某一個階段。這就需要我們的業務、産品、技術進行協作。
第二步，快速高品質傳遞，即更快更好地傳遞需求。
第三步，度量回報和持續改進。我們期望産品傳遞過程是可被度量的，同時可驅動傳遞團隊持續改進。
第四步，規模化實施。有了以上三步，其實還不夠，我們需要賦能整個企業或組織，進行規模化實施。
後面，我會詳細介紹這四步如何實施。
精益靈活研發第一步：打通端到端的業務價值流
可見，是協作的基礎。我們可以通過雲效的“看闆”實作端到端需求流動過程的可視化，如上圖所示在“看闆”的最左端是需求池，最右端是“已釋出”，其中包含了業務、産品、開發、測試和運維在内的端到端傳遞過程。打通端到端的業務價值流必須做到：使用者價值驅動，即每一個流動單元展現的都是具有使用者價值的業務需求；前後職能拉通，即拉通業務、産品、開發、測試等各個職能一起來看整個鍊路，始于使用者問題的提出，終于使用者問題的解決。
建立端到端的需求流動過程，并利用雲效看闆實作可視化，這是提升效能的基礎。下一步需要明确各階段的準入準出标準。
明确各階段的準入準出标準，即明确流轉規則，是内建品質的重要手段。團隊要達成對規則的一緻了解并共同守護和持續改進。
如上圖所示，從階段“業務讨論”開始到“已釋出”都需要有明确的準入規則。舉兩個具體的例子，一個是從“産品”流入“開發”的規則：
- 開發、測試和産品達成一緻，定義明确的驗收标準；
- 大需求，需拆分為工作量在兩周以内的故事；
-
與關聯方（如有）确認相關計劃；
-識别大的技術風險并定義應對方案；
- 涉及三位及以上開發人員的需求，指定需求負責人，負責協調進度。
第二個例子是從“開發”到“測試”的流轉規則：
- 通過持續內建環境的檢驗，部署在測試環境；
- 開發對照驗收标準進行了自測；
- 通過Show Case。
從“業務讨論”到“已釋出”每個環節都需要有一個明确的準入準出規則，這裡不再贅述，大家可以根據實際情況去定義自己的規則，這些規則不是一成不變的而是需要持續更新、持續疊代。
明确準入準出标準，是為了保證有品質的流轉。為了更好的達成業務效果，接下來需要建立業務價值回報閉環。
針對已上線的需求，經過一定的時間後（釘釘是需求上線後的7天，檢視業務效果，即T+7讀數會，不同業務可以根據自己的情況設定時長），根據産品規劃時明确的業務目标和要解決的使用者問題，去驗證業務目标是否已達成，使用者問題是否已被解決，然後做相應的優化和調整。
什麼樣的需求才能流轉到開發中呢？我們需要為傳遞團隊提供高品質的需求。在産品規劃層：需要聚焦端到端的流動效率，并形成價值回報閉環。而在團隊傳遞層：需要聚焦快速傳遞業務需求，并保證傳遞品質。當需求從“産品規劃層”流轉到“等待開發”這個階段的時候，需要“指派”給開發團隊。需求進入開發團隊後，開發同學會把它拆分為“任務”，比如說按照“前後端”會拆分為“前端任務”“後端任務”，針對無線端的任務會拆分為“iOS任務”“安卓任務”等。隻有當所有“任務”開發完成後，滿足“送出測試”要求了，才能“提測”。
精益靈活研發第二步：快速高品質傳遞
下面我們接着講精益靈活研發第二步，如何快速高品質傳遞。在軟體研發過程中，大多數的時間浪費不是協作上的等待，而是做了很多無價值的需求，以及需求不停地返工。是以發生在軟體開發之前的需求澄清工作至關重要。
如何做好需求澄清呢？首先，執行個體化需求。我們的經驗是業務、産品、開發和測試一起坐在一起，從場景出發，以使用者的操作執行個體來澄清需求。執行個體是具體的，其典型形式是：“在什麼情況下，做什麼操作，會得到什麼結果”。基于具體的執行個體，更加便于溝通中的雙向确認，保證了解的一緻和場景覆寫。
在需求澄清時需要注意：以終為始，確定需求輸入品質。如上圖左側的“三角”所示，首先要講解業務目标，也就是要解決使用者或業務什麼問題。 其次操作及操作流程，為了實作上面目标，系統需要支援哪些使用者操作？這些操作的流程是什麼樣的？再次是業務規則，各個操作步驟對應的業務規則是什麼樣的？業務規則會轉化成驗收标準。
完成需求澄清之後，我們進入第二步，驗收測試驅動開發，確定高品質的準入準出。如上圖所示：
- 需求進入開發團隊的隊列（等待開發）後，業務、開發和測試立即通過執行個體化需求活動澄清需求，用結構化的方式生成需求的驗收标準。
- 在開發實作這些需求的同時，團隊會将這些需求執行個體會轉化成測試用例，并把部分測試用例自動化，做到功能實作和自動化測試開發同步完成。
- 需求實作完成後，團隊會有加工好的測試用例來驗收這些需求。甚至可以将部分測試用例提前給到開發人員，讓開發提前進行自測。
以上形成的循環被稱為驗收測試驅動開發,這個研發實踐在阿裡巴巴集團内部和外部都得到大量應用，它重構了開發過程，可有效提升團隊的傳遞品質和效能。
當業務需求由産品規劃層進入到團隊傳遞層之後，會有兩種研發模式來完成需求的開發，持續傳遞模式和疊代傳遞模式。我們先來分享一個持續傳遞模式的實踐：限制在制品數量，提高傳遞速度。
如上圖在雲效的“看闆”上，我們可以看到這裡的一個“卡片”代表一個業務需求，在“開發中”後面有一個數字（上圖中是3），這代表着并行開發的需求數量。限制并行需求的數量，目的是盡快完成已開始需求，加速需求的流動。更重要的是，“限制并行”能更快暴露問題。因為并行開發的需求有限，當某個需求發生阻塞時，很容易被發現。
并行的需求又被稱為“在制品”。在雲效看闆上，所有已經開始，但還沒有完成的需求（或其他工作）都是在制品。限制在制品數量的基本原則是：“聚焦完成，暫緩開始”。一般而言，在制品數量越少，傳遞速度越快。源自“精益思想”的“利特爾法則”解釋了背後的原理，感興趣的同學可以自己去搜尋了解，這裡不再贅述。
雲效也支援疊代傳遞模式，并提供疊代管理、疊代需求管理、疊代活動管理、測試用例管理、缺陷管理、度量統計等功能，大家可以去雲效官網試用體驗。關于疊代傳遞模式(Scrum)業界有很多介紹，我們這裡不詳細讨論。
精益靈活研發第三步：度量回報和持續改進
怎樣知道研發團隊真的做到了高效傳遞呢？我們需要對研發效能進行度量， 并建立回報閉環，持續改進。
我們一般用“缺陷趨勢圖”來度量“傳遞品質”。如上圖所示，圖形的橫坐标是日期，橫坐标上方紅色豎條代表這一天發現缺陷數量；橫坐标下方綠色豎條代表當天解決的缺陷數量；橙色曲線代表缺陷存量。圖中左右兩個部分比較了兩種傳遞模式。
左半部分，團隊屬于小瀑布的開發模式。“疊代”前期，團隊集中設計、編碼，引入缺陷，但并未即時地內建和驗證。缺陷一直掩藏在系統中，直到項目後期，團隊才開始內建和測試，缺陷集中爆發。
小瀑布模式下，傳遞品質差，帶來大量的返工、延期和傳遞品質問題。該模式下，産品的傳遞時間依賴于何時缺陷能被充分移除，當然不能做到持續傳遞，也無法快速響應外部的需求和變化。并且這一模式通常都導緻後期的趕工，埋下傳遞品質隐患。
右半部分，團隊開始向持續傳遞模式演進。在整個疊代過程中，團隊以小粒度的需求為機關開發，持續地內建和測試它們，即時發現和解決問題。缺陷庫存得到控制，系統始終處于接近可釋出狀态。這一模式更接近持續釋出狀态，團隊對外的響應能力随之增強。
缺陷趨勢圖從一個側面反映了團隊的開發和傳遞模式。它引導團隊持續且盡早發現缺陷并及時移除它們。控制缺陷庫存，讓系統始終處于接近可釋出狀态，保障了持續傳遞能力和對外響應能力。
雲效其實已經有了這種“缺陷趨勢圖”，而且是自動産生的，不需要手動繪制。
我們使用“周期時間控制圖”來度量“傳遞效率”。如上圖所示，橫軸代表日期，豎軸是天數，一個一個藍色的點代表已經釋出的需求。期望這些藍色的散點進行如下分布：
1）縱向上向下集中——需求傳遞周期和開發周期越短，業務響應能力及其可預測性越高；
2）散點密度提高——散點密度越高代表釋出頻率越高，釋出的能力就越強；
3）橫向上更均勻分布——橫向上的需求分布是均勻的，代表是持續傳遞的。
在度量一個研發團隊的傳遞效率時，我們會看這些散點分布的趨勢是否是往下走的，如果是往下走的，說明傳遞效率在變好。此外，還會看“控制線”，在上圖中，我們看到這個研發團隊的周期控制線是13天，這表示85%的需求周期時間都要小于13天，這也代表了該研發團隊的傳遞效率。
在雲效上也提供了“需求開發周期控制圖”，同時提供了“需求開發周期報表”，這個報表不但包含了“吞吐量”，還包含這個需求是多長時間内傳遞的等資訊。
在阿裡巴巴集團内部，也有一套可行動的效能度量體系，包含需求響應周期、持續釋出能力、傳遞吞吐率、傳遞過程品質、傳遞品質等五組名額。
這五組度量名額内容又被歸納為三個次元，即流動效率、資源效率和品質保障。其中，持續釋出能力和需求響應周期這兩組名額反映價值的流動效率；傳遞吞吐率反映資源效率；傳遞過程品質和對外傳遞品質這兩組名額共同反映品質水準。用六個字來概括這三個次元就是：又快、又多、又好。
有了度量标準之後，我們還要建立效能回報和改進閉環，才能更好地提升研發效能。
通過日常回報，品質和傳遞效能的回報，并定期進行複盤分析，形成流程操作、基礎設施、代碼與設計、傳遞及測試守護和人員技能等五個方面的改進行動，然後持續回報、分析和改進。
在實際的操作中，我們發現經過複盤會議後，會産生一些“改進的行動項”，但是這些“Action”的跟進卻很困難，往往跟着跟着就跟丢了。在雲效當中有一個比較實用的功能，可以将改進的行動項轉換成督辦任務進行跟進，讓行動項妥妥落實，持續促進組織效能提升。
精益靈活研發第四步：規模化實施
在講“規模化實施”之前，我們先來學習一句話。斯蒂芬·丹甯（Stephen Denning）曾說“我們需要的是靈活的規模化，而不是規模化靈活（方法）”。什麼意思呢？我們希望持續地順暢高品質傳遞有效價值的能力被規模化，而不是簡單地規模化這種方法。
如果一個研發團隊做到了前面三步，即“打通端到端的業務價值流”“快速高品質傳遞”“度量回報和持續改進”，我們認為該團隊具備了持續地順暢高品質傳遞有效價值的能力，但是這還不夠，我們需要将這種能力規模化，并賦能整個企業。
前面主要講述的是“單産品單傳遞團隊”的靈活研發模式，下面我們來看一下如何将這種能力拓展至“單産品多傳遞團隊”及“多産品多傳遞團隊” 。
如上圖所示，是一個“單産品線多傳遞團隊”的案例。在産品規劃層，具有一個産品線看闆， 管理業務需求的端到端價值流，并将準備好的需求配置設定給負責任的開發團隊（指派給傳遞團隊1或傳遞團隊2）。在傳遞團隊層，有兩個獨立的傳遞團隊，他們的操作其實跟單産品線單傳遞團隊時并沒有不同。隻需要接受業務需求，分解開發任務，管理需求的開發和傳遞過程，快速傳遞。
在企業中也常常會出現“多條産品線多傳遞團隊”的情況，比如下圖所示是一家物流企業的實際案例。
他們有三層看闆。第一層是公司級業務營運看闆，關注公司戰略的落地，如各業務線的投資組合，各業務單元的目标和關鍵結果，跨業務線的協作群組合創新等。第二層是産品線看闆，主要關注産品需求價值流，如端到端需求流動過程，目标回報閉環等。第三層是傳遞團隊層，主要關注團隊快速傳遞需求，如高品質快速傳遞，效能回報閉環等。
我們可以看到每條産品線都對應多個不同的傳遞團隊，如果各個産品線之間沒有任何“交叉”就比較簡單了，操作方式類似前面提到的“單産品線多傳遞團隊”模式。但是也可能出現“跨業務線協作”，這就需要在産品規劃層進行拉通。比如在這個例子中“生活業務線産品” 的某個功能可能要依賴“中台業務線産品”的某個功能，生活業務線的産品經理就需要将開發需求“指派”到“傳遞團隊14”，讓“傳遞團隊11”和“傳遞團隊14”協作完成需求的開發。
總結
前面我們講到了提升研發效能的方向是要持續地順暢高品質傳遞有效價值。介紹了靈活研發實踐的三層架構：目标層、産品規劃層、團隊傳遞層。最重要的是精益靈活研發的四個步驟：打通端到端價值流；快速高品質傳遞；度量回報和持續改進；規模化實施。
以上内容整理自洪永潮(舍衛)的直播分享《業務驅動的精益靈活實施》，感興趣的開發者可以進入雲效研發效能交流釘釘群（群号：34532418）入群觀看視訊回放。
【關于雲效】
雲效，企業級一站式DevOps平台，源于阿裡巴巴先進的研發理念和工程實踐，緻力于成為數字企業的研發效能引擎！雲效提供從“需求 ->開發->測試->釋出->運維->營運”端到端的線上協同服務和研發工具，通過人工智能、雲原生技術的應用助力開發者提升研發效能，持續傳遞有效價值。
【雲效官網】
https://www.aliyun.com/product/yunxiao【公測指南】
https://developer.aliyun.com/article/756207【申請公測】
https://devops.aliyun.com【學習路徑】
https://help.aliyun.com/document_detail/153739.html【開發者社群】
https://developer.aliyun.com/group/yunxiao【精彩活動】雲效公測開啟 「産品體驗官」招募中~
https://www.aliyun.com/activity/yunxiao/Beta2020 歡迎掃碼加入雲效開發者交流群