導讀：敏捷方法已經在軟體開發和交付中獲得了主導性地位。但即便使用敏捷方法，你是否還在經歷著專案延期、質量低下、超出預算等問題？軟體開發迭代中總是有這樣那樣的問題？你是否懷疑敏捷到底能否給你帶來期望的成功？近來，在一個有關敏捷中“完成”的線上講座中，針對當前敏捷實踐中存在的問題，Scrum的創始人之一——Jeff Sutherland——總結了敏捷實踐中的這些問題的原因，並指出瞭解決的辦法——重新定義“完成”（Definition of Done，DoD）。本文是根據Jeff講座內容整理而得。

Bad Agile

瀑布開發與敏捷開發的各種利弊對比，已經得到了業界的充分分析，這裡就不再贅述。而值得我們警惕的是，敏捷方法中“不敏捷”的實踐做法，稱之為“Bad Agile”。據可靠業界資料，大約49%的敏捷團隊這在經歷著“Bad Agile”。

而正是如下這些看似無關緊要卻對專案進度和交付傷害極大的錯誤觀念和實踐，在消耗著敏捷在人們心中的價值。

• 對《敏捷宣言》的錯誤理解或者片面理解，導致無法在專案中完全遵循敏捷精神。
• 團隊沒有在一起工作以在迭代中交付可工作軟體。
• 因為軟體並不能工作，團隊無法在迭代結束時及時響應專案干係人的反饋。
• 大量缺陷（bug）無法在24小時內修復，導致越聚越多，影響交付的軟體質量。

為什麼軟體團隊無法按時交付可工作的軟體？主要有以下原因：

• “完成”的定義比較糟糕。
• 使用者故事並沒有Ready。
• 功能失常的領導者。
• 技術債（Technical Debt）。
• 糟糕的教導（Coaching）

下面來具體看看到底發生了什麼。

糟糕的DoD定義

1）“完成”的定義並不清晰。由於各個團隊成員對“完成”的理解並不一致，而團隊又沒有坐下來商討出一個清晰而一致的“完成”定義，大家並不明白“完成”到底對各個角色意味著什麼。開發人員可能覺得，寫完程式碼並check-in就算“完成”，而測試人員則認為測試完事才算“完成”，但整合和部署人員則希望功能上線才算“完成”。很明顯，如果各個角色並不清楚“完成”對他們和要交付的可工作軟體來說意味著什麼，那麼他們不可能完成客戶和產品負責人期望的軟體。

2） 缺乏一致的質量標準。如果DoD中不包含什麼是“可工作的軟體”，那大家對最終結果的認識可能完全不一致。由此，到底什麼是高質量，也就無從談起。沒有一致的質量標準，意味著大家對最終交付的軟體要達到什麼樣的質量莫衷一是。另外一個可能造成嚴重後果的原因可能來自產品負責人（Product Owner）。如果在一個Sprint結束時，Product Owner接受沒有真正“完成”的使用者故事

，那就意味著使用者故事的完成也打了折扣。這會讓Scrum團隊認為，既使在一個迭代中沒有完成使用者故事也是可以接受的，而以後也可照此辦理。

使用者故事並沒有準備就緒（Ready）

1）使用者故事的規模問題。

• 估計使用者故事規模（工作量）時使用的基本點（Base Point）並不一致。導致估算出來的使用者故事點數對不同的人和不用的使用者故事完全沒有可參考性。失去故事點的基本價值。
• 在一個迭代中承諾了太大的故事，而不是將大的故事適當合理分解。
• 將太多的使用者故事放進一個迭代中。  

2） 使用者故事寫的太糟糕。

• 由於表達能力、對使用者需求的理解等原因，使用者故事書寫得並不清晰，尤其是驗收標準（acceptance criteria）。將這樣的使用者故事交給團隊，團隊可能也是一頭霧水。
• 沒有清晰定義依賴關係。有時候，各個故事之間有一定的內在依賴關係，需要在撰寫使用者故事時清楚地列出來。

功能失常的團隊領導和管理

1）開發人員手中同時在做非常多的事情。由於需要不斷地在不同的任務或專案之間來回切換，上下文切換是要消耗開發人員的時間的，團隊的效率就會降低。

2）每件事情都是最高優先順序。沒有區分優先順序的使用者故事，團隊不知道該從哪個下手。所有事情都是最高優先順序的結果是，所有事情可能都沒法按時完成。

3）完成工作的壓力，最終會導致專案延誤，並降低交付的質量。壓力只能讓大家更快地工作，卻無法讓大家做出更好的軟體。

4）缺乏對Scrum的正確理解。誤解Scrum和敏捷的很多基本原則和實踐，往往在自己專案中會採用一些看似正確的變通措施，最終誤入歧途。

5）害怕職責的暴露或者改變。這一條，不多解釋。

6）沒有采用持續整合，和/或，根本就沒有測試。例如：奧巴馬醫改計劃。

技術債（Technical Debt）

軟體行業關於“技術債”的討論可謂數不勝數。

1）未完全完成的Sprint中，某些使用者故事“爛尾”，在下一個Sprint中不得不重新規劃並完成這些“爛尾”故事。而這可能會造成程式碼質量下降。

2）遺留程式碼往往包含了堆積如山的各種技術債，而這會大大降低團隊的交付速率（velocity）。很多技術債是由於沒有使用持續整合或自動化測試等現代技術而累積下來的。當開發團隊出現妄圖走捷徑、缺乏重構、創造力喪失、消極怠工、工作敷衍草率時，技術債就出現了。

糟糕的教導（Coaching）

1）筒倉式管理（Silo‘s ）和專業化（specialization）拖慢了敏捷團隊的前進速度。這方面最好的例子就是專業化的測試團隊。

2）開發人員並沒有像一個團隊一樣組織起來工作。他們只有極少的合作，而且沒有叢集工作。

3）未能使用持續整合，不斷出現的問題扼殺了團隊前進的速率。團隊沒有幸福感，沒有任何中斷模式，不能真正把大家召集在一起，健康地運轉Scrum。

4）"假裝敏捷"——沒有團隊協作，沒有可工作的軟體，沒有客戶協作，而且對變更沒有任何有效的響應。

基於以上Scrum團隊中存在的問題，Jeff給出了應對之道：

讓事情成功做完的系統方法：

• 使“完成”的定義（DoD）真正起作用。
• 確保產品待辦事項（Backlog）準備就緒。
• 培訓管理層。
• 實施技術債補救計劃
• 提升教導（Coaching）和Scrum Master的地位。

系統化Scrum方法模型如下圖所示：

使DoD真正生效

• “完成”的定義中，必須包含整合測試，測試數量必須超過程式碼容量。
• 測試人員必須是Scrum團隊的一員，不要單獨分離出測試團隊來。
• Sprint中不要承諾太多的使用者故事。可以使用某些模式來估計團隊在未來Sprint的velocity。比如“昨日天氣（Yesterday’s Weather）”模式，“非緊急無中斷”模式以及“Scrum緊急事件處理程式”等。
• 使用自動化構建系統來合併新程式碼與系統已有舊程式碼——持續整合。
• 系統化地構建自動化驗收測試，第一時間預防高優先順序缺陷。
• 缺陷修復時間不超過1天。實行“程式碼每日清理”（Daily Clean Code）。由於大約70%的軟體缺陷都是整合缺陷，過後再測將耗費測試人員過多時間。

確保產品待辦事項（Backlog）準備就緒。

最近更新的《Scrum指南》[2]包含了“準備就緒”（Ready）的概念。這確保了團隊即將使用的Backlog和使用者故事是經過了評審，使用者故事所表述的需求和價值清晰、明瞭，團隊對故事點的理解一致而可靠。

• 團隊可以坐在一起，就“準備就緒的定義”（Definition of Ready, DoR）達成一致。
• 只有經過評審且“準備就緒”的使用者故事才能夠進入產品待辦事項列表（backlog）。
• 對產品待辦事項進行精煉，確保使用者故事處於“準備就緒”狀態。
• 好的“就緒”故事能夠是開發團隊事半功倍，所以要捨得在使用者故事上花時間，以使之真正“就緒”。

下圖所示為使用者故事的就緒流程：

下圖是來自某個Scrum團隊的真實案例。在集中精力於使用者故事使之“準備就緒”之後，團隊的生產率得到了大幅提高。

培訓管理層

依賴允許客戶——會同供應商或者供貨商——決定軟體產品最終將是什麼樣子，敏捷開發的競爭力已經超過了精益製造（lean manufacturing）。對敏捷競爭者來說，定製富有個性的產品的能力只帶來很少或者幾乎沒有任何製造成本上升。但事實上，敏捷確實有所提高，因為敏捷要求在組織、管理哲學和組織運作上做出較大改變。經理們需要接受培訓，以瞭解那些有經驗的Agile CXO們如何領導敏捷團隊。管理層的職責包括：

• 為敏捷團隊提供富有挑戰性的目標。
• 建立有效的商業計劃或運作環境，比如：建立彼此相互協作的敏捷團隊，提供團隊運作所需的所有資源。
• 為團隊識別並排除障礙。管理層需要了解團隊的速率；列出障礙清單以瞭解是什麼因素放慢了團隊的速度；消除浪費，要事優先。
• 讓產品負責人（Product Owner）對所負責交付的每一個故事點負起職責。
• 讓Scrum Master對流程改進和團隊的幸福感負起職責。

修復技術債

• 實施缺陷補救計劃。通常，80%的缺陷來自於約20%或者更少的程式碼。針對這部分程式碼實施有針對性地補救或者更新，可修復絕大多數缺陷。IBM就有一整套完善的確定補救優先順序的策略[3]。
• 實施止痛計劃。將驗收測試系統地構建進整個產品構建系統中，確保最高優先順序測試優先執行。
• 縮減債務。團隊要為產品負責人構建出適當的業務案例，使之清楚瞭解在產品開發過程中會有多少個點的技術債，需要多長時間來消除這些技術債。
• 管理層要致力於產品的系統改進。比如降低運營成本，增加銷售量等。

用優秀教練增加成功概率

• 僱傭優秀的員工。
• 每個團隊都必須有一個敏捷教練。敏捷教練負責在每一個Sprint中至少提出一項流程改進措施。改進產品待辦事項列表並持續度量改進效果。教練的指導能夠從根本上改善高績效團隊的產出。
• 在教練指導下，所有敏捷團隊爭取在每個Sprint中實施多次持續部署（continuous deployment）。

敏捷教練可採用如下度量指標來衡量團隊的改進效果;

• 缺陷修復時間。如果團隊的平均缺陷修復時間（從發現到完成修復）少於24小時，那團隊的速率將會加倍。
• 工作群集度度量。 這個指標衡量的是個體和互動產生的績效有多好。度量公式為： 完成一個使用者故事所需要的實際工作量（以小時折算的工作日）/完成所需要的日曆時間（日曆天數）。如果這個指標超過50%， 團隊的工作效率將會再次翻倍。

• 穩定的團隊——如何開始？
• 昨日天氣——怎麼將產品待辦事項放入一個Sprint中？
• 程式碼每日清理——如何才能在Sprint結束時獲得一個沒有缺陷的產品？
• 群集——怎樣讓工作快速完成？
• 中斷模式——如何處理Sprint期間的干擾？
• 停止前進——如何處理突發事件？
• 讓Scrum Scrum起來——如何持續進行改進？
• 幸福指數——如何確保團隊不會不堪重負？

結論

Bad Agile往往由以下5個主要因素所致：

• 糟糕的“完成”定義（DoD）
• 使用者故事並未就緒
• 領導不善
• 團隊技術債
• 無效教練

系統性地聚焦於糾正這些問題將會持續不斷地造就高執行力團隊，在生產力上提高200%到400%。

如果不能專注於解決這些問題，將會導致大約49%的敏捷團隊變為“Bad Agile”，而這又會導致客戶不滿、收入減少以及股價降低。

參考文獻：

[1] 《30天軟體開發：告別瀑布擁抱敏捷》，Ken Schwaber，Jeff Sutherland 著；王軍，李麟德 譯。人民郵電出版社2014年1月出版。

[2] 《Scrum Guide》，http://www.scrumguides.org/。

[3] Mays et al. Experiences in Defect Prevention. IBM Systems Journal 29:1, 1990

[4] Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams 47th Hawaii International Conference on System Sciences (HICSS) By Jeff Sutherland, Neil Harrison, Joel Riddle January 2014.