【編者按】軟件開發和採購人員常常會對現有軟件開發方法、技巧和工具產生一些疑問。針對這些疑問，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 工程師編譯整理：html
這裏會有一系列文章來介紹這5個話題相關的最佳實踐。第一組文章分爲上下兩篇，介紹了規模化敏捷開發中的挑戰以及總結出的10個最佳實踐。限於篇幅問題，本文只介紹了10個最佳實踐中的前5個，下一篇將介紹餘下的5個最佳實踐和應用這些最佳實踐過程當中的3個建議。編程
規模化敏捷開發所面臨的挑戰
敏捷開發的概念在過去的十年間已經獲得了普遍的使用，也使得軟件開發團隊可以開發出更好的軟件。之因此能取得這樣的效果，主要是敏捷開發的方法可以提升項目進展的透明度，同時用戶還能夠很早就預見產品的雛形，並與開發團隊進行交流。然而，達到商業目的遠遠不是開發出好軟件這麼簡單。而若是指望規模化敏捷則必須先關注如下幾個方面：安全
1．團隊規模架構
試想一下，敏捷開發的方法應用在超過100人的開發團隊中會有什麼效果？當這支開發團隊須要與其餘部門在質檢、集成、項目管理、市場運營等進行合做和溝通以保證產品的順利交付時又會有怎樣的問題？一般極限編程這類的敏捷開發方法只適用於7至10人的小型團隊中，而大型團隊則須要分爲幾個小團隊，同時須要和一些非開發的人員進行配合。目前已經有人在研究如何更好地解決團隊規模所帶來的協做問題了。框架
2．系統複雜程度工具
一般狀況下，大型系統會包括較多的特性和新技術，還要與其餘系統進行通訊和集成，而且要照顧不一樣用戶羣的需求。須要搞清楚是否有實時性、可靠性和安全性的要求，以及相關利益者都是誰。一般複雜系統都須要通過嚴格的驗證，這使得敏捷開發中的快速迭代變得複雜化了。性能
3．項目規劃測試
有多長時間用於系統開發？系統維護的週期是多長？一般大型系統所需的開發和維護時間都比敏捷開發適用的系統長一些，並且須要關注可能的更改和從新設計，還可能會被要求交付不一樣的版本。搞清楚這些有助於決定對項目來講哪些纔是衡量項目成功的重要指標。ui
規模化敏捷開發的最佳實踐
各個企業的狀況有所不一樣，因此如何應用這些最佳實驗須要判斷它是否能使企業得益。特別要注意企業的商業目的、現有的流程和企業文化，由於全部的實踐都有其侷限性，不可能存在所謂的萬金油。選擇這些最佳實踐時最好可讓它們能互相配合，並且要根據企業的實際狀況作出必定的調整。編碼
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