規模化敏捷開發的10個最佳實踐（上）

【編者按】軟件開發和採購人員經常會對現有軟件開發方法、技巧和工具產生一些疑問。針對這些疑問，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 project師編譯整理：

這裏會有一系列文章來介紹這5個話題相關的最佳實踐。

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

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

敏捷開發的概念在過去的十年間已經獲得了普遍的使用，也使得軟件開發團隊可以開發出更好的軟件。之因此能取得這種效果。主要是敏捷開發的方法可以提升項目進展的透明度，同一時候用戶還可以很是早就預見產品的雛形。並與開發團隊進行交流。

然而，達到商業目的遠遠不是開發出好軟件這麼簡單。而假設指望規模化敏捷則必須先關注下面幾個方面：

1．團隊規模

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

2．系統複雜程度

一般狀況下。大型系統會包含較多的特性和新技術，還要與其它系統進行通訊和集成，而且要照應不一樣用戶羣的需求。需要搞清楚是否有實時性、可靠性和安全性的要求，以及相關利益者都是誰。一般複雜系統都需要通過嚴格的驗證。這使得敏捷開發中的高速迭代變得複雜化了。

3．項目規劃

有多長時間用於系統開發？系統維護的週期是多長？一般大型系統所需的開發和維護時間都比敏捷開發適用的系統長一些，而且需要關注可能的更改和又一次設計，還可能會被要求交付不一樣的版本號。

搞清楚這些有助於決定對項目來講哪些纔是衡量項目成功的重要指標。

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

各個企業的狀況有所不一樣，因此怎樣應用這些最佳實驗需要推斷它可否使企業得益。

特別要注意企業的商業目的、現有的流程和企業文化，因爲所有的實踐都有其侷限性。不可能存在所謂的萬金油。選擇這些最佳實踐時最好可以讓它們能互相配合，而且要依據企業的實際狀況作出必定的調整。

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

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

然而。在項目的規模和複雜程度添加以後，單一的 Scrum 團隊可能就不能知足開發的需求了，這時就要依據系統特性和服務來劃分不一樣的小團隊。對一個項目假設已經決定了要使用 Scrum 這種項目管理方法。可以對各個 Scrum 小團隊也使用 Scrum 的方法進行管理。這就需要一個另外的協做團隊，這個協做團隊有兩個責任：一是肯定團隊之間所交換的信息，這是爲了解決團隊之間的依賴性和溝通問題。二是對團隊之間的協做問題和潛在的風險進行分析並解決。

協做團隊的成員一般來自各個開發團隊，如此協做團隊的成員就可以瞭解整個項目所有的功能，另外也可能另外一些用戶界面設計、系統架構、測試和部署的專業人員參與。這一協做團隊可以幫助各個開發團隊之間實現目標、問題和風險的交流和共享。但當協做團隊本身人數也多起來的時候則要小心了。

2.使用 Architectural Runway 來管理技術複雜性

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

敏捷開發裏把這個叫作 Architectural Runway。它的目的是爲之後的迭代提供一個相對穩定的基礎。有一個相對穩定的基礎對多個團隊是很是重要的。軟件的架構可以決定系統特性的重要性進，從而決定他們在開發中的優先級。經過定義 Architectural Runway 並在系統開發過程當中對其進行擴展，開發團隊可以優先開發架構跑道中的特性以知足用戶的需求。

Architectural Runway 也可以幫助開發團隊在項目早期就發現技術上的風險，並避免技術複雜性的問題。此外，系統質量上的要求如安全性、可用性和性能也是越早肯定越好，不然很是可能得進行大的修改或者形成項目延期。開發系統功能時假設所需要的基礎設施已經就位也能添加需交付功能的肯定性。

3.基於特性開發與系統分解的結合

敏捷團隊一般的作法是在系統的所有組件中實現一個特性。這使得開發者可以專一於完畢對用戶有意義的特性，而沒必要等待其它人的開發完畢才幹進行。這個途徑被稱之爲「vertical alignment」。因爲系統中每個實現這個特性的組件都在各個團隊中獨立開發。

但系統的分解也可以是水平的，這主要基於系統的架構。這個方案主要被用於一些通用服務商，因爲它們可以被不少其它的複用。

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

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

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

這裏的建議是在開發 Architectural Runway 時收集、記錄、溝通和確認潛在的系統質量上的要求。而大型系統來講因爲維護週期都比較長，因此這點尤其重要。

在項目早期就應該對質量上的要求進行評估。以便決定哪些架構上的需求應該儘快知足或者有哪些方式交付用戶需求的捷徑。

舉個樣例說。比方一個系統要知足100萬用戶使用。

這是說立馬就要知足100萬用戶使用呢？仍是現在它事實上僅僅是一個測試產品再比方系統通常都會使用一些框架，理解系統質量要求可以幫助開發者肯定哪些架構上的需求已經被框架攻克了。當需要解決安全和部署環境方面需求變化時，架構上的需求必須給予最高的優先級。

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

這一條假設用一句話來歸納就是開發以前先寫好測試。假設開發的過程當中僅僅考慮正常狀況，那麼後期就會過分依賴於測試來找出開發中忽略掉的狀況。

爲了不這種狀況在開發過程當中就要考慮到異常。

假設可以先寫好測試。使用測試驅動開發或驗收測試驅動開發的方法，將使得咱們推薦的其它實踐變得更有成效。

原文連接：10 Recommended Practices for Achieving Agile at Scale

OneAPM 是應用性能管理領域的新興領軍企業。能幫助運維人員進行故障預警和定位。下降業務系統維護的工做量。同一時候還能提供可追溯的性能數據，量化運維部門的業務價值。

想告別加班熬夜，歡迎免費註冊使用！