陳 剛，賀晉寧

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

軟件企業(yè)大規(guī)模敏捷策略研究

陳 剛，賀晉寧

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

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

軟件；企業(yè)；大規(guī)模敏捷；策略

1 敏捷開發(fā)的產(chǎn)生

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

敏捷開發(fā)具有很多優(yōu)點，例如不斷變化、充分發(fā)揮人的創(chuàng)造力和主動性、迭代開發(fā)過程中一直保持軟件產(chǎn)品的可用狀態(tài)等。這些優(yōu)點吸引了越來越多的軟件企業(yè)研究和應(yīng)用敏捷開發(fā)。

2 敏捷開發(fā)在小團隊中的應(yīng)用

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

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

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

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

3 大規(guī)模敏捷的困惑

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

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

4 大規(guī)模敏捷開發(fā)方法論

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

4.1 SoS

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

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

4.2 LeSS

LeSS是大規(guī)模的Scrum，是將Scrum原則和理念應(yīng)用到同一產(chǎn)品線的多個團隊中。LeSS由10項原則、2種框架、大約50條指南（解釋在組織中如何應(yīng)用LeSS框架以及需要什么類型的改變）及600條試驗組成（規(guī)?；艚蓍_發(fā)時可以嘗試或避免的）。

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

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

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

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

4.3 SAFe

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

盡管版本不斷更新，SAFe的基本框架一直保持不變，從團隊（Team）、項目集（Program）和投資組合（Portfolio）3個層面清晰定義了規(guī)?；艚莸目蚣?。

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

由此可見，SAFe從3個層面保證了團隊和企業(yè)的投資組合的最終愿景一致。同時，在實施過程中，需要一系列的里程碑事件來保證最終的實現(xiàn)和高層愿景設(shè)計的持續(xù)一致，而里程碑事件的制定主要通過發(fā)布規(guī)劃和系統(tǒng)的展示來保證。

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

5 大規(guī)模敏捷開發(fā)的落地策略

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

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

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

5.2 痛點驅(qū)動與愿景驅(qū)動相結(jié)合

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

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

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

5.4 夯實Scrum團隊層面的敏捷基礎(chǔ)

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

5.5 重視敏捷教練的培養(yǎng)與文化建設(shè)

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

5.6 鼓勵創(chuàng)新與實踐沉淀相結(jié)合

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

6 結(jié)語

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

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

[2]拉爾曼.精益和敏捷開發(fā)大型應(yīng)用實戰(zhàn)[M].孫媛，顧全，譯.北京：機械工業(yè)出版社，2011.

[3]萊芬韋爾.敏捷軟件需求：團隊、項目群與企業(yè)級的精益需求實踐[M].北京：清華大學(xué)出版社，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— ），男，江蘇寶應(yīng)人，工程師。