軟體專案估計與計畫


在《Software Estimation》的第一章,有談到估計和計畫的關係:
估計和計畫是兩個相關的議題,但估計不是計畫,計畫也不是估計。..估計應該是客觀的分析過程,而計畫則是主觀的目標求解過程。估計的目的是得到準確的結果,不是尋求特定的結果;而計畫的目的則是尋求特定的結果。我們刻意(適當地)讓計畫傾向某個方面,以得到特定的結果。

然後是一個有趣的例子:
主管:你認為這個專案需要多少時間?我們要在3個月內為展覽會準備好這個軟體。我不能給你更多的團隊成員,所以你必須用現有的人手來完成工作。這是我們需要的功能清單。
專案負責人:OK! 我先去算出一些數字再來找你。
然後……
專案負責人:我們估算這個專案需要 5 個月。
主管:5 個月!你剛才沒聽清楚我說的嗎?我說的是要在 3 個月內為展覽會準備好這個軟體!
Note: 當有人要求你提供軟體估算時,要確定他是期望你進行客觀的估算,還是期望你給出如何到達目標的計畫。

計畫是一種猜測

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

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

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

估計究竟能多準?

同樣摘自《工作大解放》的其中一篇文章「你的估計能力爛透了」:
我們都是差勁的預估者。我們以為能猜出某件事情需要多久來完成,但我們其實一點概念也沒有。我們判斷事情的進展,都是根據最佳狀況,也就是不會因為不可避免的突發事件而拖延。但現實情況向來跟最佳情境不一樣。這就是為什麼對未來數週、數月和數年的預測是種幻想。事實上,你根本不能很早預知即將發生的事。 
另外,當我們猜想某件事需要多少時間來完成時,我們不只是小失準,而是錯得很離譜。這意味,如果你猜六個月,實際所需時間可能不只六個月,而是一年。......解決的辦法就是把大事化分成數件小事。要辦的事情規模愈小,就愈容易預測。你有可能還是會得到錯誤的答案,但跟估計重大計畫相比,錯誤會少很多。

我不禁想到 Scrum ....


2 則留言:

  1. 《工作大解放》好書一本!

    這應該也是為什麼專案十之八九都會delay的原因吧。

    回覆刪除
  2. 的確是好書。
    91 這麼「早」還沒睡啊! ^_^
    Good night!

    回覆刪除

技術提供:Blogger.
回頂端⬆️