※ 引述《TonyQ (自立而後立人)》之銘言：
: 覺得有點感觸，來寫一下這幾年我對軟體專案的幾個看法，
: 如果估計的時間有出入，通常都是 spec 的認知有出入，
: 那時候該釐清的是 spec 細節跟重新估算。
: 而不是在那邊「我覺得要一個月」、「但我覺得要一週」，
: 這種愚蠢的菜市場喊價。
「時程估計」是 PM 與 Dev 之間的 eternal conflict 。有的時候
不是 PM 故意找麻煩，而是 PM 的上級在逼 PM 說出一個日期。
感覺上，以下這個模式是個還不錯的平衡點
(1) 很明顯要花五天以上去作的部分，應該重新檢視，拆成更小的部
分
(2) 很明顯是一天以內能作完的事 (尤其是很制式的流程) ，應該研
究將其自動化的可能性，及編列預算
(3) 兩天至五天內的部分 (尤其是無制式流程可參考的時候) ，雙方
要達成以下共識:
(a) 視情形，先花 1/4, 1/6, 或 1/8 的時間試作看看，試試水
溫
(b) 試作時間結束後，很簡短地開個 stand-up 會議， Dev 告
之 PM 他對原始時程估計值的 "gut feeling"
(c) 誠實地調整原始估計值
* 讓 PM 成為你的盟友，幫助他建立 burn down chart ，掌握專案
進度，讓他的上級閉嘴
* 讓 Dev 成為你的盟友，一旦 Dev 願意合作建立 burn down chart,
除非你帶給他們 free food, 不然別再去煩他們
============================================================
以上這模式有個前提: 管理者不是昏君，團隊裡沒有賤人