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