在運用敏捷式產品開發與專案管理方法時,我們知道,應該以「對用戶的價值」的角度來對工作(用戶故事 User Story)的優先級做排序(參考《能讓需求簡化,還能更省時、更省錢,提供更多價值,這…可能嗎?》一文),然後,將這些工作,「依序」安排到固定週期的各個衝刺(Sprints)去,並且盡可能地將每個衝刺都塞滿、都最佳化(參考《敏捷方法的成功密技(十一):Scrum 如何最佳化利用衝刺的容量?》一文)。
但是,就算規劃得再完美,一定還是會有意外狀況,導致這些規劃好的事情生變。例如,在衝刺結束時,某些該完成的用戶故事,卻無法被驗收!這該怎麼辦?
有許多人會習慣使用「完成百分比」的方式,將那個未完成用戶故事的點數,部份地計入這個衝刺的「完成點數」,但是,這樣做會不會有什麼問題呢?
「完成百分比」運用在某些領域的工作上,可能不會有什麼大問題,例如,建築專案中的砌牆工作,工人砌磚的速度是可以被較為精準地估算出來的,因為,這類工作沒有什麼太大的風險和意外。所以,當你聽到一位砌磚工人說他花了五天完成了 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,所有百分比形式的進度,也都只是自欺欺人的說法而已!
所以,在敏捷方法當中,我會建議,只要是某個用戶故事沒有被驗收通過,那麼,該故事的進度就是「零」個點數,根本就不該被「部份納入」衝刺的進度!
等到開始規劃下個衝刺時,開發團隊自然會將這些未完成的用戶故事排進去(只要它們的優先級相較於其他的用戶故事仍然是較高的情況),也應該花費較少的時間就能完成它們了,這些用戶故事的「原始點數」當然也就會被完整地計入下個衝刺的進度計算當中,開發團隊實際花費在這項工作的時間,並不會被忽略掉。
在下下個衝刺的規劃之時,開發團隊會,也應該,把前幾個衝刺的速度做個平均,以做為這次衝刺的速度的參考依據。此時,前幾個衝刺的速度差異和變異,也就會被平均模糊掉了。在數個衝刺之後,開發團隊一樣能找出較為精準的團隊開發速度感,也就會讓每個後續衝刺能容納的點數(衝刺容量)的估算更為精準了。