時間盒迭代刪減任務會導致完不成原定開發計劃？

簡答

的確，存在這種可能性，由於在迭代開發中不斷刪減或推遲既定任務，導致既定的整體開發計劃無法完成。如果每次迭代都有任務不能及時完成，需要放入下一次迭代（發生了擠出效應），那麼累積的結果很有可能是最終無法完成事先計劃的所有需求任務。

不過，還存在另一種可能性，儘管在某次或某些迭代中，我們刪減、推遲了某些需求或任務，但最終還是趕上了進度，所有計劃的需求仍然可以在 deadline 之前完成（未發生擠出效應）。

我想，對於任何軟體開發專案，這兩種可能性都不能排除。究竟哪一種可能性更大，專案最終能不能按計劃完成，其實不到最後一刻（或最後兩週），我們並不能確切的（100%）知道。因為，用科學的術語說，軟體開發本質上是一種探索性的、非線性的、不確定過程。

所以，簡單的回答是，時間盒迭代刪減需求任務，不但不一定會導致既定的開發計劃和所有客戶需求最終無法完成，相反，與加班、加人、降低質量相比，它卻有可能是一種相對合理的、最佳有效解決辦法之一。

正確的因果

導致進度滯後的原因有 n 多種，有一些是由不合理的意外（人為失誤）造成的，而有一些是由於合理的意外（人為無法控制）造成的，比方主力開發人員意外生病/住院等等 ...

這裡我們首先應該明確一個因果問題：

究竟是因為我們在迭代中刪減或推遲了任務的完成，導致整體的釋出計劃最終無法完成，還是因為開發進度滯後的現實情況已經發生，導致我們不得不選擇刪減或推遲任務？

我想，我們在這裡討論的是後者。也就是說，如果在實際開發中，已經發生了進度滯後的情況，我們該怎麼辦？

此時，刪減或推遲一些迭代任務是可選項。那麼，它會不會導致最終專案計劃無法按期完成？前面提到，答案只有兩個，yes or no。如果不能完成，我們也不應該感到遺憾，因為進度滯後（落後於計劃）的情況在我們採取行動之前已經發生了，我們不過是做出努力，盡力彌補。

而如果一切工作都能按照我們預先制定的進度計劃完成，自然也不需要我們刪減需求或任務。

這是一種正確的因果邏輯。

那麼，在進度已經滯後的情況下，如果採取加班、加人、降低質量等措施，是否也會最終導致計劃完不成？情況可能各有不同，但處於開發的程式中，有誰能夠擔保，不刪減需求任務，通過加班、加人就能 100% 地完成事先制定的計劃（所有客戶需求）？

計劃的不確定性

當人們提出諸如“客戶的需求計劃能不能完成？完不成怎麼辦？...”此類的疑問或擔心時，往往隱含著這樣一種誤解：任何計劃（包括固定工期、固定費用的），只要是由聰明的人類作出的，都應該 100% 完成；如果完不成，那麼就是由於開發商、工程開發人員的無能，或者不努力、消極怠工所造成的。

假設，開發商事先向客戶承諾計劃用 10 個人在 6 個月內保證完成 100 項需求的開發。問題的關鍵是，這樣的事先承諾具有多少科學性（依據）？

人們（尤其管理者）普遍存在這樣一種誤解，只要是制定計劃，就一定能 100% 的完成。而且基於這種 100% 的決心，信心滿滿地向客戶/使用者作出了承諾，一旦做不到 100% 的交付，就要怎樣怎樣怎樣。

然而，軟體工程 40 年發展所反映的事實情況又如何呢？任何事先制定的計劃其實都只是一種對未來情況作出的預測，任何軟體開發專案或多或少都存在著一定數量的風險。您是否聽到過，或者親身經歷過風險為 0 的專案？只要存在著風險，人們在正式開發之前所作出的各種預測計劃就有可能完不成。所以，專案的實際情況能否完全按照計劃執行，存在一個發生概率/機率的問題。即便成功完成的把握非常大，達到 99.999%，那也存在 0.001% 失敗的可能。不同專案的實際進展，可能完全符合人們預先制定的計劃，也有可能與計劃有較大的偏差。誰都不能排除發生任何意外的可能（除了神仙）。

計劃，與計劃的實際執行情況，是兩個不同的概念。決心不同於現實。所以，我們說，跟蹤、確保計劃的執行比制定完美的計劃更重要。

在發生進度滯後的情況下，確保原定計劃實現的辦法，在迭代開發中有多種選擇，比如加人、加班、降低交付/釋出質量、減少需求任務等等。我們在這裡探討了為什麼敏捷迭代開發提倡刪減任務，而不是一味地加人、加班或者降低質量。

為了確保開發進度，加班是人們常用的手段。但加班可以利用的時間有一個上限，一個 10 個人的團隊，如果每天 24 小時工作，連續工作 6 個月，可用的時間資源上限為 10 * 24 * 6 * 31，這是一個常數。如果預測實際的工作量超過了這個最大數值，那麼再怎麼要求員工加班可能都是無濟於事的。

也有人認為，我們可以通過大量增加人手來保證進度。如果 10 個人完不成，那就再加 10 個人，怎麼樣？的確，有的專案通過增加人手，增加加班時間可以完成。

而也有的專案，簡單地通過增加人手和加班，是無效的。比方，專案遇到一個棘手的技術難題，團隊始終找不到一個最優的演算法來解決系統的效能問題，而效能不能獲得改善，系統將無法交付，客戶也不同意驗收。此時，不但現有的 10 個人完不成，即使再找到 100 個人，如果能力不夠，恐怕一時也完成不了。這說明，在這類專案或這種情況下，能不能保證進度、完成計劃、按時交付，與人數多少無關，與人的能力有關。

這就是軟體開發本身以及軟體開發計劃的不確定性。

軟體開發、軟體工程中往往會涉及到很多科學問題，而解決許多科學問題，依靠的是恰到好處的智力，而非簡單的人數乘以體力。100 個人通常比 10 個人能舉起、拉動更多的重物，而 100 個人未必比 10 個人更聰明，能解決更多的科學問題（比如軟體設計中的）。如果靈感到了，可能幾個小時就能解決，而如果靈感和經驗不足，可能一些問題即使花上半年也解決不了。

對於固定工期和費用的專案，在不適合採用加人、加班、降低質量等手段的前提下，敏捷迭代方法推薦採用刪減需求開發任務（或調整需求）的建議顯然是合理的。在質量和範圍的這對權衡關係中，敏捷方法選擇了縮小範圍，而不是輕易地降低質量。

另一個問題是，在同樣的情況下，傳統的做法能否保證計劃完成？

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