趕工計畫

Jan. 11 12:40~13:30

 

上禮拜六在上「Scrum敏捷方法實作班」的時候，講到敏捷方法如何規劃產品釋出計畫（release plan），以及如何透過release burndown chart（釋出燃盡圖）來追蹤與管理釋出計畫。基本上有兩種模式：

▼固定交期，變動範圍：產品釋出日期不變，但範圍（需求數目）可變。這種模式稱為價值驅動開發，每次開發功能都選擇對使用者價值最高的，如此一來就算原本預計的時間到了但是全部的功能沒有都做完，已經完成的功能還是對使用者有足夠高的價值，可以交付給使用者。

 

▼固定範圍，變動交期：產品範圍不變，釋出時間可以改變。這種模式很容易造成產品延後釋出，而且因為規劃的全部的功能一定都要完成產品才可以釋出，對開發團隊而言這些功能的優先順序就不是那麼重要（反正不管誰先做最後全部都一定要做完）。這種無法聚焦與分辨優先順序的心態更容易造成產品的延遲。

***

講到這裡有一位學員問了一個問題：

學員：為什麼沒有catch-up plan（趕工計畫）？傳統的專案都會有趕工計畫，功能不可以縮減，時間也不能延後，看是要加人還是加班，總是要擬定一個這樣的計畫。

Teddy：如果趕工計畫可行，為什麼不一開始就實做這個趕工計畫？把它放到正常計畫之中，這樣不就不會延遲了嗎？

學員：嗯….

Teddy：我想沒有任何的開發方法可以保證在規劃的時程內一定可以把全部的功能都做完。傳統的專案管理只管專案是否準時完成，但很可能因此忽略完成的產品是不是客戶需要的（plan-driven專案管理方式），這也正是敏捷方法所要避免的陷阱。

***

不是不能訂定趕工計畫，但請不要落入「因為我有趕工計畫，所以我的專案一定能夠如期、如質完成」的假象。在變動的環境中，回應改變比死守計畫來的有用。

***

友藏內心獨白：誰可以給我反攻大陸的趕工計畫？