剖析短迭代

作者 Dave Nicolette譯者 鄭柯 發布于 2008年11月19日 下午3時56分

很多人都覺得：迭代的長度應該由發布周期的長短確定。我不同意，我認為這兩個周期之間不應有關系。相對于長迭代來說，短迭代可以提供更為頻繁的客戶反饋， 同時也給予團隊機會，讓他們可以反思并改進自己的工作實踐。短周期可以形成“心跳節奏”，這樣的快節奏也足以展現更多意義。由于短周期的本性使然，團隊不 大有機會創建過于冗長的工作項目，而這樣的項目會使得人們很難產生成就感，除非等到大量的工作完成之后。即使發布的周期很長，下面這些好處仍然存在。

相關廠商內容

InfoQ中文站讀者獨享6折SD2C技術大會門票，即刻搶購

沙龍：GlassFish的OSGi模塊化架構分析（11.29 杭州）

好處

快速響應。在不影響正在進行的工作的情況下優先快速響應變化。產品負責人、客戶或是代理人在迭代中期改變優先 級或是添加新功能，這樣的情況很多見。如果迭代時間足夠 短，這種狀況就可以得到更好的處理，因為變更在下個迭代中就可以容納進來了，這樣也可以避免打亂當前迭代本不應受影響的正常節奏。

問題檢測。 成熟的敏捷團隊能夠發現流程上的問題并馬上處理。然而，目前看來，很多敏捷團隊仍然在學習曲線上前行，他們還沒有成熟到可以自己 發現并解決問題的地步。他們需要根據項目度量數據的變化來識別問題。由于趨勢要靠三個點的連線才能體現出來，而項目數據每個迭代才能收集一次，因此更短的 迭代可以更快地暴露問題。

范圍管理。如果待辦事項列表中的條目都很小，那就可以靈活移動。較長的迭代會產生較大的用戶故事。如果產品負責人需要變更待辦事項列表條目的優先級，如果用戶故事較大，那么變更這些用戶故事造成的影響也更大。較短的迭代則趨向產生較小的用戶故事。遵循INVEST原則，產品負責人也更容易變更用戶故事的優先級。

迭代規劃和跟蹤。 長迭代產生的較大的用戶故事，經常要被分解為“任務”，也就是要將大塊兒的開發工作拆分為可操作性更強的明細任務。接下 來，為了讓團隊知道所有用戶故事的狀態，這些任務要在迭代中跟蹤，要么使用類似于“看板”的系統，要么使用迭代的燃盡圖。很多團隊每天都會停下來重新估算 尚未完成的個人任務。使用短迭代，可以去除所有這些內部流程的管理成本；用戶故事變成了更小的工作單位，而人們也能夠以更簡單的方式跟蹤迭代狀態。

成為轉向“無迭代流程” 的基礎。迭代式開發保留了一些瀑布開發過程固有的管理成本，即使我們付出代價想去掉它們也是如此。如果將每個迭代從 頭到尾畫一個價值流累積圖（cumulative flow diagram），這些管理成本就會以“在途時間（lead time）”的形式體現出來。我參與過的一些團隊，他們在自己承受范圍之內盡量壓縮迭代的時間。我注意到他們可以消除大量類似的管理成本。迭代時間越短， 讓一切工作順利進行所需花費的流程管理成本就越少。

從另一方面來看，在有嚴格時間限制的迭代中工作，也可以帶來一些敏捷方法的附加價值，包括頻繁和有規律的演示和回顧、用來交付增量開發結果的一致性 時間 表、頻繁得到客戶反饋的機會、以及對于“心跳”或是“脈搏”類似節奏的感覺，這樣的感覺可以讓團隊在長期的開發過程中保證認真投入。使用時間盒的方式工作 是有一些額外的好處的，而有些團隊在采納無迭代的流程時會把這些好處丟掉，這就等于是“連孩子帶洗澡水一起潑出去了”。而使用短迭代，可以減少轉向超輕量 級、無迭代的流程所帶來的痛苦；這也是可以預期的。

人們在轉向無迭代流程時經常會犯一個錯誤，他們會將所有與“迭代”有關系的實踐都拋棄掉。我們要將“迭代”的概念與有附加價值的敏捷開發特定實踐區分開，并尋找能夠減少流程管理成本、同時還可以保留有價值實踐的解決之道。

潛在問題

有人在使用短迭代時遇到了困難。短迭代的擁護者Mishkin Berteig也提到一些潛在的問題 ：

• “密集的工作回讓人筋疲力盡。”我想這是團隊選擇何種工作方式的問題。周期短，不一定意味著工作就一定密集。短迭代可能僅僅 意味著小時間盒；也就是說，每 個時間盒承諾交付的工作更少了。在工作密度上不一定有什么變化。其他的敏捷原則（特別是“可持續的步調”）就是為了防止發生筋疲力盡的情況。
• “戰略層面的思考很難跟日程相結合。”戰略層面的思考跟每個迭代要做的具體工作沒有太大干系。迭代是戰術層面的。戰略層面的思考是……呃，非戰術層面的。這聽起來更像是管理上的問題，而不是短迭代的特性之類的東西。
• “ 每個迭代必須完成的、耗費管理成本的相關任務占用了短迭代的大部分時間。”這似乎又是一個團隊如何選擇工作方式的問題。我曾觀察到擠壓迭代時間長度而引 發的一個有趣結果：人們首先“發現”一些并不是非常必要的管理任務，然后就不再做它們了。最后，團隊只做必要的事情，換句話說，他們去除了流程中的浪費。 實際上，這些觀察讓我對Jim Shore在Java Ranch上的發言持 保留意見。他認為更長的迭代給團隊的壓力更小，因此有經驗的敏捷團隊更適合用長期的迭代。我覺得我們不必在迭代規劃上花費更多時間， 我認為迭代規劃還可以更少些。我支持更短的迭代，如果客戶可以采取拉式的方法以單件流 （single piece flow）的方式提出需求，這些迭代甚至可能逐漸消弭。
• “對團隊之外的資源或是人員的等待，這會使得工作的完成要跨越多個 迭代。”組織上的約束造成了此類狀況。如果試圖采取的迭代長 度過短，以至于組織不能應 對，這樣做并不合適。如果真這么做了，也就不能稱之為“迭代”了，因為不可能在那樣短的時間內交付工作結果，而組織也無法吸收這樣的結果。要想有所進步， 我們必須識別出組織的約束。我并不認為臨時的組織約束（它們是臨時的，只要你真心愿意改變）就會使得短迭代不可行。簡單么？沒人會這么想。但如果組織的變 革很容易的話，那就沒什么樂趣了，不是么？

InfoQ相關內容： Extremely Short Iterations as a Catalyst for Effective Prioritization of Work。

作者簡介

Dave Nicolette自 1977年起就從事IT行業了，他在2002年找到了敏捷，并視其為傳統IT行業很多內在問題的緩解和去除之道。從那時起，在敏捷和精益的思考和實踐上， 他就成為了一名盡心竭力的實踐者和大力鼓吹的提倡者。他喜歡與IT從業人士分享經驗和有益的實踐，并積極參與到敏捷社區的活動中。Dave目前是美國 Valtech科技公司的敏捷團隊教練。

---

志愿參與InfoQ中文站內容建設，請郵件至editors@cn.infoq.com。也歡迎大家到InfoQ中文站用戶討論組參與我們的線上討論。

轉自：

轉載于:https://www.cnblogs.com/lanzhi/archive/2008/11/25/6469771.html

總結

以上是生活随笔為你收集整理的剖析短迭代的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。