【以下為分享實錄，有刪節】
我們為什麼要提升研發效能
隨著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
歡迎掃碼加入雲效開發者交流群