軟件企業大規模敏捷策略研究

陳 剛，賀晉寧

（中興通訊股份有限公司，江蘇 南京 210012）

軟件企業大規模敏捷策略研究

陳 剛，賀晉寧

（中興通訊股份有限公司，江蘇 南京 210012）

大規模敏捷開發是軟件企業的重要改進方向。文章對大型軟件開發的特點進行了分析，并比較了幾種業界常見的大規模敏捷開發方法，結合實踐經驗，提出了一系列針對性的策略，將有助于軟件企業成功實施大規模敏捷。

軟件；企業；大規模敏捷；策略

1 敏捷開發的產生

傳統的軟件開發方法是在20世紀70年代產生，有瀑布模型、螺旋模型、噴泉模型、RUP 4類，它們注重文檔的完整，程序的易讀性，結構的完整性，屬于重型軟件開發方法。隨著市場環境的變化，傳統軟件開發方法面臨著嚴重的挑戰。由此人們開始對軟件開發過程的本質重新進行思考和探索，在20世紀90年代，一系列輕量級開發方法相繼被很多軟件大師提出。2001年2月在美國猶他州的雪鳥滑雪場召開了軟件開發大會。本次會議發布了“敏捷宣言”，包括4個核心價值觀和12條基本原則，這標志著敏捷開發的誕生。

敏捷開發具有很多優點，例如不斷變化、充分發揮人的創造力和主動性、迭代開發過程中一直保持軟件產品的可用狀態等。這些優點吸引了越來越多的軟件企業研究和應用敏捷開發。

2 敏捷開發在小團隊中的應用

經過多年的業界探討和嘗試，在敏捷方法論層面Scrum和XP得到了廣泛認同。兩者被認為是針對新產品開發一個非常完美的搭配，從管理和技術兩個方面支持了敏捷開發的實施。

Scrum是一種輕量化的敏捷軟件開發管理框架，每隔1～4周，每個人都能看到能實際工作的軟件，并且據此決定是發布這個版本還是繼續開發以加強其功能，這樣將原先的長周期的開發過程切割成若干個小段，用戶反饋速度大大提升。一個Scrum團隊要求在5～9人之間。Scrum團隊包括3類角色：（1）產品負責人，負責維護產品訂單的人，代表利益相關者的利益；（2）Scrum Master，為Scrum過程負責的人，確保Scrum的正確使用并使得Scrum的收益最大化；（3）開發團隊是由負責自我管理開發產品的人組成的跨職能團隊。

極限編程（Extreme Programming，XP）是一種輕量級的、靈巧的軟件開發方法，同時也是一個非常嚴謹和周密的方法，其基礎和價值觀是溝通、簡單、反饋、勇氣和尊重。XP是一種近螺旋式的開發方法，將復雜的開發過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其他一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，并根據實際情況及時地調整開發過程。XP有13個核心實踐，同樣也被認為十分適合小團隊實施。

基于這兩種方法，瀑布式的小型軟件開發團隊（10人以內）可以在3～6個月內轉型為敏捷開發團隊，交付能力有機會獲得較大提升。當然，實施過程也有很多風險和困難，需要有周密的策劃，包括管理層支持、建立轉型小組、痛點驅動、迭代式改進、逐步應用各類實踐、系統化的敏捷培訓等。

3 大規模敏捷的困惑

早期的敏捷理論是針對小型團隊的，這也讓很多人認為敏捷開發只能在小型團隊中實施。不少軟件企業的敏捷開發起步也是從個別開發小組試點開始的，在取得初步成效后，會吸引更多的開發小組來實施敏捷。但這些小的敏捷團隊仿佛是在各自的孤島里，難以對企業的整體研發能力帶來結果性的影響。而在不少軟件企業，一個完整的軟件團隊會遠超一個Scrum團隊的規模。由此帶來疑惑，把一個大型軟件團隊都納入敏捷開發，實施大規模敏捷是否真的可行。

所謂大型軟件團隊通常是指幾十甚至數百人的規模從事同一產品的研發。為了方便項目管理及質量監控，大型團隊通常會使用瀑布模式，按照需求分析、概要設計、詳細設計、編碼、測試、軟件交付的流程來進行開發。每個階段都有相應的角色負責本階段的工作，由此需要定義多種角色包括需求分析人員、設計人員、開發人員、系統測試人員等。軟件企業為了支撐這樣的軟件開發過程，會實施矩陣式管理，一個項目會需要貫穿多個行政部門，而同一行政部門則要支持多個項目。由此，一個大型團隊會有若干個多部門的職能團隊組成。很顯然，在一個大型團隊實際運作的復雜度遠超小型團隊。而小團隊的痛點問題大型團隊都可能遇到，并且還會有大型團隊自身的痛點，特別是各職能團隊之間的協調問題，最容易引發各種矛盾，帶來內部的浪費，從而導致影響交付效率和質量。面對這些問題，經典的Scrum管理框架難以解決項目管理方面的挑戰。而XP方法論在人員較多的情況下，本身的高學習門檻的問題也會放大，阻礙導致團隊成員技術能力進一步提升。

4 大規模敏捷開發方法論

企業的難點也成了業界研究的熱點。在2010年以后，大規模敏捷開發方法得到了深入的研討和探索。大規模敏捷開發方法重點關注的是多個Scrum團隊比較緊密地工作在一個產品上的時候，必須解決不同團隊之間的協同的挑戰。目前有一些大規模敏捷的解決方案，最有影響力的就是敏捷方案管理（Scrum of Scrums，SoS）、大規模混亂（Large-Scale Scrum，LeSS）、規模化敏捷框架（Scaled Agile Framework，SAFe）。

4.1 SoS

當多個Scrum團隊工作在同一個產品上的時候，雖然努力想做到全功能的特性團隊，希望能在一個團隊里做完所有的事情，而不需要依賴其他的團隊，但這明顯只是一個非常理想的狀態；團隊之間不可避免會有依賴，需要協同。SoS的做法就是每個Scrum團隊選出1～2個代表，團隊的代表聚在一起分享進度和協同解決依賴。SoS非常簡單，其主要形式就是一個（或一系列）會議。最頻繁的情況是每天一次，最少的情況下是每周一次。在SoS會議上，各團隊的代表需要回答4個問題：從上次會議到現在你們團隊做了哪些任務？到下次會議之前你們團隊計劃完成哪些任務？你們團隊有哪些困難需要其他團隊協助的？你們有沒做什么會影響其他團隊工作的決定的？

需要注意的是SoS相對比較簡單，可以幫助Scrum團隊人數增加時管理的擴展，可以幫助部分解決團隊間協作的問題，卻無法從根本上解決大型團隊整體管理的諸多問題。

4.2 LeSS

LeSS是大規模的Scrum，是將Scrum原則和理念應用到同一產品線的多個團隊中。LeSS由10項原則、2種框架、大約50條指南（解釋在組織中如何應用LeSS框架以及需要什么類型的改變）及600條試驗組成（規模化敏捷開發時可以嘗試或避免的）。

10項原則：透明、經驗過程控制、精益思想、系統思考、排隊論、大規模Scrum仍然是Scrum、以少為多、關注整個產品、以用戶為中心、向完美持續改進。其中前兩項屬于Scrum的基本原則，3～5項屬于Meta類原則，6～10項屬于LeSS特有原則。

2種框架：LeSS和LeSS Huge。前者是簡化版框架，適用于2～8個團隊的產品群體（例如50人左右）。后者是大型框架，適用于單個產品超過百人或千人規模的產品群體。簡化版框架由一名PO面向多個Scrum團隊，增加的活動為多團隊的聯合回顧會（可選）。而大型LeSS引入需求領域的概念，增加了2個新的角色即領域產品負責人（APO）和產品負責人團隊（包括PO和所有APO）及一個領域待辦事項列表（APB），活動增加了聯合評審會（可選）和聯合回顧會（可選）。

特性團隊是LeSS實施的關鍵點。LeSS繼承了Scrum的思想，認為一個嚴格意義上的Scrum團隊就是一個特性團隊。為完成產品待辦列表中的一個條目（一個客戶特性）而進行所有的工作。團隊的目標是鼓勵成員學習更多技能和整個團隊進行完整特性的開發。特性團隊是跨職能的，由測試人員、開發人員、分析人員等組成，單一功能團隊將不再存在。組件團隊是開發人員圍繞系統組件組合的，會帶來很多弊端，特性團隊不是圍繞組件集合，而是組成可以在任何模塊中工作的跨組件團隊，目標是完成特性開發工作。特性團隊將團隊之間的協調難題從團隊之間的項目管理轉移到代碼層面的協調。這種轉變也帶來新的挑戰包括擴展技能、代碼并發訪問、分擔設計職責等。

實施LeSS將對組織結構帶來變革性影響，使組織管理趨向偏平化，矩陣化的管理將不再建議繼續適用。為解決行政部門弱化后專業技能培養的問題，實踐社團（CoP）作為試驗的內容被重點推薦，以非正式的渠道幫助在組織內部橫向傳播知識。

4.3 SAFe

SAFe定義了一個可擴展的敏捷框架模型，適用于大型團隊的合作開發，可以幫助提高團隊之間的協作性，降低團隊管理的復雜性。SAFe自發布后一直根據用戶的反饋不斷地迭代演進，2017年6月22日更新到4.5版本。

盡管版本不斷更新，SAFe的基本框架一直保持不變，從團隊（Team）、項目集（Program）和投資組合（Portfolio）3個層面清晰定義了規模化敏捷的框架。

在第1層投資組合，由投資組合管理委員會（Program Portfolio Manager，PPM）來負責定義和驅動投資策略如何形成和資金的組合形式，然后將其體現成為史詩（Epics）。一個Epic可以是一列單獨的敏捷發布火車（Agile Release Train，ART）來執行，也可以是幾個火車的組合。Epic是直接面向客戶的、設計架構級別的業務解決方案。在第2層項目集，由產品經理（Product Manager，PM）負責把等待安排的計劃（Backlog）進行排序，并且把投資策略轉化成具體的特性（Feature），同時和業務負責人一起設計出項目的愿景和路線。在第3層團隊，由產品負責人（Product Owner，PO）和團隊成員根據上面的定義細化出用戶故事（User Story，US）和驗收標準，開發團隊可以從候選的用戶故事里面優先選擇可以提前開始的內容，其余的留到故事池里面等待后續的選擇。

由此可見，SAFe從3個層面保證了團隊和企業的投資組合的最終愿景一致。同時，在實施過程中，需要一系列的里程碑事件來保證最終的實現和高層愿景設計的持續一致，而里程碑事件的制定主要通過發布規劃和系統的展示來保證。

在LeSS里，從根本上圍繞業務驅動項目重組企業，不需要管理者和專家。而在SAFe中，管理者還有架構師和專家有了一席之地。SAFe是借鑒了精益、敏捷和瀑布流開發方式的細致、重量級的方法。SAFe為企業大規模實施敏捷帶來了系統化的思路，帶來幾方面的好處，首先引入了大型需求、架構如何從愿景到實施團隊的層次化管理。其次，業務師、架構師、PMO、質量管理等人員可以考慮如何在各層級的介入；再次，對傳統項目、傳統管理方法的改造，比如如何利用精益敏捷方法對傳統需求價值評估、如何從“項目管理”到“持續內容管理”的轉變、對傳統單項目管理思維的優化、從里程碑治理到基于事實的治理等。正如其名字的隱喻，SAFe期望讓傳統的軟件企業在規模化敏捷過程中感到“安全”。

5 大規模敏捷開發的落地策略

任何敏捷開發方法在實施運用時，都不可避免地要與企業的實際狀況相結合，才能發揮其應有的作用，對于大規模敏捷開發的方法更是如此。經過實踐探索，總結了6條大規模敏捷開發落地的策略。

5.1 管理層重視支持并親力親為

對于小團隊而言，管理層的支持體現在給予資源支持，提供改進的空間和氛圍。而對于大型團隊，敏捷開發會涉及組織結構的調整和人員角色重新調整，這個對既有的管理機制會帶來很大的沖擊，原先有的崗位可能消失，運作方式會發生很大的變化。因此管理層不僅需要理解其中的因果關系，也要親自參與和領導這場變革。

5.2 痛點驅動與愿景驅動相結合

小團隊往往從痛點分析出發啟動敏捷開發，對于大型團隊也仍然適用。不同的是，大型團隊的敏捷實施對于企業發展方向會帶來重大影響，企業的高層和團隊的管理層都需要理解這種變革將會把企業和團隊帶領向何方。以痛點為出發點，以愿景為方向，才能保證大規模敏捷開發的順利實施。在實施中，愿景可以轉化為以半年或一年為粒度的里程碑目標。

5.3 對敏捷理論采用拿來主義

業界大規模敏捷開發的理論方法都有其特點、優點、缺點及產生的背景。完全照搬難以獲得期望的效果，需要將這些方法與企業和團隊的實際情況相結合，有選擇地引入實踐幫助團隊的有效改進。例如，LeSS中的特性團隊對于團隊交付能力會有質的幫助，而SAFe的敏捷發布火車概念，可以很好地在項目管理層面將敏捷開發契入既有的企業管理框架。

5.4 夯實Scrum團隊層面的敏捷基礎

Scrum團隊是大型團隊敏捷的基本單元，在組織層面管理變革時不能忽視這一重要基礎。需要不斷培養合格的SM，幫助Scrum團隊向自組織方向發展。

5.5 重視敏捷教練的培養與文化建設

敏捷教練是大規模敏捷開發實施的骨干力量。無論是管理教練和技術教練，都有其重要價值，可以幫助各種實踐在團隊內部有效實施，凝聚成為若干個實踐案例。管理方式的變革和技術實踐的演進對普通員工都會帶來現實的壓力和影響，需要通過培訓、學習、交流等各類活動幫助其快速適應這種變化，建立善于學習、樂于分享的敏捷文化。

5.6 鼓勵創新與實踐沉淀相結合

對于管理者往往期望將最佳實踐在組織內部快速復制，從而減少其他人的摸索成本，提升整體的研發能力。最佳實踐也往往會沉淀為組織規范，但在敏捷開發中最佳實踐這個詞本身會有爭論，會限制其他團隊的更新、更好的實踐產生。因此，組織規范不應成為改進探索的約束，相反應鼓勵更多團隊在相互學習的基礎上進一步創新，以獲得更多的優秀案例。在企業內部，這也會促使過程改進工作重心由星形集中化推動向網絡形橫向互連的變化。

6 結語

大規模敏捷開發是對軟件企業發展的重要的命題。SoS，LeSS，SAFe等大規模敏捷方法都具有重要的參考價值。而要有效實施，則需要企業內部的管理者有充分的理解和參與，才能將理論與實際相結合。需要注意的是，這種實施過程不是一蹴而就的，需要有長期的探索和演進。在此過程中，無論是管理者還是敏捷教練，都需要不斷回顧和重溫敏捷宣言，反思實施過程，才能及時發現和解決各種問題，保證改進方向的正確性。

[1]拉爾曼.精益和敏捷開發大型應用指南[M].孫搖媛，李搖劍，譯.北京：機械工業出版社，2010.

[2]拉爾曼.精益和敏捷開發大型應用實戰[M].孫媛，顧全，譯.北京：機械工業出版社，2011.

[3]萊芬韋爾.敏捷軟件需求：團隊、項目群與企業級的精益需求實踐[M].北京：清華大學出版社，2015.

Study on large scale agile strategy in software enterprises

Chen Gang, He Jinning
（ZTE Corporation, Nanjing 210012, China）

The large scale agile development is an important improvement direction for the software enterprises. This paper analyzes the characteristic of large scale software development, compares several common large scale agile strategy methods. Based on practical experiences, puts forward a series of pertinent strategies, which will help the software enterprises to successfully implement large scale agile.

software; enterprises; large scale agile; strategy

陳剛（1977— ），男，江蘇寶應人，工程師。