如何做effort的estimate?本文給出了敏捷開發(fā)模式中的一個(gè)方法。
　　---

　　項(xiàng)目經(jīng)理被問到最多的問題就是，“這個(gè)項(xiàng)目什么時(shí)候才能完成？”

　　被問的時(shí)候，可能項(xiàng)目才定下來(lái)，僅僅知道大概的功能模塊，非功能性需求還模糊不清，甚至團(tuán)隊(duì)成員都沒到位。但是上級(jí)、銷售、客戶急切地要知道，這個(gè)項(xiàng)目什么時(shí)候才能完成？

　　被問的時(shí)候，也可能項(xiàng)目已臨近結(jié)束，或者說(shuō)臨近當(dāng)初計(jì)劃的交付日期。然而待完成的功能還有一堆，測(cè)試出來(lái)的bug有一大堆，客戶又提出了新的需求，團(tuán)隊(duì)正有人要離職 …。但是上級(jí)、銷售、客戶非常急切地要知道，這個(gè)項(xiàng)目到底什么時(shí)候才能完成？

　　這還不算糟糕。更頭疼的問題是：“再有三周，項(xiàng)目應(yīng)該完成了吧？”

　　因?yàn)楹笳吒静皇菃栴}，而是命令。項(xiàng)目經(jīng)理必須要能夠合理解釋為什么三周不能夠完成項(xiàng)目；或者說(shuō)明在三周內(nèi)，能夠完成什么。

　　我們都用過(guò)MSProject， 但是那上面的漂亮表格對(duì)這樣的困境毫無(wú)幫助。相反，正是Project 中的甘特圖和日程表，埋下了陷阱。因?yàn)椋赑roject中無(wú)法預(yù)估需要多少工作日才能完成模糊不清的需求，也無(wú)法體現(xiàn)實(shí)際情況發(fā)生變化后對(duì)進(jìn)度的影響。

　　當(dāng)我們討論進(jìn)度的時(shí)候，其實(shí)包含了兩個(gè)未知的變量。第一是完成需求所要的工作量，包括需求定義、開發(fā)內(nèi)容邊界；第二是團(tuán)隊(duì)的工作能力，包括成員的行業(yè)知識(shí)專業(yè)技能，成員之間、成員和外部的溝通能力，等等。

　　關(guān)鍵就在于，這兩項(xiàng)都是變量。如果任務(wù)是搬一千塊磚頭，每分鐘每人能搬10塊，那么結(jié)果是顯而易見的。

　　在敏捷開發(fā)中，采用相對(duì)估算和迭代求精的方法來(lái)處理項(xiàng)目進(jìn)度的問題。

　　首先是工作量。用估算代碼行數(shù)或者界面元素的方式，就像論斤賣書一樣，只適用于粗制濫造的軟件生產(chǎn)過(guò)程。用戶需要的并不是代碼或者按鈕，而是可靠易用的功能。

　　在敏捷方式中，先由用戶和設(shè)計(jì)人員粗略估計(jì)各個(gè)功能模塊的相對(duì)規(guī)模和難度，給出一定的分值。分值不代表具體人月，起相對(duì)比較的作用。例如有查詢、顯示、修改三個(gè)模塊，如果實(shí)現(xiàn)顯示模塊的工作量是10分，那么查詢模塊可能是15分，而修改為20分。

　　下一步，選擇一個(gè)工作量估分最低的模塊，例如這里是顯示模塊，然后進(jìn)一步考量其工作量。例如要準(zhǔn)備數(shù)據(jù)庫(kù)、設(shè)計(jì)界面、執(zhí)行查詢，顯示內(nèi)容等等。假設(shè)這輪估算得出此模塊需要10人天，從而得出單位分值對(duì)應(yīng)的人天為1；那么，整個(gè)項(xiàng)目就需要45人天。

　　這個(gè)估算建立在對(duì)項(xiàng)目的初步了解上，主要依賴項(xiàng)目經(jīng)理的經(jīng)驗(yàn)。有偏差？沒關(guān)系。接下來(lái)通過(guò)迭代來(lái)求精。先來(lái)實(shí)現(xiàn)顯示模塊，如果事實(shí)上花費(fèi)了12人天，那么根據(jù)比例關(guān)系，剩余內(nèi)容的估算大約就是42人天。

　　當(dāng)然，比例關(guān)系也不是一成不變的。隨著模塊的逐個(gè)完成，項(xiàng)目經(jīng)理對(duì)項(xiàng)目的認(rèn)識(shí)也在加深，他可以再調(diào)整剩余模塊的相對(duì)分值。

　　在實(shí)際操作中，項(xiàng)目經(jīng)理首先按照優(yōu)先級(jí)排列功能模塊。然后把高優(yōu)先級(jí)的模塊盡可能地細(xì)分，再選擇分值最小的模塊開始開發(fā)。統(tǒng)計(jì)總工作量時(shí)，按比例累加其他模塊的工作量，并加一定的調(diào)整系數(shù)，因?yàn)槟K的復(fù)雜度不是線性增長(zhǎng)的。每次迭代開發(fā)完成后，逐步降低調(diào)整系數(shù)。通常4~5次迭代后，可以將調(diào)整系數(shù)歸零。

　　在上面的例子中，第一次估算的初步結(jié)果是45人天，因?yàn)橥耆菓{經(jīng)驗(yàn)，因此要給較大的調(diào)整系數(shù)，比如說(shuō)0.4，因此給出的估算工作量區(qū)間為[45*0.6,45*1.4],即27到63人天之間。為保險(xiǎn)起見，項(xiàng)目經(jīng)理上報(bào)的工作量為70人天。

　　第二次估算，剩余內(nèi)容的初步估算為42，調(diào)整系數(shù)下降為0.3，因此給出估算區(qū)間為30到50人天之間。依此類推，通過(guò)不斷迭代，對(duì)剩余工作量的估算將越來(lái)越精確。

　　這樣估算的好處在哪里？

　　首先，工作量變量的很大一部分因素，存在于非功能需求，例如界面的美觀程度。而同一項(xiàng)目的不同模塊之間，非功能需求往往是一致的，相對(duì)估算法過(guò)濾了這一層復(fù)雜度。團(tuán)隊(duì)能力這一變量因素也是如此。當(dāng)然，隨著項(xiàng)目的進(jìn)展，成員的開發(fā)能力應(yīng)該有一定的上升，但隨著加班出差等因素，投入程度也可能下降，因而會(huì)相互抵消。總之在周期6個(gè)月以內(nèi)的項(xiàng)目中，很少出現(xiàn)團(tuán)隊(duì)工作能力戲劇性變化的情形。因此相對(duì)估算也過(guò)濾了這個(gè)復(fù)雜度。

　　其次，迭代求精的方式讓項(xiàng)目經(jīng)理對(duì)估算時(shí)間更有把握。最初出現(xiàn)偏差是必然的，但只要團(tuán)隊(duì)穩(wěn)定，沒有大的需求變動(dòng)，估算范圍將迅速收縮。這比一次性報(bào)數(shù)更準(zhǔn)確。

　　它的額外好處是，敏捷開發(fā)是遵循優(yōu)先級(jí)的，即使對(duì)剩余時(shí)間（即低優(yōu)先級(jí)模塊的開發(fā)時(shí)間）的估算不十分準(zhǔn)確，影響也不是非常大。

　　對(duì)比一下甘特圖方式，在開發(fā)初期就要把各個(gè)模塊的開發(fā)時(shí)間估算出來(lái)以統(tǒng)計(jì)總量，這就是瀑布開發(fā)的模式。

　　進(jìn)度問題的另一方面，是項(xiàng)目經(jīng)理如何了解團(tuán)隊(duì)以及每個(gè)開發(fā)人員的開發(fā)速度。當(dāng)任務(wù)分配之后，項(xiàng)目經(jīng)理如何做到心中有數(shù)，估算任務(wù)實(shí)際完成時(shí)間。

　　敏捷開發(fā)過(guò)程中，由開發(fā)人員自己來(lái)估算完成該任務(wù)所需要的時(shí)間。當(dāng)然，每個(gè)人的能力不同；每個(gè)人的心態(tài)也不同，有的人保守，有的人樂觀。沒關(guān)系，還是靠迭代來(lái)逐步求精。

　　在每天的例會(huì)上，開發(fā)人員被要求對(duì)當(dāng)前任務(wù)的剩余開發(fā)時(shí)間做重估。不同于Project統(tǒng)計(jì)每人每天在任務(wù)中花費(fèi)了多少時(shí)間，敏捷方式只關(guān)心這項(xiàng)任務(wù)還需要多少時(shí)間去完成，直到歸零，然后再來(lái)統(tǒng)計(jì)實(shí)際的工作時(shí)間。

　　為什么？因?yàn)榻y(tǒng)計(jì)開發(fā)過(guò)程中的花費(fèi)時(shí)間是毫無(wú)意義的。這和搬磚頭不同，也許昨天用了8個(gè)小時(shí)沒有一點(diǎn)進(jìn)展，今天一旦想通了就事半功倍。我們真正關(guān)心的，就是到底還需要多少時(shí)間來(lái)完成任務(wù)，而不是已經(jīng)花費(fèi)掉不可恢復(fù)的時(shí)間成本。

　　在每天例會(huì)中，項(xiàng)目經(jīng)理需要注意時(shí)間曲線保持水平的成員，他是不是遇到瓶頸了，是否需求幫助？也要留意時(shí)間曲線下降幅度過(guò)大的成員，他發(fā)現(xiàn)了什么好的辦法，有沒有低估需求？這樣，項(xiàng)目經(jīng)理會(huì)更面向結(jié)果，只要按計(jì)劃保證質(zhì)量完成任務(wù)就行，成員到底花了多少時(shí)間是個(gè)人的事。傳統(tǒng)做法記錄每個(gè)人每天的工作內(nèi)容，第一是因繁瑣而失真。其次，一旦上級(jí)發(fā)現(xiàn)某人工作時(shí)間不夠（即便他完成了任務(wù)），忍不住會(huì)派新任務(wù)，從而造成越干活越多，反過(guò)來(lái)打擊程序員的積極性。

　　敏捷估算的關(guān)鍵之處，是把成員能力這個(gè)變量的估算，交給最合適的人去做，即程序員本人。然后通過(guò)比較歷次迭代時(shí)的預(yù)估和實(shí)際時(shí)間，給出校正系數(shù)，以避免程序員過(guò)于保守或過(guò)于樂觀。這肯定不是絕對(duì)準(zhǔn)確的，但效果往往比項(xiàng)目經(jīng)理自己拍腦袋估算，然后強(qiáng)行指定deadline 要好得多。

　　在敏捷開發(fā)中，做計(jì)劃比計(jì)劃本身更重要。項(xiàng)目經(jīng)理需要時(shí)刻向前考慮，考慮各種動(dòng)態(tài)因素，而不是死報(bào)著計(jì)劃本身。在進(jìn)度估算的時(shí)候，項(xiàng)目經(jīng)理應(yīng)該在不同階段，根據(jù)實(shí)際情況，給出合乎情理的回答。

it知識(shí)庫(kù)：敏捷開發(fā)中對(duì)進(jìn)度的把握，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。