摘要：本文以證券行業的某頭部企業的重點產品為例，探討基於行業特徵，同時脫離現成框架的規模化敏捷實施的實踐總結。
說到規模化敏捷，大家通常馬上會想到市場上的各種主流框架。誠然，現成的框架能與企業現狀較好結合的時候，基於框架的實施是省時省力的。
然而，實踐中我們經常會遇到的情形是，企業的情況千變萬化，往往跟框架的假定相去甚遠，有時候應用現有框架代價巨大，甚至產生削足適履的效果。本文以證券行業的某頭部企業的重點產品為例，探討基於行業特徵，同時脫離現成框架的規模化敏捷實施的實踐總結。
01我們眼中的規模化敏捷
如何在產品研發中凝聚力量以快速捕捉市場機會、使之轉化為業務收益，並持續地做到這一點，是很多大型組織需要解決的問題。具體而言，複雜產品開發中，
- 如何讓共同的目標凝聚多個敏捷團隊？
- 多個敏捷團隊如何協作？
- 如何快速地、持續不斷地推出新的產品功能？
- 如何控制協作的複雜度以降低管理成本，並減少系統瓶頸？
- 如何保持透明性，使產品研發的過程可見，使風險和障礙容易顯現，並被移除？
- 如何不斷演進自己以適應環境的變化？
在我們看來，規模化敏捷的本質是應用精益、敏捷的思想和實踐來尋求這些問題的解決方案。
02從五個核心能力看規模化敏捷實踐
規模化敏捷可能有無數的剖析視角。我們認為，從具體實踐落地的角度，規模化敏捷最依賴於五種核心能力：
目標對齊，節奏，同步，依賴解耦，持續改進
我們可以基於這些核心能力衍生、演進實踐，使組織能夠勠力同心、快速應變。本節將以某重點產品為例，介紹基於這五種核心能力實踐中如何幫助產品開發。
圖 1 規模化敏捷的五種核心能力
下圖展示了所述產品上下文。自外而內的兩層橢圓中，外層表示產品所屬投資組合，內層表示本文字產品範圍。產品內部包含多個相對獨立的應用，每個應用設有Scrum Master (SM)和Product Owner （PO），圖中的兩個應用作為示意。各應用均基於Scrum方式搭建團隊，每個應用包括若干專職、固定的Scrum小組。
值得注意的是：本產品內所包括的應用往往同時被投資組合中的其他產品所依賴，這形成了複雜的相互依賴關係，形成了產品開發活動的一個關鍵制約因素。
注：下文所提到的“Scrum Master”（SM）、“Product Owner”(PO) 均為各應用級別角色，他們通常負責多個Scrum團隊。
圖 2 產品範圍及主要活動
（產品協作會：各應用PO主導、協作定義優先順序
計劃協作會：各應用SM主導、下一迭代排期，兼上一迭代回顧
介面對齊點，在迭代開始之前確定相依賴產品之間的介面）
2.1目標對齊
你大概聽過這個故事：
工地上三個石匠在忙碌。路人問，你們在做什麼？第一個石匠說，我在砌牆。第二個說，我在掙錢養家。第三個說，我在建一座大教堂。
人們常常讚歎第三個石匠的格局，但第一個石匠可能過於被“順便”輕視了。的確，我們心中應該有我們在修建的大教堂，那是使命所在。然而，眼前要砌的這堵牆是否該是當前關注的焦點？
從目標對齊的角度而言，我們需要基於長期業務目標，但更要能夠：
- 將作為遠景的大目標分解為短期的小目標，
- 使相關人和團隊的“小目標”指向一致，
- 使相關團隊在實現小目標的過程中步調一致。
長期的大目標給我們方向，短期的小目標讓我們聚焦。大、小目標的對齊讓我們能夠勠力協作，然後才能持續快速交付。
產品的目標對齊由以下三個關鍵活動驅動。
圖 3 三個關鍵活動驅動產品目標對齊
產品協作會及其先導活動
基於業務價值並考慮相互依賴關係，產品各PO共創進行需求拆分和優先順序排序(必要時業務裁決)。產品協作會輸出下一迭代所需排期的需求列表。
產品協作會是一個線下與線上結合的活動，絕大部分實質性工作發生在會議之前。PO們在會議之前需要深入分析需求，並與相關方充分溝通；會議更多是一個查漏補缺的檢查點。
表1 產品協作會
（注：每個迭代兩週時間；W: 當前迭代第一週；W+1: 當前迭代第二週；W-1: 迭代開始前的一週…其他類推。）
計劃協作會及其先導活動
基於產品協作會產出，產品各應用的SM協作排期。（如前所述，“SM”是一個應用的Scrum Master，背後可能有多個Scrum小組。）
協作排期本質上是從傳統Scrum計劃會議抽取出了產品級的計劃工作（之後Scrum小組會在迭代計劃會中各自進行詳細計劃）。
與產品協作會類似，絕大部分實質性排期工作同樣發生在會議之前的線下溝通中。
表2 計劃協作會
介面對齊點
基於計劃協作會產出，各產品架構定義相互依賴的介面；迭代開始之前（W-1周）確定相互依賴的各應用介面。這個活動是迭代計劃會的一個跟進，也是迭代中聯調工作的序章。
表3 介面對齊點
可以看到，此產品的對齊機制結合了少量例行活動和大量線下溝通：產品協作會與計劃協作會類似，會議作為對齊點，但實質性工作大部分都發生線上下；介面對齊點更是僅僅作為一個檢查點存在。這與各通用的敏捷框架有明顯區別，比如SAFe、LeSS都在不同程度上強調大規模集體計劃活動。
之所以有這樣的不同，背後原因有二：第一，該產品所屬投資組合是多個相關聯產品的叢集，多個價值流交錯；產品所依賴的很多應用同時服務於投資組合內的其他產品，這與SAFe或LeSS典型場景中的唯一解決方案顯著不同。第二，產品開發中廣泛使用的合作方（外包）員工目前還不能深入參與到早期需求活動中。
在這種複雜場景下，大規模集體計劃很難保證效率。相形之下，本產品所採用的對齊方式以去中心化的、漸進式的計劃方式為基礎，以集中的檢查點為制約，對類似情形有參考價值。
2.2 節奏與同步
如果你參加過拔河比賽，你可能知道，站在旁邊喊號的人很大程度上決定了比賽勝負。喊號實際上是對節奏的控制。在比賽中利用穩定節奏製造衝擊波，是獲勝的一個訣竅。
規模化軟體開發對節奏的依賴也如拔河。各相關產品基於固定的迭代節奏互相配合，重要活動可預期、可管理，才能在團隊之間形成合力並免於混亂無序。
同步發生在節奏之中，包括正式和非正式活動，基於資訊共享促成合作，在目標對齊的前提下使人們有機會在整體上權衡取捨。
本文所述產品所在投資組合範圍內的應用共同使用兩週為單位的同一個迭代節奏。對高度關聯的產品而言，這樣統一拉齊的節奏有利於目標對齊。
截止我們寫作本文時，迭代節奏以及其中的主要活動如下圖所示。
- “跨產品優先順序共創”比開發迭代提前2個週期。其主要活動是前文已述的“產品協作會”，作為研發的觸發器。
- “需求梳理與跨迭代排期”為開發迭代提供直接輸入，包括需求溝通活動、介面同步活動以及需求的分析與設計。這些活動比開發迭代提前1個週期。
- “開發迭代”是主要的價值產生階段。開發迭代內部有聯調控制點，表示跨系統聯調的控制開始時間；還有提測控制點表示提交系統測試的控制開始時間，不同小組略有區別。
圖 4 迭代節奏與其中的同步活動
同一節奏為多產品目標對齊和研發協作提供了可靠的心跳，是穩定交付的基礎。
受限於目前的人員狀況，當前節奏設計仍然略偏複雜：該產品的相當部分開發及測試工作由合作方完成，合作方員工的高流動性導致難以形成積累，這導致更多管控需要和相應流程環節——這裡有待繼續探索簡化機制。
2.3 依賴解耦
規模化場景中，各團隊之間的依賴關係往往是效率殺手。“依賴解耦”就是應用各種方式減少、控制依賴，使團隊的工作能夠儘可能獨立。有觀點甚至認為規模化敏捷的本質是“去規模化”，也就是通過研發組織之間的解耦來降低組織協作的複雜性。完全的組織解耦未必可行也未必最優，解耦的最佳投入產出點需要通過探索來逐漸逼近。本產品採用的典型嘗試包括長期的基礎業務能力解耦和短期的旅客機制。
基礎業務能力建設
基礎業務能力體現為多應用共享的公共服務。抽取基礎業務能力是降低系統複雜度的一種嘗試，這裡的關鍵是儘量避免公共服務成為業務開發的依賴。
IT部門的天職是迅速、高質量地響應業務需求。然而由於資源有限，短期和長期的響應能力是一對矛盾。著眼短期，我們需要以全部人力盡可能快地響應業務請求；而長遠看來，我們需要為基礎業務能力建設留出人力，因為成熟的基礎業務能力支撐可使應用功能開發事半功倍。（注意：這個實踐的嘗試需要慎重，基礎業務能力如果無法做到較高的獨立性，很可能會產生適得其反的效果。）
我們在本產品開發中採用了一種漸進建設基礎業務能力的思路。
如下圖：作為遠景，期望中的基礎業務能力與應用產品開發應該是解耦的，基礎業務能力開發應具有適當的前瞻性和成熟度，聚焦公共服務，支撐應用開發。
不過，當前基礎業務能力範圍還包括為“應用特定服務”部分，其內容與特定應用仍有緊密耦合。
為保障業務響應速度，“應用特定服務”部分要緊跟應用開發的節奏；同時，相關開發人員需要與基礎業務能力部分（尤其是架構師）保持緊密合作，並受業務能力的基礎設施和規則制約，以備相關功能平臺化。
長期看來，隨著基礎業務能力的完善，“應用特定服務”部分的軟體功能應向上下兩個方向分化 – 部分沉澱為基礎業務能力的通用服務，部分上升合入業務需求開發。
圖 5 應用功能與基礎業務能力開發的平衡
旅客機制
敏捷團隊應該基於價值組織。而同時，敏捷團隊也應該保持穩定。然而，這兩個原則有時是衝突的。當有衝突的時候怎麼辦？這裡我們借鑑了LeSS中的旅客概念（是借鑑而非借用 - LeSS中的旅客更傾向於目標團隊賦能，而在我們這裡旅客的首要目的是需求交付）。
如果某個迭代，基礎業務能力有較多的某特定應用開發工作，則基礎業務能力團隊研發工程師可作為“旅客”臨時加入應用，按照應用優先順序工作。這種做法的作用有：
一，降低團隊之間的耦合程度，從而降低協調複雜度（跨團隊溝通轉化為團隊內溝通）。
二，平衡基礎業務能力開發與應用需求開發。在這二者之間，可上可下的旅客制提供了靈活性。
三，促進基礎業務能力與業務應用合作緊密度，使基礎業務能力開發保持業務敏感。
當然，旅客機制只是一種可能的嘗試，遠不是銀彈。在這種多價值流交錯的情況下，我們需要在“消除依賴”和“管理依賴”之間尋找一種平衡。
2.4 持續改進
工作方式演進
基於對精益敏捷理念的把握和實踐中得到的反饋，產品研發實踐在一直不斷地調整、適配。
在不同範圍內，持續改進機制的主要承載活動包括：
（1）Scrum小組的迭代回顧會
這是源於經典Scrum框架的基本檢視調整活動。
（2）應用內的SoS例會
應用內的SoS例會有兩個作用：一是日常工作的同步，二是對開發過程中問題的及時回顧和改進。這種及時回顧產生的改進事項會記錄在Wiki中，並在下一次會議中檢查結果。各個回顧活動強調自下而上的問題發現，領導層致力於幫助團隊解決問題。
（3）產品範圍的迭代協作會
前文“目標對齊”部分已介紹此活動，這裡不再贅述。
從規模化敏捷實踐中獲得的收益
（1）規模化場景中特別需要避免各團隊各自為戰。本產品的對齊機制設計基於多應用的優先順序共創，各應用協作產生每個迭代所需完成的功能列表、所需支撐的業務目標，使得各個應用有同認可的目標，這成為應用間協作的堅實基礎。
（2）多應用統一的節奏為產品開發中的各個事件提供了可靠的過程框架。同一節奏方便了去中心化的同步活動，並以例行的（中心化的）檢查點及配套工具（Wiki，Jira）增強透明性，確保去中心化活動的質量。這在簡化溝通、協作的同時，有效地暴露進而消除了迭代執行中的障礙。
（3）需求與實現的雙重迭代週期（輔以清晰的流程、角色、職責）使需求的梳理活動嚴謹有序，產品規劃與需求實現有規律地交疊推進。
03 當前面臨的主要挑戰和仍在進行中的探索
多價值流交錯情形之下，規模化的演進方向
前文已述，本產品所屬投資組合面臨的是多產品並存且相互依賴，多價值流交錯的複雜場景。在此情形下，現成的規模化框架並不能提供系統的解決方案，必須探索自己的方式。我們正在進行的探索基於對如下幾個關鍵點的考量：
第一，多產品目標對齊。在投資組合範圍內，把多個產品所形成的網路看做一個價值流網路整體，這個網路有共享的業務目標。我們正在努力的一個方向是：以多應用的優先順序共創為基礎，以路線圖支援長期組織戰略（長期目標對齊），以使多個應用能夠集中力量，在同一釋出中分兵協作，共同支援跨產品的業務需求（短期目標對齊）。
第二，去中心化協作。價值流網路越龐大複雜，大型的集體活動和決策就越昂貴，我們就越需要依賴於去中心化的協作方式。這與員工賦能相輔相成，我們依賴於優秀的員工高度自主地、高質量地完成他們各自的產出，更依賴他們與合作伙伴的緊密協作、相互支援。
第三，透明。去中心化的場景下，我們更需要有效的度量設計，形成過程和度量的整體檢視，從而能夠暴露需要關注的需求開發問題，以及系統性問題。這樣，我們才有機會在去中心化的同時，為需求開發過程去除障礙，並避免混亂無序。
“大需求”的支援：一個具體的挑戰
影響投資組合範圍內多個產品的“大需求”尚未完全納入對齊機制和迭代節奏：目前，大需求往往基於固定交付時間點獨立排期、一次性驗收，在迭代節奏之外運作。
對此，我們正在試圖將大需求按照“MVP+增量”的方式進行拆解，並基於此強化投資組合範圍內的對齊機制，使大需求開發納入同一迭代節奏，並相應地通過視覺化看板提供整體檢視。
圖 6 大需求的MVP拆分方式示意
最後
本案例規模化敏捷探索已經進入深水區。在致力於探索這些深層次問題的解決之道的同時，我們希望在本產品開發中所做的這些探索能夠對你有參考價值，同時也歡迎跟我們一起探討規模化敏捷開發的實踐。