【編者按】軟件開發和采購人員經常會對現有軟件開發方法、技巧和工具產生一些疑問。針對這些疑問，Kevin Fall 整理了五個軟件方面的話題：Agile at Scale，Safety-Critical Systems，Monitoring Software-Intensive System Acquisition Programs，Managing Intellectual Property in the Acquisition of Software-Intensive Systems，以及 Managing Operational Resilience。該系列的第一篇主要關注 Agile at Scale 問題，本文由 OneAPM 工程師編譯整理：
這里會有一系列文章來介紹這5個話題相關的最佳實踐。第一組文章分為上下兩篇，介紹了規模化敏捷開發中的挑戰以及總結出的10個最佳實踐。限於篇幅問題，本文只介紹了10個最佳實踐中的前5個，下一篇將介紹余下的5個最佳實踐和應用這些最佳實踐過程中的3個建議。
規模化敏捷開發所面臨的挑戰
敏捷開發的概念在過去的十年間已經得到了廣泛的使用，也使得軟件開發團隊能夠開發出更好的軟件。之所以能取得這樣的效果，主要是敏捷開發的方法能夠提高項目進展的透明度，同時用戶還可以很早就預見產品的雛形，並與開發團隊進行交流。然而，達到商業目的遠遠不是開發出好軟件這么簡單。而如果期望規模化敏捷則必須先關注以下幾個方面：
1．團隊規模
試想一下，敏捷開發的方法應用在超過100人的開發團隊中會有什么效果？當這支開發團隊需要與其他部門在質檢、集成、項目管理、市場運營等進行合作和溝通以保證產品的順利交付時又會有怎樣的問題？通常極限編程這類的敏捷開發方法只適用於7至10人的小型團隊中，而大型團隊則需要分為幾個小團隊，同時需要和一些非開發的人員進行配合。目前已經有人在研究如何更好地解決團隊規模所帶來的協作問題了。
2．系統復雜程度
通常情況下，大型系統會包括較多的特性和新技術，還要與其他系統進行通信和集成，並且要照顧不同用戶群的需求。需要搞清楚是否有實時性、可靠性和安全性的要求，以及相關利益者都是誰。通常復雜系統都需要經過嚴格的驗證，這使得敏捷開發中的快速迭代變得復雜化了。
3．項目規划
有多長時間用於系統開發？系統維護的周期是多長？通常大型系統所需的開發和維護時間都比敏捷開發適用的系統長一些，而且需要關注可能的更改和重新設計，還可能會被要求交付不同的版本。搞清楚這些有助於決定對項目來說哪些才是衡量項目成功的重要指標。
規模化敏捷開發的最佳實踐
各個企業的情況有所不同，所以如何應用這些最佳實驗需要判斷它是否能使企業得益。特別要注意企業的商業目的、現有的流程和企業文化，因為所有的實踐都有其局限性，不可能存在所謂的萬金油。選擇這些最佳實踐時最好可以讓它們能互相配合，而且要根據企業的實際情況做出一定的調整。
1.[團隊協作][1]乃是第一要務
Scrum 是目前使用范圍最廣的敏捷項目管理方法。簡單來說 Scrum 開發環境只需要一個 Scrum 團隊。這一團隊需要具備說明需求、系統架構、設計、編碼以及測試所需的知識和能力。
然而，在項目的規模和復雜程度增加之后，單一的 Scrum 團隊可能就不能滿足開發的需求了，這時就要根據系統特性和服務來划分不同的小團隊。對一個項目如果已經決定了要使用 Scrum 這樣的項目管理方法，可以對各個 Scrum 小團隊也使用 Scrum 的方法進行管理。這就需要一個另外的協作團隊，這個協作團隊有兩個責任：一是確定團隊之間所交換的信息，這是為了解決團隊之間的依賴性和溝通問題。二是對團隊之間的協作問題和潛在的風險進行分析並解決。協作團隊的成員通常來自各個開發團隊，如此協作團隊的成員就能夠了解整個項目所有的功能，另外也可能還有一些用戶界面設計、系統架構、測試和部署的專業人員參與。這一協作團隊可以幫助各個開發團隊之間實現目標、問題和風險的交流和共享。但當協作團隊自己人數也多起來的時候則要當心了。
2.使用 [Architectural Runway][2] 來管理技術復雜性
嚴格的安全要求和任務關鍵需求會增加技術上的復雜性以及風險。如果一項任務在一次迭代中無法完成，同時也無法分解成較小的任務交給多個小組並行的話，這就說明這項任務有着技術上的復雜性。需要解決技術復雜性的問題，管理員必須在項目早期就完成最重要的軟件架構特性，有時甚至要將這個問題提升到整個企業的高度，比如對基礎設施平台或者產品線。
敏捷開發里把這個叫做 Architectural Runway。它的目的是為以后的迭代提供一個相對穩定的基礎。有一個相對穩定的基礎對多個團隊是很重要的。軟件的架構可以決定系統特性的重要性進，從而決定他們在開發中的優先級。通過定義 Architectural Runway 並在系統開發過程中對其進行擴展，開發團隊可以優先開發架構跑道中的特性以滿足用戶的需求。
Architectural Runway 也可以幫助開發團隊在項目早期就發現技術上的風險，並避免技術復雜性的問題。此外，系統質量上的要求如安全性、可用性和性能也是越早確定越好，否則很可能得進行大的改動或者造成項目延期。開發系統功能時如果所需要的基礎設施已經就位也能增加需交付功能的確定性。
3.基於[特性開發與系統分解][3]的結合
敏捷團隊通常的做法是在系統的所有組件中實現一個特性。這使得開發人員能夠專注於完成對用戶有意義的特性，而不必等待其他人的開發完成才能進行。這個途徑被稱之為「vertical alignment」，因為系統中每個實現這個特性的組件都在各個團隊中獨立開發。但系統的分解也可以是水平的，這主要基於系統的架構。這種方法主要被用於一些通用服務商，因為它們可以被更多的復用。
無論是針對特性進行開發還是對系統進行水平分解，其目的都是根據系統的分解來安排開發團隊並且解耦以便保持進度。當需要在敏捷穩定性和進度上保持平衡時可以采用的策略是先開發一個通用服務的平台，再在此基礎上以插件的方式快速進行基於特性的開發。
4.使用[質量評估][4]來決定架構上的需求
Scrum所注重的是解決用戶面對的特性問題，這確實也對系統成功與否起到重要作用。但當注意力完全放在功能特性上的時候，往往就會忽略架構上的需求。
這里的建議是在開發 Architectural Runway 時收集、記錄、溝通和確認潛在的系統質量上的要求。而大型系統來說由於維護周期都比較長，所以這點尤為重要。在項目早期就應該對質量上的要求進行評估，以便決定哪些架構上的需求應該盡快滿足或者有哪些方式交付用戶需求的捷徑。
舉個例子說，比如一個系統要滿足100萬用戶使用。這是說立刻就要滿足100萬用戶使用呢？還是現在它其實只是一個測試產品再比如系統一般都會使用一些框架，理解系統質量要求可以幫助開發人員確定哪些架構上的需求已經被框架解決了。當需要解決安全和部署環境方面需求變化時，架構上的需求必須給予最高的優先級。
5.在整個生命周期中使用[測試驅動][5]理念
這一條如果用一句話來概括就是開發之前先寫好測試。如果開發的過程中只考慮正常情況，那么后期就會過度依賴於測試來找出開發中忽略掉的情況。為了避免這種情況在開發過程中就要考慮到異常。如果能夠先寫好測試，使用測試驅動開發或驗收測試驅動開發的方法，將使得我們推薦的其他實踐變得更有成效。
原文鏈接：[10 Recommended Practices for Achieving Agile at Scale][6]
[1] http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=87764
[2] http://www.scaledagileframework.com/architectural-runway/
[3] http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=87764
[4] http://www.sei.cmu.edu/architecture/start/reasoning.cfm