【編者按】軟體開發和採購人員經常會對現有軟體開發方法、技巧和工具產生一些疑問。針對這些疑問，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 問題，本文由

這裡會有一系列文章來介紹這5個話題相關的最佳實踐。第一組文章分為上下兩篇，介紹了規模化敏捷開發中的挑戰以及總結出的10個最佳實踐。限於篇幅問題，本文只介紹了10個最佳實踐中的前5個，下一篇將介紹餘下的5個最佳實踐和應用這些最佳實踐過程中的3個建議。

規模化敏捷開發所面臨的挑戰

敏捷開發的概念在過去的十年間已經得到了廣泛的使用，也使得軟體開發團隊能夠開發出更好的軟體。之所以能取得這樣的效果，主要是敏捷開發的方法能夠提高專案進展的透明度，同時使用者還可以很早就預見產品的雛形，並與開發團隊進行交流。然而，達到商業目的遠遠不是開發出好軟體這麼簡單。而如果期望規模化敏捷則必須先關注以下幾個方面：

1．團隊規模

試想一下，敏捷開發的方法應用在超過100人的開發團隊中會有什麼效果？當這支開發團隊需要與其他部門在質檢、整合、專案管理、市場運營等進行合作和溝通以保證產品的順利交付時又會有怎樣的問題？通常極限程式設計這類的敏捷開發方法只適用於7至10人的小型團隊中，而大型團隊則需要分為幾個小團隊，同時需要和一些非開發的人員進行配合。目前已經有人在研究如何更好地解決團隊規模所帶來的協作問題了。

2．系統複雜程度

通常情況下，大型系統會包括較多的特性和新技術，還要與其他系統進行通訊和整合，並且要照顧不同使用者群的需求。需要搞清楚是否有實時性、可靠性和安全性的要求，以及相關利益者都是誰。通常複雜系統都需要經過嚴格的驗證，這使得敏捷開發中的快速迭代變得複雜化了。

3．專案規劃

有多長時間用於系統開發？系統維護的週期是多長？通常大型系統所需的開發和維護時間都比敏捷開發適用的系統長一些，而且需要關注可能的更改和重新設計，還可能會被要求交付不同的版本。搞清楚這些有助於決定對專案來說哪些才是衡量專案成功的重要指標。

規模化敏捷開發的最佳實踐

各個企業的情況有所不同，所以如何應用這些最佳實驗需要判斷它是否能使企業得益。特別要注意企業的商業目的、現有的流程和企業文化，因為所有的實踐都有其侷限性，不可能存在所謂的萬金油。選擇這些最佳實踐時最好可以讓它們能互相配合，而且要根據企業的實際情況做出一定的調整。

1.團隊協作乃是第一要務

Scrum 是目前使用範圍最廣的敏捷專案管理方法。簡單來說 Scrum 開發環境只需要一個 Scrum 團隊。這一團隊需要具備說明需求、系統架構、設計、編碼以及測試所需的知識和能力。

然而，在專案的規模和複雜程度增加之後，單一的 Scrum 團隊可能就不能滿足開發的需求了，這時就要根據系統特性和服務來劃分不同的小團隊。對一個專案如果已經決定了要使用 Scrum 這樣的專案管理方法，可以對各個 Scrum 小團隊也使用 Scrum 的方法進行管理。這就需要一個另外的協作團隊，這個協作團隊有兩個責任：一是確定團隊之間所交換的資訊，這是為了解決團隊之間的依賴性和溝通問題。二是對團隊之間的協作問題和潛在的風險進行分析並解決。協作團隊的成員通常來自各個開發團隊，如此協作團隊的成員就能夠了解整個專案所有的功能，另外也可能還有一些使用者介面設計、系統架構、測試和部署的專業人員參與。這一協作團隊可以幫助各個開發團隊之間實現目標、問題和風險的交流和共享。但當協作團隊自己人數也多起來的時候則要當心了。

嚴格的安全要求和任務關鍵需求會增加技術上的複雜性以及風險。如果一項任務在一次迭代中無法完成，同時也無法分解成較小的任務交給多個小組並行的話，這就說明這項任務有著技術上的複雜性。需要解決技術複雜性的問題，管理員必須在專案早期就完成最重要的軟體架構特性，有時甚至要將這個問題提升到整個企業的高度，比如對基礎設施平臺或者產品線。

敏捷開發裡把這個叫做 Architectural Runway。它的目的是為以後的迭代提供一個相對穩定的基礎。有一個相對穩定的基礎對多個團隊是很重要的。軟體的架構可以決定系統特性的重要性進，從而決定他們在開發中的優先順序。通過定義 Architectural Runway 並在系統開發過程中對其進行擴充套件，開發團隊可以優先開發架構跑道中的特性以滿足使用者的需求。

Architectural Runway 也可以幫助開發團隊在專案早期就發現技術上的風險，並避免技術複雜性的問題。此外，系統質量上的要求如安全性、可用性和效能也是越早確定越好，否則很可能得進行大的改動或者造成專案延期。開發系統功能時如果所需要的基礎設施已經就位也能增加需交付功能的確定性。

敏捷團隊通常的做法是在系統的所有元件中實現一個特性。這使得開發人員能夠專注於完成對使用者有意義的特性，而不必等待其他人的開發完成才能進行。這個途徑被稱之為「vertical alignment」，因為系統中每個實現這個特性的元件都在各個團隊中獨立開發。但系統的分解也可以是水平的，這主要基於系統的架構。這種方法主要被用於一些通用服務商，因為它們可以被更多的複用。

無論是針對特性進行開發還是對系統進行水平分解，其目的都是根據系統的分解來安排開發團隊並且解耦以便保持進度。當需要在敏捷穩定性和進度上保持平衡時可以採用的策略是先開發一個通用服務的平臺，再在此基礎上以外掛的方式快速進行基於特性的開發。

4.使用質量評估來決定架構上的需求

Scrum所注重的是解決使用者面對的特性問題，這確實也對系統成功與否起到重要作用。但當注意力完全放在功能特性上的時候，往往就會忽略架構上的需求。

這裡的建議是在開發 Architectural Runway 時收集、記錄、溝通和確認潛在的系統質量上的要求。而大型系統來說由於維護週期都比較長，所以這點尤為重要。在專案早期就應該對質量上的要求進行評估，以便決定哪些架構上的需求應該儘快滿足或者有哪些方式交付使用者需求的捷徑。

舉個例子說，比如一個系統要滿足100萬用戶使用。這是說立刻就要滿足100萬用戶使用呢？還是現在它其實只是一個測試產品再比如系統一般都會使用一些框架，理解系統質量要求可以幫助開發人員確定哪些架構上的需求已經被框架解決了。當需要解決安全和部署環境方面需求變化時，架構上的需求必須給予最高的優先順序。

5.在整個生命週期中使用測試驅動理念

這一條如果用一句話來概括就是開發之前先寫好測試。如果開發的過程中只考慮正常情況，那麼後期就會過度依賴於測試來找出開發中忽略掉的情況。為了避免這種情況在開發過程中就要考慮到異常。如果能夠先寫好測試，使用測試驅動開發或驗收測試驅動開發的方法，將使得我們推薦的其他實踐變得更有成效。

OneAPM 是應用效能管理領域的新興領軍企業，能幫助運維人員進行故障預警和定位，減少業務系統維護的工作量，同時還能提供可追溯的效能資料，量化運維部門的業務價值。想告別加班熬夜，歡迎免費註冊使用！