软件工程 估计方法
?
上回書說到 -
一個小組的同學 (6-8 人) 決定要徒步遍歷中國陸地邊界, 假設供給裝備齊全, 估計需要多長時間?
用什么樣的辦法能讓同學們方便地交流各自的估計, 最后到達大致理性和統一的共識?
一般這個時候教室里一定非常熱鬧,? 大家各抒己見, 爭執得不亦樂乎。 但是最后往往誰也說服不了誰, 還有一些同學無動于衷, 覺得無從下手， 干脆不參加討論。? 在這種情況下, 可以考慮通過 Wide-band delphi 來達到快速溝通和達到意見的一致。
網上有不少關于這類方法的介紹:
http://www.stellman-greene.com/aspm/content/view/23/38/
http://en.wikipedia.org/wiki/Wide-band_delphi
http://drdobbs.com/article/printableArticle.jhtml?articleId=184414570&dept_url=/? (Dr. Drobb’s)
?
這個方法看起來復雜, 其實挺簡單的:
1) 找到一個主持人 (facilitator/moderator)
2) 主持幾輪討論,? 每一輪統計大家的估計, 并且詢問大家估計值的前提假設是什么, 找到合理的假設, 然后繼續。
例如:? 第一輪, 大家的估計和假設是:
a) 300 年???????????????? 假設: 要按照邊界走, 爬到珠穆朗瑪峰就掛了
b) 2 年;?????????????????? 假設: 兩萬多公里的陸上邊境線。參考紅一方面軍在長征時候的記錄，12個月走1萬兩千公里。所以2年即可。
c) 5 年;?????????????????? 假設: 3 萬公里, 一年工作 300 天, 每天20公里，?
d) 1 年;?????????????????? 假設: 邊界大概有10個省份, 每個省份在當地公安邊防的帶領下, 一個月就搞定了。 有兩個月用于和各地政府取得聯系。
e) 5 個月????????????????? 假設: 南宋后再無中國, 只好沿著南宋的邊界走, 走走玩玩, 很快就走完了。
f) 不可能????????????????? 假設: 被有關部門請去喝茶
?
[我在微博上看到還有人說 50 天的, 不知道他的假設是什么樣子…]
…
?
大家對各自的假設做了分析, 得出了新的共同假設:?
??????? 沿著邊界 = 離邊界最近的公路或小路走, 青藏高原可以繞一下, 不必親自到每一塊界碑跟前拍照留念。 不過還得自己走。?
??????? 陸地邊界 = 中國現在的邊界, 不是南宋的。 約等于2 萬公里
在這樣的前提下, 大家又有新的一輪估計:
??? … …
然后又澄清一些假設,
??? … …
最后大家的估計收斂到一個大家都比較滿意的精度數值。于是估計就結束了. 注意在精度上, 大家不必太拘泥, 根據這個題目的情況, 用月做單位即可。 不必爭論到底會用 1002 天還是1003 天。
主持人要記住在每一輪的估計中, 探詢數值背后的假設, 這是作為項目經理最重要的能力.? 另外, 要推動數值收斂, 這要求大家的假設 (也就是用戶需求分析) 也要收斂, 不要天馬行空。在每一輪的討論中, 估計值的上界和下界要不斷接近。
注意, 最后得到的估計數值, 也許和某人最初提出的數值很接近, 但是這意義并不大, 因為最后達成的假設也許和最初的假設大相徑庭。? Wide-band delphi 的目的不是比誰的第一輪估計猜得準， 而是在較短的時間內讓團隊充分溝通, 交換意見。
?
在這個練習中, 很重要的一點是要估計團隊自身的能力, 你看到別人能每天行軍30公里, 你自己未必能夠。 你聽說編程大牛幾天寫好某模塊, 你自己卻花了幾個星期。? 在上課的時候, 有同學提到團隊要先培訓幾年, 這也是很好的角度, 在開始使用一個全新的技術前, 一段時間的培訓和練習是很有必要的。 你的估計中是否包括這些因素?
?
還有一個高級PM能考慮到的問題, 既然這是一個長期項目, 那不可避免地有人員的投入 (commitment)和變動 (attrition) 問題。 大家走著走著, 有人受傷怎么辦? 有人和當地少數民族少女墜入愛河怎么辦? 有人打退堂鼓怎么辦???????
?
軟件開發的一個特點是, 軟件項目的確有不少東西可以重用別人的結果, 但是項目中最有價值的部分, 別人都還沒做過, 還得自己動手. 這就要求我們去探索, 發現這樣的工作到底需要多長時間。?? 問題是 - 探險者總是高估自己的能力，低估未知的困難 - 不然他們就不會出門探險了！
?
據說, 早期的西班牙探險者到美洲達科羅拉多河大峽谷的時候, 他們站在峽谷南岸俯瞰深谷中蜿蜒的河流, 覺得那不過是一條細細的小溪而已。 隊長估計用不了一天的時間就能跨越, 于是大隊人馬開始出發。? 等他們下到山谷的一半, 才發現河流湍急, 自身的裝備不夠, 人困馬乏, 只好又悻悻返回, 同時已經累得半死。
我們在做項目的時候, 也有很多次發現原來估計很容易的地方原來 “水很深”, 往前走, 也許會被淹死, 往回退, 會耽誤大量的時間。 這時候大家心里都暗想 - 當時要是在項目計劃的時候多做深入分析和估計就好了!? 但是回過頭來, 對于這種情況, 大家如果坐在峽谷邊 wide-band delphi 一整天, 也依然會得出非常樂觀的結論，因為沒有人提出不同的 “假設”。 這時候, 我們可以考慮參考前人的經驗,打聽一下當地人跨越大峽谷要幾天。 有些事情花的時間是客觀規律, 不是由個人能力決定。? 例如生一個小孩大約需要10個月, 這個估計和你的 S 是大號, 中號, 還是小號無關, 和婚禮來賓的數量也無關。 要是還不滿意懷孕時間長, 再加上幾個精壯男子幫忙, 也無濟于事。??世界上很多事情都有人做過了, 即使和你的具體情況有種種區別, 還是可以作為參考, 例如你想徒步走遍全國, 貌似前無古人, 但是不妨看看一個騎自行車走遍全國的例子:
?[鏈接: http://www.lvye.cn/article-26533-1.html]
這些老人騎車用了大約200天,? 小伙子走路能比他們快么??? 另外, 老人們走的是城市間的連接線, 大學生們要走邊境線, 難度比較一下, 原來那些小于300 天的估計都可以推翻了。
另外一個辦法是快速原型法 -? 用一兩個先鋒去探路。 例如一個項目如果能用上 Microsoft Azure 平臺, 那貌似會給我們帶來很多好處.? 如果你光看 Azure 的宣傳資料, 你覺得這簡直太容易了, 咱們趕緊上馬!? 且慢, 這時不妨派一個人寫一個簡單的Azure Hello World 應用, 實際看看開發/調試/部署/支持的情況如何, 這樣才能給項目估計提供更好的數據支持。
?
我自己在長期的革命斗爭中, 摸索出一套經驗公式: 你問一個開發人員兩件事 – 對某件事的估計時間 X, 以及他做過類似開發工作的次數 N.? 那么他最終需要的時間
Y = X +/- X/N???? //注: 中間的 +/- 表明或者加上, 或者減去。
例如果凍估計某個模塊需要 3 天, 但是果凍從來沒有做過, 那么這件事情實際花費的時間有兩種可能 Y = 3 +/- 3/0.??
就是說, 這事情也許是 (3 + 無窮大),? 在項目時間內壓根就做不了。 例如一個學生團隊一度想做 “用玩家的人臉做拳皇游戲”?
或者是 (3 - 無窮大), 不但不用做, 而且這個員工會搞出很多新的bug 來, 讓團隊花更多的時間來處理, 把項目拖垮.?
?
比如果凍說要實現網絡用戶的管理, 結果發現Asp.net 早就實現了. 但是果凍不服,非得要自己寫一個。 結果寫得漏洞百出,? 很多其他員工來幫他擦屁股。 最后把他的代碼扔了, 用標準控件來實現。
?
當 N 等于 1 的時候, 一項工作估計的實際花費范圍是 [0 .. 2X],?? 如果員工一直做類似的項目, 他們的 N 值都在 1 以上, 估計變化的范圍會越來越小, 準確度越來越高。當然, 技術在變, 市場在變, 員工的心態也在變, 員工是不甘于, 也不能一直做雷同的項目的。??
如果把這個公式展開一下, 項目的復雜程度
???? a) 需求的復雜程度 - 程序員是第幾次實現類似的需求???有些外行看起來很復雜的需求 (如銀行業務流程), 如果一個程序員已經做過多次相關的銀行項目, 其實不向外人看的那么難。
???? b) 技術的復雜程度 - 程序員是第幾次用這個技術實現??
??? 一個極端的例子: 幾個程序員用他們從來沒用過的技術 (例如 HTML5) 去實現一個他們以前沒碰到過的需求 (例如銀行業務), 他們的時間估計一定很飄忽...
業界的專家也有類似的分析, 例如這個項目/過程復雜度的二維圖 (圖來自 Danc? “Managing game design risk: Part I”? )
?
一個案例:? 大牛在完成一項任務, 他原計劃 3 天完成, 現在是第三天的下午, 他馬上就可以做完. 但是在實現功能的過程中, 他越來越意識到自己原來的想法不是最好, 他應該采取另一個辦法, 才能避免后面集成階段的額外工作. 但是他如果現在就改弦更張, 那勢必要影響自己原來估計的準確性. 這樣他的老板, 同事會因此看不起他?? 如果他按部就班, 最后整個團隊還要花更多時間在后續集成上， 但是就不是他個人的問題了. 怎么辦？
?
整個軟件項目的時間估計也可以從兩個方面來看 -
a) 自底向上? 團隊成員各自估計底層模塊和單個功能 (和單元測試) 所需的時間, 再加上集成, 及基本測試的時間, 就是大概的開發時間。 這還沒有考慮各個模塊之間的相互依賴性.
b) 回溯?????? 團隊從整個項目最終交付之日往回倒推 -??
如果在十一就要交付整個軟件, 那么九月一號就要完成基本測試
如果九月一號要完成基本測試, 那么八月一號就要代碼完成 (Code Complete)
如果八月一號要代碼完成, 那么我們要有16 周的開發任務, 那意味著我們四月一號就要開始, 而且四月一號要有第一批設計規格說明書 (spec)
我倒！ 今天已經四月七號了! 你還在看博客!
?
在敏捷開發的項目中, 團隊一般不過分強調 “估計”的價值，因為它就是一個“猜”字。 “猜得準”不是團隊的目標。 團隊的目標是把軟件寫出來, 讓用戶滿意。?? 如果猜錯了，沒關系，微調項目進度即可，不要為了“猜得準” 而躊躇不前; 或者為了讓當初的猜測看起來靠譜而不如實報告進度。
?
在敏捷的開發流程中, 還有不少看似山寨的辦法, 我接觸到的有:
估計撲克牌 – 撲克牌上面是1, 2, 3, 5, 8, 13, … 等數字, 大家出牌來估計某功能花費的時間。 這副牌我給了我們項目的PM, 她拿去打拖拉機了。
劃拳估計法 - 幾人一聲吶喊, 同時出拳, 幾個手指代表幾天, 我們項目組還沒有正式演練過.
t-shirt 尺寸法 – 用 S, M, L, XL 代表估計的時間長度, 對于尺寸超大的任務, 要考慮把它們分解為比較細小可掌控的小任務.
這些方法都是強調快速得到粗粒度的估計, 然后進入實現階段. 一個團隊經過一次里程碑之后, 再回過頭看看原來的估計和實際花費時間的差距。? 經過一兩次里程碑, 成員們就可以了解在我們項目中, 一個尺寸為 S 的任務大概要多少天。
?
關于時間估計, 這里有更多相關內容:
http://www.pmhut.com/agile-estimating-%E2%80%93-estimation-approaches
?
回到上一個博客提到的目標, 決心和估計的區別, 當一個程序員果凍聽到大老板說 - 果凍, 這個項目十一要交付使用, 你估計能行么?
果凍首先想到的不是用哪一種時間估計方法, 而應該反問? - 老板, 您已經給了一個商業目標, 現在你是想聽客觀的估計呢?? 還是我主觀的決心?
老板一定會對果凍另眼相看的
?
另一個目標/決心/估計的故事: 某項目本來進行得很順利, 大領導非要全體人員脫產開一天的動員大會,?會議結束時, 領導熱情地問大家: 大家對如期完成項目有信心么??? 這時, 項目經理站起來說: 我們本來是可以按期完成的, 現在開了一天會, 我們已經延期了一天。 對這樣的經理, 我要點【贊】。?
?
Steve McConnel 曾經詳細說明了軟件估計的 10 種罪, 很值得一讀:
??? http://www.ewh.ieee.org/r5/central_texas/austin_cs/presentations/2004.08.26.pdf?
?
既然是一個面試問題, 下面是我的一些打分標準:
6 分及格, 10分優秀。
總結
- 上一篇： 软件使用手册模板_我的印象笔记使用手册（
- 下一篇： php 命名空间通俗易懂_PHP进阶由浅