產品設計體會（五一）敏捷的估計與規劃

前段讀了《敏捷估計與規劃》，這本書很適合開發經理看，我只是很快的瀏覽了一下，摘錄一些體會。

ø敏捷的里程碑是功能驅動的，先完成可交付的最「重要」功能，重要取決於功能商業價值、生命週期、實現難度等綜合的結果。而傳統的瀑布模型的里程碑是任務階段驅動的，到了專案

50%的時間，可能進入「編碼」，但對客戶來說，等於

0%。而且這樣的模式會陷入「實現難度決定開發順序」的不合理模式，因為這裡有個不合理的假設前提：所有功能都能夠完成、必須完成，中間過程對客戶是透明的。

ø專案估計的不確定性是會累積的，

80%×

80%×……，所以開始訂的專案計畫，在乙個月後已經面目全非，強行的遵守是沒有意義的，而應該不斷的修正計畫，當然，更好的做法是一開始的計畫中間留有一些柔性的內容。

ø隨著時間變化，必然有新的資訊出現，特別是瞬息萬變的網際網路業界，死守著開始的專案計畫不調整是沒有邏輯的做法，敏捷的迭代剛好權衡了變化的成本和不變的成本，就是：不變本次迭代，更新下次迭代，這是乙個將專案計畫細化粒度的做法。

ø需求唯一不變的特徵就是「不斷變化」（

plus

不斷細化），敏捷的思想就是歡迎變化，擁抱變化。瀑布模型一次性完成的需求分析，會存在「過度需求」的問題，降低整體效率。

專案管理理論的發展，從開始混亂，每個專案自有一套，每個pm自有一套；到後來人們非常想訂出乙個統一的簡單的流程，減少人為影響（瀑布模型等出現），；再後來進入靈活的敏捷，看似又變得混亂，實則有序。又是宛如那個哲學的三段論：見山是山à見山不是山à見山還是山；也如管理的三個境界：人治à法治à無為而治。

產品設計體會（五一） 敏捷的估計與規劃