如何做軟體專案的估計

開始前請先準備好紙筆

等等會用到

快去拿

找到了嗎

騙人

真的啦快去拿紙筆

好了齁

好的關於估計軟體專案阿

這真的是很難的題目

概念是用經驗來做估計

原則是把大事情盡量切成小事情

來分別做估計再加起來

沒錯很籠統

但還是可以簡單聊聊兩種門派的做法

同樣的沒有絕對的好與壞

請依照專案的性質與團隊的做事方法來選擇

waterfall

在waterfall的流程來說

估計就是要…

準!

而做估計的那個人

通常是說話最大聲或

最有份量的人

比如說最資深的工程師

PM

或業務客戶

甚至是老闆本人

這個人說了需要多久以後

再加一點buffer

就是你的軟體專案的deadline

我已經介紹完了第一種方法了

身為PM的你

會不會覺得念了一大堆書都浪費了?

因為這沒甚麼學問

讀聖賢書所為何事

而且

這樣估出來根本他媽的不準

來看看好一點的waterfall的估計方法

還記得你剛剛找到的紙筆嗎?

我們來估計你下班從公司回到家需要

的時間

第一步

請你在紙上寫下

一般狀況下你回家所需要的時間

令這個值叫做N(normal的意思)

第二步

請你在紙上寫下

最樂觀的最順利的狀況下回到家所需要的時間

令這個值叫做O(是英文字母那個ㄛ，不是零)

(Optimistic的意思)

第三步

請你在紙上寫下

最悲觀的最慘的狀況下

回到家所需要的時間

令這個值叫做P(Pessimistic的意思)

以上

套用機率模型

期望值是( O + 4N + P ) / 6

令 E = 你算出來的期望值

算好了嗎?

標準差是( P – O ) / 6

令 stddev = 你算出來的值

算好了嗎

套用機率模型Normal distribution…

在正負一個標準差之內的機率是68%

在正負兩個標準差之內的機率是95%

你現在可以估計出今天回家

有68%的機會會在E-stddev 到 E+stddev之間

而有95%的機會會在

E-2*stddev 到 E+2*stddev之間

ㄟ，你剛剛有跟著算吧?

同樣的

假如你的軟體專案是屬於某一個人來喊時間的那種

請用這種機率模型來做估計

會比較科學一點

這套方法叫做PERT法

Program Evaluation

and Review Technique

可是

一開始有說原則是

把大事情切小分別做估計再加起來

那用PERT法怎麼做?

同樣的對每件小事情給NOP三個值

算出E跟stddev

現在你手上會有一堆小事情的E跟stddev

你的大事情的期望值就是把所有E的總和

就是把E全部加起來令他是E_total

標準差stddev_total比較麻煩

請把每一個stddev平方加起來再開根號

你現在有E_total跟stddev_total了

一樣套用機率模型

我有68%的信心指數可在E_total正負stddev_total

時間內完成

而95%的機會可在E_total正負兩倍stddev_total

時間內完成

身為PM的你如果說出以上的話

人家應該會覺得你很有學問吧?

講完了waterfall的方法了

一個是喊巴辣拳一個是

PERT法

如果你是用waterfall開發我非常推薦PERT法

休息一下呼~

嚇!

88頁了

再休息一下湊90頁再出發好了

90頁了…

接下來看看agile的作法

請再次拿起你的紙筆來

好了嗎?

請看下面這張圖

來源http://hdw.eweb4.com/out/440195.html

請在紙上寫下

紅色圈圈的大樓是綠色圈圈大樓的幾倍高?

我再給你看一次圖

來源http://hdw.eweb4.com/out/440195.html

接下來請你在紙上寫下

紅色與綠色圈圈的大樓的高度

單位請用公分

是的公分!!

我再讓你看一次圖

來源http://hdw.eweb4.com/out/440195.html

認真的啦! 公分啦!!!

好了齁~

接下來請你在紙上寫下

這兩棟大樓的高度一樣用公分

只是這次請把地下停車場的深度也估進去

沒錯地下停車場!!!!

我再讓你看一次圖

來源http://hdw.eweb4.com/out/440195.html

對，你看不到地下停車場

但，你還是要估

好了沒?

再等你一下

好了齁~

接下來請你在紙上寫下

紅色圈圈的大樓是綠色圈圈大樓的幾倍高?

包含地下停車場喔~~

再給你看一次圖

來源http://hdw.eweb4.com/out/440195.html

好的我們做了四次估計

相對的估計兩次

(幾倍高?)

絕對的估計兩次

(用公分)

ㄟ，你有跟著玩吧?

有參與吧?

請問!!

你覺得那個比較簡單直覺?

那個比較能處理未知數?

(地下停車場)

你覺得用公分來估計大樓高度

合理嗎?

有意義嗎?

遊戲結束

這個故事帶給我們的啟示是

第一

用無意義的單位來做估計是無意義的

用人天來估計軟體專案就好比

用公分來估計大樓高度

30人天的事情你找10個人來

3天就做得完嗎?

第二

相對的估計比絕對的估計好

所以

綜合來說

這個feature是那個feature的幾倍難

會比

這個feature需要20人天而那個feature需要30人天

來得好

這兩個是agile的估計的原則

還有另外一個原則

就是

請讓開發團隊全體成員來做估計

不是PM

不是資深的軟體工程師

更不是業務客戶老闆

(不過還是要尊重老闆啦…)

再次強調是

全體開發團隊

接下來

我要講最重要的一點了

重要到我都想把每個字換成紅色的了

就這樣做吧!

估計不是為了準確

是在讓大家提出對策

估計不是為了準確是在

讓大家提出對策

估計不是為了準確是在

讓大家提出對策

估計不是為了準確是在

讓大家提出對策

估計不是為了準確是在

讓大家提出對策

估計不是為了準確是在

讓大家提出對策

因為很重要所以我又講了三次

估計準的話很好

不準的話沒關係

但要確保身為PM的你

對估出來的結果有對策

而且

要每隔一段時間就做一次估計

修正方向與策略

你才能帶領團隊往你的理想前進

講完了

關於agile的估計我們來複習一下

1. 用相對的方法來估(不用人天作單位)

2. 找全體團隊一起做估計3. 估計是為了採取相對應的對策，而不是為了準

這很難

但請記得第一篇講的

軟體專案越快開始越好

你的schedule壓力會越小

而更能盡早採取對策面對專案的未知數

最後

我們總複習一下

Waterfall

1. 強力推薦用PERT法2. 估計就是要準!!

Agile

1. 用相對的方法去估計2. 不要求一定要準，而是盡快採取對策

至於agile是怎麼用相對的方法

去做估計

那是開發團隊的事情

身為PM

其實不需要知道

如果有興趣的話

可以去google

“planning poker”

或是找個內行的問一下

還有一件觀念你也一定要具備

在軟體專案裡面

難的事情不一定要花很多時間

可能開個硬體加速就好了

簡單的事情不一定不用花時間

比如說UI 基本上不難

但要做到漂亮是很花時間的

所以難度跟時間

不一定是正相關的!!

這也超重要

最後提醒一件事

估計啊

其實是猜

或許你也或多或少有感覺吧？

但是對接收者來說(通常是你的長官)

他們接收到的是承諾

其實當團隊把他們估出來的數字給你的時候

他們其實也是在猜測

你也是把這數字當作是承諾

把猜測的結果當作是承諾

是很危險的

這也是我覺得估計

之所以這麼難搞的原因

所以

要結束了

我說了甚麼?

1. Waterfall的估計2. Agile的估計3. 時間跟難度不是正相關4. 把估計當承諾是危險的

建議你往回走幾頁去看總複習那頁

以上報告完畢

希望能幫到你

超過200頁了bye~