在運用敏捷式產品開發與專案管理方法時，我們知道，應該以「對用戶的價值」的角度來對工作（用戶故事 User Story）的優先級做排序（參考《能讓需求簡化，還能更省時、更省錢，提供更多價值，這…可能嗎？》一文），然後，將這些工作，「依序」安排到固定週期的各個衝刺（Sprints）去，並且盡可能地將每個衝刺都塞滿、都最佳化（參考《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》一文）。

 

但是，就算規劃得再完美，一定還是會有意外狀況，導致這些規劃好的事情生變。例如，在衝刺結束時，某些該完成的用戶故事，卻無法被驗收！這該怎麼辦？

 

當我們要計算這個衝刺的速度（完成了多少點數 Points），以便團隊能檢討改進，加速下一輪衝刺的速度之時，這些沒完成的用戶故事，其所含的點數，到底該如何計算呢？

 

有許多人會習慣使用「完成百分比」的方式，將那個未完成用戶故事的點數，部份地計入這個衝刺的「完成點數」，但是，這樣做會不會有什麼問題呢？

 

「完成百分比」運用在某些領域的工作上，可能不會有什麼大問題，例如，建築專案中的砌牆工作，工人砌磚的速度是可以被較為精準地估算出來的，因為，這類工作沒有什麼太大的風險和意外。所以，當你聽到一位砌磚工人說他花了五天完成了 50% 的砌磚工作，你可以大膽地估計，他還需要五天就能完成所有的砌磚工作（100%）！

 

可是，對於一些創意類的工作來說，例如，研發、設計等，工作的完成度可就沒有這麼簡單了！

 

您有沒有見過這樣的進度回報狀況：10%、20%、30%、...、90%、95%、99%、99.1%、99.2%...

 

是的，這就是許多創意類工作者的進度回報狀況。為什麼會這樣呢？

 

理由很簡單，因為創意類的工作，本來就很難將工作的進度量化、估算得很準，但是為了要能回應專案經理、產品經理，或老闆的對工作進度的追蹤，所以才會在週報當中給出像 10% 到 90% 這種等比例的進度資訊，然而，它們卻是假的資訊，只不過是為了給進度而給進度罷了！

 

好了，當時間愈來愈逼近工作的 deadline 的時候，我們就會開始得到像 91%、92%、93% ... 這種又是等比例，但是百分比間隔卻變小的進度回報！換句話說，這個時候工作者在週報上回報的進度，變成只有之前的 1/10 了！

 

再過一陣子，我們又會發現，工作者的進度回報會變成 99.1%、99.2%、99.3% … 這種更誇張的型態！

 

舉個例子來說，軟體開發人員的程式設計工作，不但需要完成程式碼的撰寫（coding），還必須要通過所有的測試（unit test, integration test...），這樣才能夠宣告這項軟體開發工作的進度是 100% 地完成。

 

可是，在實務上，我們經常發現到，許多軟體開發人員都沒有放太多的心思和心力在「測試案例」的設計上。因此，「程式碼撰寫完成」往往只不過達到實際進度的一、兩成罷了，其實後面還需要花費八、九成以上的時間來抓那些還沒被發現到的臭蟲和瑕疵（bugs、issues）！此時，大多數的軟體開發人員卻看不見後面的這些巨大 efforts，故而將進度回報到 90%！

 

等到巨量的臭蟲和瑕疵不斷地被品保人員發現之後，開發人員才疲於奔命地回頭去找問題的根源，不僅曠日費時，也不知何時才能夠收斂完畢！此時，開發人員就只能從 91% 開始回報進度，等用到 99％ 之後，也只能繼續用 99.1% 來開始回報進度了！

 

上面的例子告訴我們，創意類型的工作，在沒有經過完整的測試和驗收之前，進度都只能說是 unknown，所有百分比形式的進度，也都只是自欺欺人的說法而已！

 

所以，在敏捷方法當中，我會建議，只要是某個用戶故事沒有被驗收通過，那麼，該故事的進度就是「零」個點數，根本就不該被「部份納入」衝刺的進度！

 

等到開始規劃下個衝刺時，開發團隊自然會將這些未完成的用戶故事排進去（只要它們的優先級相較於其他的用戶故事仍然是較高的情況），也應該花費較少的時間就能完成它們了，這些用戶故事的「原始點數」當然也就會被完整地計入下個衝刺的進度計算當中，開發團隊實際花費在這項工作的時間，並不會被忽略掉。

 

在下下個衝刺的規劃之時，開發團隊會，也應該，把前幾個衝刺的速度做個平均，以做為這次衝刺的速度的參考依據。此時，前幾個衝刺的速度差異和變異，也就會被平均模糊掉了。在數個衝刺之後，開發團隊一樣能找出較為精準的團隊開發速度感，也就會讓每個後續衝刺能容納的點數（衝刺容量）的估算更為精準了。