軟體專案估計與計畫

在《Software Estimation》的第一章，有談到估計和計畫的關係：

估計和計畫是兩個相關的議題，但估計不是計畫，計畫也不是估計。..估計應該是客觀的分析過程，而計畫則是主觀的目標求解過程。估計的目的是得到準確的結果，不是尋求特定的結果；而計畫的目的則是尋求特定的結果。我們刻意（適當地）讓計畫傾向某個方面，以得到特定的結果。

然後是一個有趣的例子：

主管：你認為這個專案需要多少時間？我們要在3個月內為展覽會準備好這個軟體。我不能給你更多的團隊成員，所以你必須用現有的人手來完成工作。這是我們需要的功能清單。
專案負責人：OK! 我先去算出一些數字再來找你。
然後……
專案負責人：我們估算這個專案需要 5 個月。
主管：5 個月！你剛才沒聽清楚我說的嗎？我說的是要在 3 個月內為展覽會準備好這個軟體!

Note: 當有人要求你提供軟體估算時，要確定他是期望你進行客觀的估算，還是期望你給出如何到達目標的計畫。

計畫是一種猜測

我曾跟某位同仁說：「軟體專案的 dead line 其實只是一種 best guess。」這話聽起來像是托詞，為進度的 delay 找藉口。但，那只是其中一種用途。

在《工作大解放》一書中，有一篇標題為「計畫是一種猜測」的文章是這麼說的：

除非你是算命師，否則長期的商業計畫就只是幻想。市場上有太多你無法掌控的因素：市場條件、競爭對手、顧客、經濟情勢等等，你以為寫計畫書就可掌控這一切，但其實你做不到。
我們何不把這些計畫正名為：猜測。商業計畫就是「商業猜測」、財務計畫就是「財務猜測」，而策略計畫就是「策略猜測」。既然計畫只是猜測，你再也不必為此如此煩心，因為不值得。
擬訂長期計畫的時機也不合理。可參考資訊最多的時刻，是事情正在進行時，而不是在你著手進行前。但你通常是在什麼時候寫計畫書呢？就在你開始執行之前，那是制訂重大決策最壞的時機。
我不是說你不應該思考未來，或是思索如何迎戰即將到來的障礙。這是很好的練習，但不必覺得你得將這些想法記錄下來，或念念不忘。你要是真的寫下什麼大計畫，你很有可能永遠不會再去看它，數十頁的紙上計畫只是淪為你檔案櫃裡的化石罷了。
停止猜測吧，決定這星期內你要做的事，而不是這一年。弄清楚下一個最重要的事，然後就動手去做。在你要進行某事之前做出決策就好，不要過早。

我想，先縝密計畫再依計畫執行而成功者，亦大有人在。我只是覺得「計畫一點、實作一點」的方式比較適合我而已。

但我也知道，這種方法往往很難說服頂頭上司，或其他從未開發過軟體專案、卻需要盯進度的人。有的人要看美美的甘特圖，但我們更需要真正能讓專案開發有進展的東西。因此，一種折衷的作法，或許是一邊做計畫，一邊手底下盡快做些小實驗，同時祈禱你有足夠的時間。

估計究竟能多準？

同樣摘自《工作大解放》的其中一篇文章「你的估計能力爛透了」：

我們都是差勁的預估者。我們以為能猜出某件事情需要多久來完成，但我們其實一點概念也沒有。我們判斷事情的進展，都是根據最佳狀況，也就是不會因為不可避免的突發事件而拖延。但現實情況向來跟最佳情境不一樣。這就是為什麼對未來數週、數月和數年的預測是種幻想。事實上，你根本不能很早預知即將發生的事。 

另外，當我們猜想某件事需要多少時間來完成時，我們不只是小失準，而是錯得很離譜。這意味，如果你猜六個月，實際所需時間可能不只六個月，而是一年。......解決的辦法就是把大事化分成數件小事。要辦的事情規模愈小，就愈容易預測。你有可能還是會得到錯誤的答案，但跟估計重大計畫相比，錯誤會少很多。

我不禁想到 Scrum ....