1       估算的含義

1.1    估算,目標,承諾

估算:是對專案將持續多長時間,花費多少成本的預測;

目標:描述期望達到的業務的目的;

承諾:許諾載特定的日期之前以特定的質量交付規定的功能,可以比估算激進,也可能比估算保守;

1.2    估算,計劃

估算是客觀的分析過程,計劃是主觀的目標求解功能.

當有人要你提供估算值時,要確定他是期望你進行估算還是期望你給出如何達到這個目標的計劃.

看到單點估算結果時,要問清這是個估算值還是一個事實上的目標;看到一個單點估算值時需要問清楚這個估算值的概率,因為任何一個單點估算值都與一個概率關聯.

1.3    良好估算的定義

一個良好的估算方法應該在75%的時間內提供與實際結果相差不超過25%的估算結果.但是僅僅通過估算實踐本身並不能獲得準確的估算結果,還需要通過有效的專案控制.

1.4    估算與專案控制

海森堡不確定性:僅僅對事物的觀察就會改變事物的本身,因此只有看到事物的表現時才會知道它的表現是什麼樣的,而不可預知它的表現;

專案中會受到各種各樣的因素的影響導致對最初進行專案估算時的假設失效,但如果最終提供了與估算一直的結果,那麼就說明這個估算是個良好的估算,所以評價一個良好的估算不能基於它的預測能力,而是要基於估算為專案成功提供支援的能力.

1.5    估算的真正目的

估算的首要目標不是預測專案結果,而是確定專案目標是否能夠足夠的現實.事實證明:如果初始目標與初始估算值的之間的差距不超過20%時,專案經理可能調節專案引數從而達到業務目標.

2       你的估算水平

大部分人的90%的置信度其實只有30%,所以除非有定量的推算方法,否則不要提供百分率的置信度,尤其是90%置信度.

避免使用沒有依據的較窄的範圍,確保估算值中的範圍與你給出的估算值的置信度相匹配.

3       準確估算的價值

3.1    高估好還是低估好

3.1.1   反對高估的觀點

如果專案被高估了,帕金森法則就會起作用:如果給一名開發人員5天的時間完成4天的工作量,他就會在額外的一天找些其他的事情做,另外的顧慮就是學生綜合症:給開發人員太多的時間,他們就會一直拖到專案快結束的時候才匆忙完工,結果反而可能無法按時完成專案.

3.1.2   反對低估的觀點

降低了專案計劃的有效性;

從統計角度降低專案交付的可能性;

未做好基礎工作導致專案的實際結果比名義上可取得的結果更差;

專案後期破壞性的變因導致專案實際結果比名義上可以取得的結果更差;

3.2    權衡各種觀點

採用積極的任務跟蹤和緩衝管理(即專案控制),而不是人為的降低估算值.所以不要低估,低估帶來的損失比高估帶來的損失可能更嚴重,應通過計劃和控制來解決高估的顧慮.

3.3    軟體行業估算的詳細記錄

行業資料顯示:軟體行業普遍存在系統性低估的問題,我們首先要讓估算變大,才能讓估算更準確.

3.4    準確估算帶來的好處

更準確的顯示專案狀態:進度跟蹤的最佳方法是將計劃與實際進度進行比較;

更高的質量:準確的估算有助於避免因進度壓力而導致的質量問題,軟體40%的錯誤是由於進度不合理導致;

更好的於軟體以外的活動進行協調;

更好的編制預算;

提高開發團隊的可信度;

更早的獲得風險資訊:認清專案業務與估算結果存在不一致的含義:這是表明專案無法成功的高價值的風險資訊.

3.5    可預測性與專案其他屬性的價值比較

進度

成本

功能

對於很多業務而言:可預測性比開發所花的成本,時間或者具備的靈活性更有價值.

4       估算誤差的來源

估算值中誤差的來源可能是下面四個方面:

有關被估算專案的不準確資訊

和被實施專案的開發組織能力能力相關的不準確資訊;

專案過於混亂;

估算過程本身帶來的誤差

4.1    估算不準確性的來源

對於給定的特性,在如何說明,設計,和實現單個特性上的潛在的差異可以導致在實現時間上累積產生100倍以上的差異,大型特性集中有成百上千的特性,而每個特性都有這樣的不確定性,其結果就會導致專案本身存在不確定性非常大.

4.2    不確定性錐

專案早期建立的估算值可能存在很高程度的誤差,在初始階段誤差可能達到4倍,

軟體估算的準確度取決與對軟體定義的細化程度,定義的越細化,估算越準確.

減少估算值的可變性的唯一辦法是減少專案的可變性.

通過估算值中使用預先確定的不確定性範圍來考慮不確定性錐的影響.

由一個人估算”有多少”,由另一個人來估算”有多不確定”,從而考慮不確定性的影響.

在專案早期錐面還較寬的時候不可能做出有意義的承諾,高效的開發機構會推遲到完成那些讓錐面縮小的工作後才作出承諾.

4.3    混亂的開發過程

常見的專案混亂:

一開始沒有很好的研究需求;

在需求確認階段沒有與終端使用者溝通;

導致程式碼中尋呼現無數錯誤的不良設計;

引發大量排錯工作的不量程式碼實踐;

缺乏有經驗的人員;

不完整或不熟練的專案計劃活動;

“首席女歌手”成員;

開發人員增加不必要的功能或採取不必要的方法;

缺乏自動化原始碼控制.

Note:不要期望更好的估算實踐能為混亂的專案提供更準確的估算,不可能精確估算一個失控的專案,作為起始步驟,消除混亂比改善估算更重要.

4.4    不穩定的需求

在執行良好的專案上中,會以一組初始需求集作為基線,然後根據該需求集的基線來估算成本和時間進度,在增加新需求或修改舊需求時,就要對成本和進度的估算值進行修正來反映這些變更,但很多專案會在需求變更時忽略了對有關成本和進度的假設進行更新,儘管增加了需求專案上看起來更合理了,但是專案還是被看作延誤了.

如果所處的環境不能讓需求穩定下來,就要考慮使用針對那些高可變性環境的其他方法:短迭代,scrum,極限程式設計,dsdm,時間框開發等等.

4.5    遺漏的活動

被遺漏的工作主要有三類:遺漏的需求,遺漏的軟體開發活動,遺漏的非軟體開發活動,

被遺漏的需求譬如安裝程式,幫助系統,部署方式,外部介面等

被遺漏的軟體開發活動譬如:新成員的準備,指導新成員,交接部署,安裝,定製,參與技術評審,整合工作,維護修訂控制系統,維護每日構建等等;

被遺漏的非軟體開發活動:休假,病假,培訓,週末,假日,所以在持續時間為數週的專案需要為休假,病家,培訓,公司會議等開銷留出空間,

4.6    沒有理由的樂觀主義

開發人員給的估算值一般是過於樂觀,

軟體估算會受到”樂觀主義共謀”現象的破壞,需要看這些估算值是否有可靠的基礎.

4.7    主觀性和偏差

估算方法的控制按鈕越多,受主觀性影響的可能性越大.所以估算模型中控制按鈕越多可能偏差越大.

4.8    即興估算

不要做即興估算,即使經過15分鐘考慮的估算也會更準確.

4.9    無根據的精度

準確度和精度的區別

準確度表明離真實值有多遠

精度表明一個數值有多精確

不要給出毫無根絕的精度來給人帶來估算很準確的錯覺.

5       影響估算的因素

5.1    專案規模

專案規模有很多種表現方式:程式碼行,功能點,需求數目,web頁面等等,但無論什麼方式,變化特性都是一樣的,所以應投入適當的精力來評估待構建的軟體規模,因為軟體規模是影響軟體工作量和進度的最主要因素.

5.1.1   規模不經濟

不要以為工作量是隨著專案規模的擴大呈線性增長,實際上是呈指數增長;

5.1.2   何時可以安全的忽略規模不經濟

在一定的範圍內,軟體規模估算值的線性估算值與指數估算值相差不大,(最大規模和最小規模相差3倍)就可以安全的使用基於產能(如每月完成程式碼行數的估算方法)來估算新專案.

5.2    待開發軟體的型別

電信軟體:一萬行程式碼:200-3000人月;十萬行程式碼:50-600人月,二十五萬行程式碼:40-500人月.

5.3    人員因素

不需要考慮太大的差異:因為最好的開發人員和最差的開發人員都喜歡跳到那些僱員水平和他們相當的組織中.

5.4    程式語言

變成語言不會影響估算的結果,但會影響估算本身,

5.5    影響專案的其它因素

譬如使用者重用,平臺經驗,提供文件的程度,產品複雜度,軟體工具的使用等等,其中影響比較大的有產品複雜度,需求分析師的能力,程式設計師的總體能力,時間限制,人員持續性,多場所開發,要求的軟體可靠性等等,來源於cocomo2調整因子.

5.6    再論規模不經濟

五個規模因子:開發過程的成熟度,架構和風險的化解,有先例可循度的程度,團隊凝聚力和開發靈活性.這些因子在cocomo2中是影響最小的因子,但是這些會在不同的規模產生不同的影響.隨著規模的變大,這些因子的影響變的很顯著.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/22878014/viewspace-619655/，如需轉載，請註明出處，否則將追究法律責任。