為什麼時間盒迭代提倡刪減需求任務？

時間盒迭代（timeboxing/timeboxed iterations）是國際上流行的開發方式，它的特點是每次迭代的結束時間點是固定的，一旦確定，就不允許推遲或變更這個時間。到點時，開發團隊必須提交一個穩定的、通過了系統測試的版本，以便參加評審或向客戶演示。

如果在迭代進行中，開發團隊發現進度落後，無法完成全部的迭代開發任務和計劃的需求功能時，敏捷方法通常允許或要求開發團隊與客戶協商，減少開發任務或需求（可以放入下一次迭代中），以保證在既定的時間點提交高質量的成果（儘管這個成果可能不完整）。

這是為什麼？

也有人擔心，如果因進度緊張，計劃的需求任務老是被推遲到下一次迭代中，那麼是否會導致開發團隊在既定的工期內，永遠都無法實現既定的完整客戶需求？

簡答

當進度滯後的情況發生時，為了確保開發進度，保證按時交付系統，增加人手、提高加班強度、降低質量以及刪減需求任務是一些人們常用的手段。

敏捷方法提倡在一個迭代（固定時間片）內刪減需求任務，這主要是因為其他手段（增加人手、提高加班強度、降低質量等）不適用，或者已採用但仍不能滿足要求。

原理

根據專案管理的基本原理，我們在從事一個軟體開發專案時，往往需要在時間、資源、質量和範圍（需求、內容）等 4 個要素之間進行權衡。



這 4 個因素/因子之間存在著相互制約、相互依賴、相互影響（拉動）的關係。

例如，對於給定的範圍（比方 100 個明確、固定的軟體需求項），如果要獲得較高的軟體質量，往往需要我們在時間和資源上作出更多的投入，即花更多的時間和資源，包括資金、裝置、工具和人力上的投入等等。也就是說，一旦範圍（內容）固定，那麼為了在原有基礎上提高質量，往往需要我們增加時間，或者資源。

假設有一個 10 人的開發團隊，計劃在 6 個月內完成 100 項需求的軟體開發。迭代長度為 1 個月。

如果交付時間固定，比方要求必須在 6 個月內交付，那麼剩下範圍、資源和質量 3 個因素可供調節。如果範圍也固定，必須交付這 100 個需求項，那麼就需要我們在資源和質量這兩個因素之間進行權衡。

在國內外的軟體工程實踐中，普遍存在著大量固定工期、固定費用（比如招投標中）的合同專案。如果開發團隊在專案過程中發現，難以在某次迭代中完成既定計劃中的所有需求項的開發，該怎麼辦？

辦法一

第一種辦法是增加資源（人力等），也就是通常所說的增加人手。著名的《人月神話》告訴我們，簡單地依靠增加人手，來確保 deadline 往往是不可行的，增加新人的結果往往會導致專案延期。

當然，對於那些簡單的、比較確定的專案和任務（比如“電腦打字”類的），增加人手和加班時間，顯然能夠解決問題。通常這類的專案具有線性特徵。如果 1 個人 1 天能完成一件標準工作，而對於以上 10 人的團隊，在 dealine 之前還有 120 件工作需要完成，而剩餘的時間只有 10 天，那麼再增加 2 個人就可以了。

然而，實踐表明，大量的軟體研發專案具有非線性、非確定特徵，無法按照以上簡單、理想的計算結果來確保進度。

辦法二

與加人相關的另一個常用辦法是，增加加班時間，可以與加人辦法一同採用。

儘管 dealine 是不能修改的，工期也有限，總共只有 6 個月，那麼最好是向黑夜要時間，在有限的工期內擠出更多的可用工作時間來。原來規定每人工作 12 個小時（加班 4 小時），如果進度來不及，還可以嘗試進一步延長加班時間，比如讓每人的工作時間為 14 到 16 個小時等。當然，最好是三班倒，不分白天黑夜地幹，這樣每天 24 小時都被充分利用了。

事實上，加人、加班的確是業界（尤其勞動密集型產業）常見的對付進度滯後、工期偏緊的辦法。

然而，加人、加班共有的一個缺陷是，它們都有一個上限。加人意味著企業成本的增加，需要拆東牆補西牆，無法無限制地增加人數；而加班超出限度，會導致員工疲勞，生產力下降，進而導致質量下降，反而無法實現進度目標。

辦法三

如果不能加人、加班，或者即使加人、加班也不能滿足要求，那麼降低質量也是一個辦法。我確實聽說國內外有不少團隊為了實現 deadline 目標，獲得客戶/使用者和領導們的最大滿意度，或者贏得最佳的 time-to-market，寧願犧牲或降低質量，也要按時準點交付。

降低質量有很多種手段。實在來不及了，省略測試，或者乾脆不做測試，或者放棄修正以有的 bug 就交付，是常見的做法。

這種做法有一個明顯的缺陷，就是可能會帶來質量後遺症。表面上是按時交付了，各種需求都滿足了，可以使用，但由於隱藏著質量問題，開發團隊不得不在釋出之後繼續花更多的時間一邊開發新功能，一邊修正以前殘留的質量問題。

另一方面，任何釋出的軟體都不可避免的存在一些或大或小的錯誤，即使經過了嚴密的測試。要避免質量後遺症，如何把握、掐準釋出/交付的質量門檻是一個關鍵。

辦法四

如果資源、質量都不能變動，或者加班、加人、降低質量都無濟於事，那麼還剩下一個因素可以調節，也就是範圍。減少範圍，在迭代中刪減或不再增加新的開發任務，同時不刪減質保活動，集中團隊的精力解決現有問題、完成現有任務，就能保證在規定時間內不斷地交付較高質量的產品（或其一部分/增量）。

通常以上 4 種辦法可以結合起來運用。在進度滯後、既定任務計劃完不成的情況下，為了確保進度/趕進度，人們通常想到的辦法首先是加班，也就是增加現有人員的有效工作時間；如果加班不行，那麼就加人，增加人手；如果加班、加人還不行，那麼可以降低質量，減少精雕細琢的行為，把主要精力放在主要任務上；可是，如果降低質量還不能滿足進度，怎麼辦？

在時間、進度緊迫的情況下，交付一個功能、需求可能不完整但是質量較高的系統，與交付一個功能、需求完整但是質量較低的系統，哪一種結果更好？客戶會更喜歡哪一個？恐怕我們不能一概而論。

以上就是為什麼開發團隊遇到此類情況時，以時間盒迭代為特點的當代敏捷方法通常推薦我們在迭代的進行過程中，減少計劃完成的需求或任務，並根據迭代中可用的時間片來安排、填充迭代任務的原因。

總之，為了保證開發進度，當既不能加班、加人，也不能降低開發質量時，與客戶或產品經理等需求管理者進行協商，減少迭代中待開發的需求任務是更為合理的選擇。當然，如果開發團隊發現進度超前，自己還有餘力接受更多的任務時，敏捷方法也鼓勵增加需求任務。

不管增加還是減少需求任務，都是敏捷方法進行適應性計劃、靈活和 just-in-time 任務排程的一個選項。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13633641/viewspace-600465/，如需轉載，請註明出處，否則將追究法律責任。