0 引言
 不知道您是否聽說過關(guān)于軟件項(xiàng)目管理的一個(gè)經(jīng)典“六拍”笑話。那是這樣說的:在項(xiàng)目開始之前,大家先“拍腦袋”承諾項(xiàng)目進(jìn)度安排;在開工大會(huì)上領(lǐng)導(dǎo)“拍拍大家的肩膀”,語重心長,充滿期待;而兩杯小酒下肚,春風(fēng)得意的時(shí)候,不由得“拍胸脯”向領(lǐng)導(dǎo)表決心,領(lǐng)任務(wù);
而當(dāng)項(xiàng)目執(zhí)行中遇到困難時(shí),客戶和業(yè)主已經(jīng)在“拍桌子”時(shí),研發(fā)團(tuán)隊(duì)卻不得不“一拍大腿”,恍然大悟,事情怎么就這樣了呢?!直到一切覆水難收,項(xiàng)目失敗的時(shí)候,也只能“拍拍屁股”另謀高就去了。雖說這只是個(gè)笑話,但是也確實(shí)反映了軟件項(xiàng)目中面臨的一些問題。從“拍腦袋”到“拍屁股”走人,每個(gè)環(huán)節(jié)都可能存在著各式各樣的問題。
但是追根溯源,要不是當(dāng)初“拍腦袋”的時(shí)候沒有考慮清楚、輕易地承諾,那么后面的一系列問題也就不會(huì)發(fā)生了。“拍腦袋”也需要好的方法,并不能輕而易舉地一“拍”而就。就像帶兵打仗,先要仔細(xì)謀劃,知己知彼,才能百戰(zhàn)不殆。本文正是試圖從軟件項(xiàng)目的現(xiàn)實(shí)角度,通過敏捷開發(fā)中常用估算方法在項(xiàng)目中的實(shí)踐,以及與其他估算方法的比較,從而希望能得到些有價(jià)值的參考意見。
這也是為了提高項(xiàng)目的計(jì)劃質(zhì)量而未雨綢繆,也希望下一次“拍腦袋”能拍得有理有據(jù)。
1 什么是估算
 在軟件項(xiàng)目管理中,估算就是對(duì)項(xiàng)目將持續(xù)多長時(shí)間或花費(fèi)多少成本的預(yù)測(cè)。所以說,估算正是一種對(duì)未來的預(yù)測(cè)。本文將僅就項(xiàng)目時(shí)間估算這一方面展開討論,而不涉及項(xiàng)目的費(fèi)用和成本估算。
估算往往是與項(xiàng)目目標(biāo)、項(xiàng)目承諾、執(zhí)行計(jì)劃等諸如此類的項(xiàng)目管理詞匯聯(lián)系在一起。業(yè)務(wù)目標(biāo)描述的是項(xiàng)目期望達(dá)到的成果,是進(jìn)行估算的基本輸入。而項(xiàng)目承諾則是項(xiàng)目組許諾在特定的日期之前以特定的質(zhì)量交付規(guī)定的功能。承諾可以與估算相同,也可能比估算更激進(jìn)或保守。
承諾是主觀的對(duì)項(xiàng)目交付的時(shí)間和質(zhì)量的預(yù)計(jì),而估算只是基于客觀事實(shí)的預(yù)測(cè)結(jié)果。此外,執(zhí)行計(jì)劃通常是羅列出各個(gè)工作項(xiàng)和其相聯(lián)的關(guān)系,從而將承諾具體化。計(jì)劃與估算并不相同。
前者是尋求如何實(shí)現(xiàn)特定的結(jié)果,而后者的目的是為了得到準(zhǔn)確的預(yù)測(cè)。計(jì)劃可以通過主觀的方法進(jìn)行調(diào)整,以實(shí)現(xiàn)特殊的要求,比如為了應(yīng)付突發(fā)情況而進(jìn)行趕工、增加資源等。計(jì)劃的基礎(chǔ)正是估算,但計(jì)劃不一定要與估算結(jié)果相同。如果估算與計(jì)劃存在顯著的差別,那么項(xiàng)目可能有較高的風(fēng)險(xiǎn);反之則計(jì)劃可能具有較低的風(fēng)險(xiǎn)?！?br /> 2 估算在項(xiàng)目管理中的位置
 在項(xiàng)目管理的九大知識(shí)領(lǐng)域中,項(xiàng)目時(shí)間管理中包含了與估算相對(duì)應(yīng)的管理過程:活動(dòng)資源估算和活動(dòng)持續(xù)時(shí)間估算。這些過程是在項(xiàng)目組已經(jīng)建立,范圍確定后進(jìn)行的。其輸入內(nèi)容除上述前導(dǎo)過程的輸出結(jié)果外,還建立在事業(yè)環(huán)境因素和組織過程資產(chǎn)之上。
而且活動(dòng)持續(xù)時(shí)間估算的輸出是后續(xù)制定進(jìn)度表和進(jìn)度控制的依據(jù)。由此可見,估算在項(xiàng)目管理中處于承前啟后的位置,是項(xiàng)目計(jì)劃制訂的必須條件之一,也是項(xiàng)目最終順利交付的關(guān)鍵因素之一。
項(xiàng)目管理是一門偏向于實(shí)踐的科學(xué),其理論和方法都需要在實(shí)踐中檢驗(yàn),也需要根據(jù)實(shí)踐經(jīng)驗(yàn)做出適當(dāng)?shù)恼{(diào)整。這也是各種估算方法在項(xiàng)目管理中運(yùn)用的關(guān)鍵:必須根據(jù)實(shí)際的情況做出合適的變化,才能達(dá)到最好的結(jié)果。
3 估算的目的
 軟件項(xiàng)目的估算并不完全是純粹的預(yù)測(cè)活動(dòng),而是與項(xiàng)目計(jì)劃及確定優(yōu)先級(jí)的活動(dòng)有密切的聯(lián)系。實(shí)際上,軟件估算很容易受到其他事情的影響。但一旦做出了估算,并且在此估算的基礎(chǔ)上承諾在某日期前交付具有一定質(zhì)量的功能,那么項(xiàng)目經(jīng)理就不得不通過管理控制使項(xiàng)目達(dá)到目標(biāo)。
通常來說,只要交付的項(xiàng)目與最初想要的功能水平大致相當(dāng),花費(fèi)的資源與計(jì)劃基本相同,而且大致上是在設(shè)定的時(shí)間框架內(nèi)完成的,那么就可以認(rèn)為項(xiàng)目“與估算一致”,而不管這種說法在推理上隱含著怎樣的瑕疵。
因此,評(píng)估估算的預(yù)測(cè)能力(與最終結(jié)果進(jìn)行比較)并不能說明估算的實(shí)際價(jià)值,因?yàn)檐浖?xiàng)目的外圍環(huán)境總是不斷地在變化。評(píng)價(jià)“良好”估算的標(biāo)準(zhǔn)應(yīng)該是基于估算為項(xiàng)目成功提供支持的能力。所以說,估算的首要目標(biāo)不是預(yù)測(cè)項(xiàng)目的結(jié)果,而是確定項(xiàng)目目標(biāo)是否足夠現(xiàn)實(shí),從而讓項(xiàng)目在可控的狀態(tài)下達(dá)成這些目標(biāo)。
4 敏捷開發(fā)的特點(diǎn)
 敏捷開發(fā)是在2001年前后,一些軟件業(yè)專家為了解決許多公司的研發(fā)團(tuán)隊(duì)所面臨的不斷增長的項(xiàng)目問題和“過程”泥潭,所概括出的一些可以讓開發(fā)團(tuán)隊(duì)具有快速工作、響應(yīng)變化能力的價(jià)值觀和原則。他們自稱為敏捷聯(lián)盟。
而其所倡導(dǎo)的開發(fā)方法就稱之為敏捷方法。敏捷方法集成了許多新型開發(fā)模式的共同特點(diǎn),它重點(diǎn)強(qiáng)調(diào):
①以人為本,注重編程中人的自我特長發(fā)揮;
②強(qiáng)調(diào)軟件開發(fā)的產(chǎn)品是軟件,而不是文檔。文檔是為開發(fā)服務(wù),而不是開發(fā)的目的;
③客戶與開發(fā)者的關(guān)系是協(xié)作,不是合約細(xì)則。開發(fā)者應(yīng)與客戶合作來澄清需求細(xì)節(jié),而不是將自己變成客戶業(yè)務(wù)的“專家”;
④設(shè)計(jì)周密是為了最終軟件的質(zhì)量,但不表明設(shè)計(jì)比實(shí)現(xiàn)更重要。為了適應(yīng)客戶需求的變化,設(shè)計(jì)要能根據(jù)環(huán)境的變化而不斷更新。
敏捷開發(fā)通常用于復(fù)雜或非常不確定需求的軟件項(xiàng)目。它不同于傳統(tǒng)開發(fā)方法,如瀑布模型,原型法等。主要區(qū)別在于敏捷方法是開放的、具有彈性的方法。敏捷方法在項(xiàng)目管理中更加關(guān)注于人在項(xiàng)目中的作用,而不是繁復(fù)的計(jì)劃和沉重的過程方法。
人是項(xiàng)目成功的最重要因素之一。但是敏捷開發(fā)團(tuán)隊(duì)并不一定非要由頂尖的開發(fā)人員組成。頂尖的、但不能很好與別人合作的成員并不比普通的、但與其他人溝通良好的成員更加適應(yīng)敏捷開發(fā)的特點(diǎn)。因此,敏捷開發(fā)特別強(qiáng)調(diào)與人合作、溝通和交流的能力,
這比單純的軟件開發(fā)能力更為重要。而且敏捷開發(fā)團(tuán)隊(duì)一般都會(huì)較小,這也是為了能達(dá)到最高的溝通效率。典型的敏捷開發(fā)方法有:SCRUM、Crystal、特征驅(qū)動(dòng)軟件開發(fā)(Feature Driven Development,FDD)、以極限編程(eXtreme Programming,XP)等。
本文會(huì)根據(jù)在軟件項(xiàng)目中實(shí)施極限編程的實(shí)踐,對(duì)敏捷方法的估算技術(shù)做進(jìn)一步的討論。但所討論的方法不僅能用于極限編程,也適用于其他敏捷方法。
5 敏捷開發(fā)中的估算方法
 敏捷開發(fā)的團(tuán)隊(duì)通常是由較有經(jīng)驗(yàn)的、善于溝通的人員構(gòu)成。所以在敏捷開發(fā)中采用的估算方法往往需要便于理解、能發(fā)揮團(tuán)隊(duì)成員的集體智慧、并有利于項(xiàng)目的順利交付。在筆者的團(tuán)隊(duì)中,采用了一種
叫做“撲克估算”(Planning Poker)的方法進(jìn)行項(xiàng)目初　　期的估算。正像許多其他敏捷開發(fā)中所采用的技術(shù),“撲克估算”也非常簡(jiǎn)單,但卻有效率。
首先,敏捷方法中的估算應(yīng)該是由團(tuán)隊(duì)成員共同進(jìn)行,而不是由項(xiàng)目經(jīng)理“閉門造車”式地得出。這樣做的原因之一是因?yàn)殚_發(fā)團(tuán)隊(duì)是由不同經(jīng)驗(yàn)的同事組成,對(duì)于同一個(gè)問題,經(jīng)驗(yàn)不同的人往往會(huì)給出不一樣的解決方案。如果可以將所有人的能力集中到一起,那么最后對(duì)問題的求解也就八九不離十了。
同樣的道理也能用在估算上。“撲克估算”大致過程是這樣的:開始之前首先要決定采用的估算度量。一般來說“估算點(diǎn)”比較常用,但有時(shí)也會(huì)采用費(fèi)伯那其數(shù)字(Fibonacci Number,0,1,1,2,3,5,8,13…)作為估算點(diǎn)
的值,或者采用衣服的尺碼(XS,S,M,L,XL,XXL…)或其他抽象的數(shù)字或符號(hào)。例如,用戶故事一比較簡(jiǎn)單,那么可以標(biāo)記1為它的估算點(diǎn);用戶故事二是一個(gè)系統(tǒng)登錄過程,需要考慮的方面較多,那么就可以標(biāo)記13為它的估算點(diǎn)等。
這樣做的最大好處是可以估算出每一個(gè)“塊”相對(duì)于其他“塊”的大小,而不是實(shí)現(xiàn)它需要的時(shí)間長短。因?yàn)槊艚蓍_發(fā)具有短交付周期的特點(diǎn),一般經(jīng)過幾個(gè)周期的適應(yīng),團(tuán)隊(duì)就能逐漸得出每個(gè)“點(diǎn)”該花費(fèi)多少時(shí)間的認(rèn)識(shí),那么下次估計(jì)就會(huì)更加準(zhǔn)確。
這也正是敏捷開發(fā)的另一個(gè)“自我糾正”的特點(diǎn)。接下來就是準(zhǔn)備這樣一套卡片或使用即時(shí)貼代替。團(tuán)隊(duì)成員對(duì)于每一個(gè)用戶故事進(jìn)行討論,澄清關(guān)于該點(diǎn)的需求,盡量使所有成員都理解這個(gè)功能該如何設(shè)計(jì)等。
如果大家對(duì)于某一點(diǎn)再也提不出問題,那么就一起亮出自己的“估算點(diǎn)”卡片。正如前面所說的,每個(gè)成員都有不同經(jīng)驗(yàn)背景,所以很難一次都給出同樣的估算。這是因?yàn)榭赡苣硞€(gè)人看到了潛在的問題和風(fēng)險(xiǎn)而其他人卻沒有發(fā)現(xiàn),又或者有人想到了一個(gè)更加簡(jiǎn)便的辦法等。得到不同意見后,將其作為下一步討論的基礎(chǔ)。
大家相互交換對(duì)問題風(fēng)險(xiǎn)的看法,討論新的點(diǎn)子等。最后,小組重新投票得出一個(gè)比較一致的估算。一個(gè)接著一個(gè),按照同樣的流程對(duì)所有的用戶故事進(jìn)行估算,得出一串不同的“估算點(diǎn)”。這就是“撲克估算”的大致思路。
6 常用的估算方法
 能夠應(yīng)用在軟件項(xiàng)目中估算方法還有很多種,其中功能點(diǎn)分析是一種常用方法。它是將系統(tǒng)分解為較小組件,以便能夠快速理解和分析。同“估算撲克”法類似,功能點(diǎn)是功能點(diǎn)分析的測(cè)量單位在功能點(diǎn)分析中,系統(tǒng)被分為五個(gè)大類組成部分(組件)和一些常規(guī)系統(tǒng)特性。
前三類件是:外部輸入(External Inputs EI)、外部輸出(External Outputs EO)和外部查詢(External Inquiry EQ)。這些組件中的每一個(gè)組件都處理檔案,因此他們被稱為“事務(wù)”(Transac-tion)。另外兩類或組件是:內(nèi)部邏輯文件(InternalLogical Files ILF)和外部界面文件(External InterfaceFiles EIF),它們是構(gòu)成邏輯信息數(shù)據(jù)的存儲(chǔ)之地。
外部輸入:是指用戶可以根據(jù)需要通過增、刪、改來維護(hù)內(nèi)部邏輯文件。外部輸入使用戶可以維護(hù)ILF。外部輸出:是指用戶的輸出結(jié)果。顯示結(jié)果就是經(jīng)過調(diào)用維護(hù)數(shù)據(jù)和參考數(shù)據(jù)獲得的。在功能點(diǎn)術(shù)語中,顯示的結(jié)果就稱為“外部輸出”。外部查詢:是指用戶可以通過計(jì)算機(jī)系統(tǒng)選擇特定的數(shù)據(jù)并顯示結(jié)果。
為了獲得這項(xiàng)結(jié)果,用戶要輸入選擇信息抓取符合條件的數(shù)據(jù)。此時(shí)沒有對(duì)數(shù)據(jù)的處理,是直接從所在的文件抓取信息。例如:駕駛員要顯示預(yù)先設(shè)置的地形圖,輸出的結(jié)果就是直接從信息存貯位置提取的信息;這里稱作“外部查詢”。
內(nèi)部邏輯文件:這是第一項(xiàng)數(shù)據(jù)功能,使客戶可以使用他們負(fù)責(zé)維護(hù)的數(shù)據(jù)。數(shù)據(jù)在系統(tǒng)中的邏輯分組是由最終用戶維護(hù)的,所以把它們叫做“內(nèi)部邏輯文件”(ILF)。
外部界面文件:這是第二項(xiàng)數(shù)據(jù)功能,也和數(shù)據(jù)的邏輯分組有關(guān)。在這種情況下,用戶不負(fù)責(zé)維護(hù)數(shù)據(jù),數(shù)據(jù)在另一系統(tǒng)中駐留由其他用戶進(jìn)行維護(hù)。該數(shù)據(jù)只供系統(tǒng)用戶參考使用。例如:飛行中,駕駛員可能需要參考某衛(wèi)星或地面定位系統(tǒng)的定位數(shù)據(jù)。駕駛員不負(fù)責(zé)更新這些數(shù)據(jù)但要參考使用。
這樣,這些只供參考使用的其他系統(tǒng)的數(shù)據(jù)分組就稱為外部界面文件。功能點(diǎn)估算通過對(duì)于系統(tǒng)的分析,根據(jù)以上五種組件的多少,按照高、中、低三個(gè)類別對(duì)每項(xiàng)的復(fù)雜度進(jìn)行打分,最后加上影響估算的調(diào)整因子而得出估算結(jié)果,如下面的公式
AFP(調(diào)整后功能點(diǎn))=UFP(未調(diào)整功能點(diǎn)數(shù)目)×AF(影響因子)
7 實(shí)際的例子
 筆者在實(shí)際采用敏捷方法的項(xiàng)目中進(jìn)行了一些實(shí)驗(yàn)。分別采用不同的方法對(duì)于同樣一個(gè)短開發(fā)周期的工作進(jìn)行了估算,結(jié)果如下表1所示。表1不同估算方法不同估算結(jié)果方法估算值單位工作量(人/天)預(yù)計(jì)工作量撲克估算33 1·6 52·8人/天功能點(diǎn)估算69 0·8 55·2人/天
其中撲克估算的單位工作量是按照前幾次團(tuán)隊(duì)估算的結(jié)果調(diào)整得出的,大約要花費(fèi)1·6個(gè)人天才能完成一個(gè)估算點(diǎn)的工作量;功能點(diǎn)估算的單位工作量是從公司已有的統(tǒng)計(jì)表格上摘錄,反映了在公司中采用類似技術(shù)團(tuán)隊(duì)的平均工作效率。
整個(gè)周期大約花費(fèi)了兩個(gè)禮拜的時(shí)間,共有六個(gè)團(tuán)隊(duì)成員參與開發(fā)。實(shí)際工作量可以認(rèn)為是60人/天。
8 結(jié)果的分析
 綜上所述,在采用比較簡(jiǎn)單的、基于團(tuán)隊(duì)經(jīng)驗(yàn)的估算方法比起精確的、有著復(fù)雜數(shù)學(xué)模型的估算方法并沒有明顯精確度的差異。但是相對(duì)于復(fù)雜的方法來說,簡(jiǎn)單的、易于團(tuán)隊(duì)達(dá)成共識(shí)的方法能節(jié)約得出結(jié)論所需要的時(shí)間,也能增強(qiáng)團(tuán)隊(duì)對(duì)于任務(wù)的認(rèn)識(shí)。
從另一個(gè)側(cè)面來看,也能提高團(tuán)隊(duì)的士氣和效率。正如某些研究預(yù)測(cè)學(xué)的專家所說,“研究預(yù)測(cè)學(xué)得到的最牢靠也最有用的結(jié)論之一就是,簡(jiǎn)單方法總體上和復(fù)雜方法一樣準(zhǔn)確。”
比較敏捷估算和功能點(diǎn)估算,二者都是將項(xiàng)目量化成一個(gè)抽象的值,但如何求出項(xiàng)目完成所需要花費(fèi)的時(shí)間卻又各不相同。前者通過項(xiàng)目團(tuán)隊(duì)自適應(yīng)的開發(fā)模式,通過一段時(shí)間的實(shí)踐,得出一個(gè)單位工作量,從而得出項(xiàng)目的全部工作量。后者通過更大范圍的歷史數(shù)據(jù),
比較相類似的項(xiàng)目,得出一個(gè)單位工作量,然后估算項(xiàng)目的預(yù)計(jì)時(shí)間。無法說哪種方式更加優(yōu)越,但顯而易見第一種更容易實(shí)現(xiàn),而第二種需要大量的項(xiàng)目積累。而且項(xiàng)目團(tuán)隊(duì)并不完全一樣,人也并不是純粹的資源,所以后者的平均工作量對(duì)于不同團(tuán)隊(duì)可能是不一樣的。
比較而言,第一種方法可能會(huì)更貼近于實(shí)際。此外,估算方法畢竟只是某種估計(jì),并不能期望采用一些更好的方法就能做出完美的項(xiàng)目計(jì)劃。在項(xiàng)目控制上多下力氣才是最終的王道。由于需求變更是估算產(chǎn)生問題的最大來源。
如果需求確定不下來,估算的可變性就會(huì)保持在一個(gè)高的水平直到項(xiàng)目結(jié)束。而且因?yàn)橛行枨笞兏?項(xiàng)目經(jīng)理往往會(huì)更加關(guān)注于變更本身以及其對(duì)于進(jìn)度控制等方面的影響,從而忽視了對(duì)原始估算進(jìn)行調(diào)整的需要。
不幸的是,也許原始的估算在當(dāng)初的功能范圍內(nèi)還算準(zhǔn)確,但在增加了十幾個(gè)功能以后,由于沒有適當(dāng)?shù)母?所以項(xiàng)目將根本達(dá)不到它最初所承諾的估算結(jié)果。諷刺的是,雖然所有人都承認(rèn)增加的那些特性是不錯(cuò)的改動(dòng),但項(xiàng)目最終還是會(huì)被看做延誤了。所以,再好的估算方法并不能解決由于需求不穩(wěn)定所造成的問題。
在項(xiàng)目控制上做出相應(yīng)的調(diào)整才能更好地解決這個(gè)矛盾。對(duì)于敏捷開發(fā)來說,其本身就是為了適應(yīng)高可變性的環(huán)境而誕生的,所以將合理的估算和敏捷開發(fā)的項(xiàng)目控制結(jié)合起來,才能最好地保證項(xiàng)目按照可控的時(shí)間、預(yù)計(jì)質(zhì)量進(jìn)行交付,也能使得所有的利益相關(guān)方最終收獲滿意的結(jié)果。