Ruddy Lee 分享空間

Emergent Design 演化設計

工程師如何估算工時?

leave a comment »

當上級過來詢問『這個工作要作多久?』你要怎麼回答呢?

範圍呢? 它可能是:

* ㄧ個功能的小修改。
* 新增一個完整的功能。
* 一個人的專案開發。
* 一個3到5個人的開發團隊要接手一個新專案。
* 一個古老系統的重新開發,人力、時程…,都要一起估算。
* …
* 哈,可能只是一個構想,但總要估個時間來作參考啊。

而你可能是一個工程師或是這個專案的負責人,請問要如何估算開發的時程呢?

.

(基本上;不管你怎麼估算,都不會太準確的《這是軟體開發的特性,不是個人的問題,別太在意》。不如花一點時間,多收集一些資料,然後運用參考、比較的方式來進行估算,這樣會準確許多。但! 這還是在猜測。 不如針對整個開發團隊訂下簡單的規範,讓大家一起來遵循,會有意義的多。以下是我建議的做法: 「信心點估算法」)

.

長久以來,我們都用直覺或是猜測的方式來回答這個問題,即便是曾經作過,有經驗可供參考。但基本上;還是很難像補輪胎的師傅一樣的回答: 大約 10 分鐘!

.

※ 對個人而言

工程師由第一天開始寫程式開始,就會被不斷的問到這個問題,怎麼回答呢? 老實說,只要你是用猜的,他就不會準! 但;如果不用猜的話那要怎麼辦。正式的回答是:

「給我一點時間,讓我進一步了解一下! 」

— 接著; 用科學的方法: 盡快的依靠觀察、組織、搜尋,用切割成小的區塊再整合起來的方式去架構出來你需要的估算,最基本的作法就是切割成小組件來估算,在一塊兒的加總起來(Divide and Conquer)。

.

老闆當然不會給你太多時間去進一步了解一下的! 很快的,工程師就必須給出一個預估的時間(把我這篇文章給老闆過目一下,老闆在閱讀的時候還可以換取一些時間),接著呢! 這時候;就應該趕緊去理解這個問題,要明白當你越快弄清楚了,成功的機率就越大!(軟體開發的過程,就是一種學習的過程,學得越好,程式才會越正確)

 

估工時2

圖一. 運用信心點的估算方式

請注意!

第一次的估算純粹是猜測,不是承諾。要我真正的承諾,等我的信心點出現。

第二次的估算,是有信心後的估算,它是承諾。

上面這一張圖是我上課的時候常常建議給學員們的方式,在第一時間點(專案還沒開始時,時間=0),不要甚麼都不做就去猜,至少要透過「進一步了解一下」的方式,才給出「預估」的時間。

然後在專案進行到產生「信心點」時,再來給上級「承諾」。此時的承諾可能要比當初的預估時間要準確許多了。這是我經常要求工程師的動作,隨著我們對專案問題的了解越來越深入,自然會越有把握何時會做完(這個時候務必讓主管也知道一下,這一點非常重要,它叫做專案的透明度)。

上面的「信心點」就是我們對自己工作的把握程度。我一般把它訂在專案開始後 1/5 到 1/3的時間範圍內(這裡的比例是根據不確定性錐的曲線所得來的(Cone of Uncertainty),1/5到1/3的時候剛好是不確定椎急速收斂的區間,這個時候是我們對專案的相關智識快速增加的區間,也就是我們開始大量熟悉它的時候,因此我習慣在這個時候要求工程師給予承諾。工程師經常在還不到1/5時就跑過來拍胸脯了。好啊! 有信心是好事!)。通常在時間到了(到達1/3的開發時間)的時候,我會再要求工程師給一次估算,然後慎重其事地說,這一次可是「承諾」了。雖然這個承諾基本上還是猜測,但他至少是一個較值得我們一起去努力達成的,一個比較有意義的奮鬥目標(其實他的意義已經遠勝於承諾的價值了)。

Cone01

不確定性錐Cone of Uncertainty

這樣子的做法是對工程師的一種尊重。但是工程師應該要主動做這件事,不需要主管再來確認。(請參考: Steve McConnell 的不確定性錐)

.

制定簡單的規則

一、當我們被要求要做估算時,不要在第一時間就做出回答。應該要花一點時間,多收集一些資料,運用參考、比較的方式,來做第一次的估算。(請參考2002年諾貝爾獎得主Daniel Kahneman所著的: 快思慢想 ,他說沒有經過較多時間思考就做的回答,往往錯誤率會偏高且容易被問題所誤導)

二、在提出估算之後,要持續去追求對專案問題的瞭解,盡快找到「信心點」,在產生了信心之後,主動向主管做出承諾。承諾是第二次的估算。然後團隊就可以以此為共同的目標,努力的去實踐它了。

.

工程師如何估算工時? 讓他依照團隊所制定的簡單規範來做預估,千萬不要讓工程師各自為政沒有一定的準則在做估算,上面的二個簡單規則,歡迎參考,我稱它為「信心點估算」,信心點越提前,我們就能越快獲得工程師的承諾。而提前的因素很多,多做測試就是一個,請這方面的專家來演講也是一個。

.

為什麼要給工程師二次估算的機會呢?  因為這樣做是值得的。

.

(還記得實施Scrum的時候,會要求團隊自我管理時要制定簡單的規範嗎? 這就是了! 但我還是囉嗦一下,執行簡單規則要成功必須有一個要素,那就是「共識」! 一定要有共識;讓團隊、老闆看一下這篇文章,討論一下,制定你們自己的規則。造成共識是成功的第一步…)

.

※ 至於對團隊的專案預估。如果你還在採用一個人一天工作八小時來作估算! (我的天啊!這個時代還有人這麼做嗎? )請問你上班時不開會或接電話或上網嗎? 這個議題待下回再聊了!

.

值得參考的一本書: [軟件估算:“黑匣子”揭秘], by: Steve McConnell

Written by ruddyllee

2014 年 12 月 03 日 於 13:04:33

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: