在軟件開(kāi)發(fā)過(guò)程中，估算始終是一項(xiàng)具有挑戰(zhàn)性的任務(wù)，因?yàn)檐浖_(kāi)發(fā)包含很多不確定因素，而且任何項(xiàng)目都不盡相同。雖然很難（或幾乎不可能）做到完美估算，但還是有必要努力提高估算的準(zhǔn)確性。本文將根據(jù)自己的經(jīng)驗(yàn)和深入研究來(lái)解釋軟件估算的原則。我保證，有了這些可操作的原則，你可以顯著改善項(xiàng)目估算的結(jié)果。

為什么估算很重要？

為什么估算很重要？為什么客戶、高管、銷售人員或其他利益相關(guān)者總是問(wèn)："需要多長(zhǎng)時(shí)間？""你們什么時(shí)候能完成？"他們會(huì)根據(jù)估算采取什么行動(dòng)？答案是為了業(yè)務(wù)決策。估算的最終目的是支持業(yè)務(wù)決策。估算會(huì)直接影響時(shí)間和成本，這也是商人一直關(guān)心的問(wèn)題，以便衡量他們的投資能獲得多少收益，也就是所謂的投資回報(bào)率（ROI，Return on Investment）。估算不是為了降低風(fēng)險(xiǎn)、提高速度或確保質(zhì)量，而是為了輔助決策。我見(jiàn)過(guò)很多人誤以為自己在做軟件開(kāi)發(fā)，但實(shí)際上他們做的是業(yè)務(wù)。

在敏捷項(xiàng)目中，產(chǎn)品負(fù)責(zé)人（Product Owner）代表業(yè)務(wù)并負(fù)責(zé)決策，他根據(jù)三個(gè)因素做出決定：范圍、資源和時(shí)間。估算與時(shí)間有關(guān)，產(chǎn)品負(fù)責(zé)人要監(jiān)控這三個(gè)因素之間的平衡，以確定應(yīng)該開(kāi)發(fā)什么以及何時(shí)開(kāi)發(fā)。例如，如果一項(xiàng)任務(wù)需要一天或一年的時(shí)間，做出的決定就會(huì)不同。如果任務(wù)估計(jì)只需要一天的時(shí)間，他可能會(huì)決定立即著手進(jìn)行。相反，如果估計(jì)需要一年，就可能會(huì)取消或推遲。估算對(duì)產(chǎn)品負(fù)責(zé)人的決策有巨大的影響。在敏捷項(xiàng)目中，產(chǎn)品負(fù)責(zé)人（Product Owner）代表業(yè)務(wù)并負(fù)責(zé)決策，他根據(jù)三個(gè)因素做出決定：范圍、資源和時(shí)間。估算與時(shí)間有關(guān)，產(chǎn)品負(fù)責(zé)人要監(jiān)控這三個(gè)因素之間的平衡，以確定應(yīng)該開(kāi)發(fā)什么以及何時(shí)開(kāi)發(fā)。例如，如果一項(xiàng)任務(wù)需要一天或一年的時(shí)間，她的決定就會(huì)不同。如果任務(wù)估計(jì)只需要一天的時(shí)間，她可能會(huì)決定立即著手進(jìn)行。相反，如果估計(jì)需要一年，她可能會(huì)取消或推遲。估算對(duì)她的決策影響巨大。

決策三角

敏捷項(xiàng)目和瀑布式項(xiàng)目的決策方法不同。在敏捷項(xiàng)目中，資源和時(shí)間是固定的，而范圍是靈活的。由于敏捷是為快速迭代交付而設(shè)計(jì)，因此產(chǎn)品負(fù)責(zé)人要考慮的是如何在有限的時(shí)間和資源內(nèi)實(shí)現(xiàn)產(chǎn)品價(jià)值的最大化。如果估算的范圍過(guò)大，無(wú)法在目標(biāo)時(shí)間內(nèi)完成，則應(yīng)按照優(yōu)先級(jí)縮小范圍。

另一方面，在瀑布式方法中，范圍是固定的，而資源和時(shí)間是靈活的。決策者的角色與敏捷項(xiàng)目中的產(chǎn)品負(fù)責(zé)人相同，需要考慮完成所有項(xiàng)目需要多少資源和時(shí)間。他需要采購(gòu)必要的人力資源，并根據(jù)范圍大小和估算制定計(jì)劃。

阿特拉斯敏捷鐵三角

雖然上述決策方法廣為人知，但固定和靈活的因素可能會(huì)根據(jù)業(yè)務(wù)環(huán)境發(fā)生變化。例如，在敏捷方法中，如果利益相關(guān)者要求通過(guò)推遲交付時(shí)間來(lái)完成所有工作，那么時(shí)間就會(huì)延長(zhǎng)。如果客戶預(yù)算有限，而軟件開(kāi)發(fā)的成本超出了他們的預(yù)期，那么瀑布式方法中的時(shí)間范圍就會(huì)縮小。應(yīng)根據(jù)實(shí)際情況調(diào)整決策，同時(shí)牢記這些基本方法。

原則 1：明確需求

第一條原則是明確需求。不確定性三角的研究表明，明確的需求最能提高估算的準(zhǔn)確性。換句話說(shuō)，需求越明確，估算就越準(zhǔn)確。

下圖說(shuō)明了估算變異性（不準(zhǔn)確性）是如何隨著時(shí)間的推移而縮小的。垂直線表示估算可變性，水平線表示時(shí)間（開(kāi)發(fā)階段）。如圖所示，隨著初步概念的形成、產(chǎn)品定義的批準(zhǔn)、需求的完成以及用戶界面的完善，估算變異性會(huì)明顯縮小。在總時(shí)間的前 20%-30%，錐形線明顯變窄，將估算可變性降低了 2 倍到 4 倍。如果不確定從哪里開(kāi)始估算，請(qǐng)從盡可能清晰的定義需求開(kāi)始。這一步看似顯而易見(jiàn)，但在許多項(xiàng)目中卻經(jīng)常被忽視。

原則 2：定義"完成"的含義

第二個(gè)原則是定義項(xiàng)目中完成的含義，即"完成的定義"（DoD，Definition of Done）。DoD 可以區(qū)分已完成和未完成的 PBI（Product Backlog Item，也稱為 ticket、issue 或 tasks），并提高產(chǎn)出質(zhì)量。估算中最常見(jiàn)的誤區(qū)之一就是忽視質(zhì)量保證過(guò)程，這往往會(huì)導(dǎo)致估算過(guò)低。為了讓客戶滿意，產(chǎn)品必須達(dá)到一定的質(zhì)量，質(zhì)量保證流程應(yīng)定義為 DoD。增加質(zhì)量保證步驟會(huì)讓開(kāi)發(fā)人員認(rèn)識(shí)到他們需要更多的時(shí)間來(lái)完成任務(wù)，以防止低估。下面列出了一些例子。

• 必須編寫(xiě)單元測(cè)試，覆蓋率必須超過(guò) 80%。
• 代碼審查必須由兩名軟件工程師進(jìn)行。
• 質(zhì)量檢查必須由測(cè)試人員進(jìn)行。
• 功能必須向產(chǎn)品負(fù)責(zé)人展示，以獲得反饋和最終批準(zhǔn)。

盡管 DoD 被定義為敏捷最佳實(shí)踐，但也可以（或應(yīng)該）用于瀑布式項(xiàng)目，因?yàn)闊o(wú)論項(xiàng)目管理類型如何，它都能帶來(lái)巨大的好處。而根據(jù)項(xiàng)目的不同，DoD 也有很大的不同。

原則 3：避免完美

第三個(gè)原則是避免追求完美，這意味著估算只是最佳的猜測(cè)，而不是開(kāi)發(fā)團(tuán)隊(duì)無(wú)論如何都必須遵守的最后期限。軟件開(kāi)發(fā)中的估算具有挑戰(zhàn)性，因?yàn)槿魏雾?xiàng)目都不盡相同。史蒂夫-麥康奈爾（Steve McConnell）是不確定性三角（The Cone of Uncertainty）的作者，他說(shuō)，沒(méi)有一個(gè)項(xiàng)目具有相同的需求、相同的人、相同的業(yè)務(wù)背景、相同的技術(shù)和相同的限制。因此，所有項(xiàng)目都包含大量的不確定性和不可預(yù)測(cè)性，這給估算帶來(lái)了困難。

與其追求完美的估算，不如隨著時(shí)間的推移不斷提高準(zhǔn)確性，這就是所謂的"Kaizen"或"持續(xù)改進(jìn)"。在開(kāi)發(fā)結(jié)束時(shí)，軟件工程師會(huì)回顧實(shí)際花費(fèi)的時(shí)間，檢查估算時(shí)間與實(shí)際時(shí)間之間的差距，相互分享經(jīng)驗(yàn)，并在下一次開(kāi)發(fā)中加以利用。在敏捷開(kāi)發(fā)（Scrum）中，Sprint 回顧是分享經(jīng)驗(yàn)的最佳時(shí)機(jī)，估算時(shí)間也會(huì)在 Sprint 中得到改善。如果一個(gè)軟件工程師被一個(gè)復(fù)雜的錯(cuò)誤困住了，花費(fèi)的時(shí)間超出了他的預(yù)期，他就會(huì)分享問(wèn)題是如何解決的，這樣其他軟件工程師就不會(huì)被同樣的錯(cuò)誤困住。尤其是，必須分享瓶頸所在，因?yàn)檫@將大大提高估算的準(zhǔn)確性。

另一個(gè)避免完美的技巧是估算范圍，而不要進(jìn)行精確估算，只估算最小值和最大值。例如，一項(xiàng)任務(wù)估算的最小時(shí)間為 3 天，最大時(shí)間為 5 天。不同項(xiàng)目的范圍各不相同，應(yīng)與產(chǎn)品負(fù)責(zé)人和業(yè)務(wù)人員協(xié)商。只要估算能幫助他們做出決策，范圍大小并不重要。三點(diǎn)估算也是一種估算技術(shù)，有三個(gè)點(diǎn)：最壞情況、最好情況和最可能情況，是相同的概念。

三點(diǎn)估算

原則 4：集體知識(shí)

第四項(xiàng)原則是利用集體知識(shí)，即集體估算。這背后的理念是，由多人做出的估算會(huì)比單獨(dú)估算更加精確。單人估算容易出現(xiàn)個(gè)人原則造成的疏忽，而多人估算則可以防止疏忽并提高準(zhǔn)確性。

"三人原則"（Three Amigos）是敏捷最佳實(shí)踐之一，即由三個(gè)關(guān)鍵人物（業(yè)務(wù)人員、測(cè)試人員和軟件工程師）對(duì)需求進(jìn)行審核，從而使集體知識(shí)變得有效。業(yè)務(wù)人員作為領(lǐng)域?qū)＜姨岢鲆?jiàn)解，軟件工程師從技術(shù)角度進(jìn)行檢查，測(cè)試人員審查如何確保質(zhì)量。如前所述，需求的質(zhì)量和清晰度至關(guān)重要，因?yàn)樗鼈儗?duì)估算的準(zhǔn)確性影響最大。

德?tīng)柗品ǎ═he Delphi method）是另一種利用集體知識(shí)進(jìn)行估算的技術(shù)。一組專家交換信息并進(jìn)行多輪討論，直至達(dá)成共識(shí)。德?tīng)柗品ㄒ沧C明了集體估算優(yōu)于個(gè)人估算，因此自 20 世紀(jì) 50 年代問(wèn)世以來(lái)一直被廣泛使用。

原則 5：不估算故事點(diǎn)

第五項(xiàng)原則是不做故事點(diǎn)的估算。盡管故事點(diǎn)被廣泛提及，仿佛是敏捷中的最佳實(shí)踐，但其實(shí)有幾個(gè)關(guān)鍵缺陷。最大的缺陷是，故事點(diǎn)永遠(yuǎn)無(wú)法幫助業(yè)務(wù)決策，而業(yè)務(wù)決策才是估算的最終目的。在進(jìn)行軟件開(kāi)發(fā)之前，首先要做的是業(yè)務(wù)。因此，我們必須基于商業(yè)中常用的指標(biāo)來(lái)支持商業(yè)決策。即使我們對(duì)某個(gè)任務(wù)的估算是 15 個(gè)點(diǎn)，業(yè)務(wù)人員也無(wú)法知道應(yīng)該如何處理，最終還是會(huì)問(wèn)："你什么時(shí)候能完成？"或者"完成這個(gè)任務(wù)需要多長(zhǎng)時(shí)間？"軟件開(kāi)發(fā)不是發(fā)明或研發(fā)，而是業(yè)務(wù)。無(wú)論項(xiàng)目的類型是 BtoB 還是 BtoC，投資者或贊助商關(guān)心的總是投資回報(bào)率。

第二個(gè)缺陷是，速度（velocity）對(duì)企業(yè)來(lái)說(shuō)根本不重要。當(dāng)我第一次了解到"速度"這一概念時(shí)，對(duì)其印象頗為深刻。然而，經(jīng)過(guò)進(jìn)一步思考，我開(kāi)始思考開(kāi)發(fā)速度的含義。例如，我從未聽(tīng)到有人談?wù)撨^(guò)業(yè)務(wù)速度或商務(wù)速度。沒(méi)有人會(huì)說(shuō)："這個(gè)月的業(yè)務(wù)速度是 500 點(diǎn)"，并為此感到高興。同樣，沒(méi)有人會(huì)關(guān)心軟件開(kāi)發(fā)的速度，聽(tīng)到本月的軟件開(kāi)發(fā)速度是 1000 點(diǎn)就高興得不得了。真正重要的是截止日期和任務(wù)是否完成。再說(shuō)一遍，軟件開(kāi)發(fā)就是業(yè)務(wù)。

我們必須使用常見(jiàn)的業(yè)務(wù)指標(biāo)，如小時(shí)、天或周，而不是故事點(diǎn)，因?yàn)闃I(yè)務(wù)使用這些指標(biāo)，而且與職業(yè)、國(guó)家等無(wú)關(guān)。只要有助于業(yè)務(wù)決策，項(xiàng)目之間的度量標(biāo)準(zhǔn)可以不同。

原則 6：粗略估算是可行的

第六項(xiàng)原則是可以進(jìn)行粗略的估算。在大多數(shù)情況下，業(yè)務(wù)人員在提出想法和確定需求之前，都會(huì)要求進(jìn)行粗略估算。應(yīng)該采取的正確做法是，在提出粗略估算時(shí)，強(qiáng)調(diào)這只是一個(gè)粗略估算，極有可能發(fā)生變化。這有助于業(yè)務(wù)決策，而且在修改估算時(shí)也不會(huì)有人生氣。

試想一下，乘坐出租車時(shí)，司機(jī)說(shuō)"我不知道要多久"或"要 30 分鐘到一個(gè)小時(shí)"。前者對(duì)你沒(méi)有任何幫助，而后者可能會(huì)讓你放棄打車，改乘地鐵。正因如此，大多數(shù)共享出行服務(wù)都會(huì)顯示到達(dá)目的地所需的大致時(shí)間，盡管并不精確，而且由于很多不確定因素（天氣、意外事件、事故等），很難預(yù)測(cè)交通情況。

不過(guò)，如果你是分包商，而客戶還沒(méi)有付款，情況就不一樣了。由于估價(jià)是關(guān)鍵信息，需要花費(fèi)大量精力，因此很多人都會(huì)假扮潛在客戶，試圖套取估價(jià)。在這種情況下，應(yīng)該將其作為討價(jià)還價(jià)的籌碼，并仔細(xì)考慮是否應(yīng)該給出估計(jì)以及何時(shí)給出。在為軟件分包商工作時(shí)，我看到過(guò)很多人和公司都在問(wèn)："請(qǐng)只要告訴我估價(jià)就好。"但最后他們從不付錢。

原則 7：越小越好

小任務(wù)使估算更容易，也更準(zhǔn)確。敏捷最佳實(shí)踐之一就是將任務(wù)（用戶故事）做得足夠小，以便在一個(gè)沖刺（通常為 1 或 2 周，最多不超過(guò)一個(gè)月）內(nèi)完成。這是因?yàn)楫?dāng)任務(wù)變大時(shí)，軟件的復(fù)雜性會(huì)呈指數(shù)級(jí)增長(zhǎng)，而不是線性增長(zhǎng)。例如，估算下一周能完成的任務(wù)比估算下一年能完成的任務(wù)要容易得多。任務(wù)越小，估算就越準(zhǔn)確。如果發(fā)現(xiàn)項(xiàng)目任務(wù)過(guò)大，就應(yīng)該把它們分解成幾周內(nèi)可以完成的較小任務(wù)。這種做法也同樣適用于瀑布式項(xiàng)目。

軟件復(fù)雜度和任務(wù)規(guī)模

除了估算的準(zhǔn)確性，小任務(wù)還能提高質(zhì)量，因?yàn)橐?guī)模小，使得開(kāi)發(fā)、測(cè)試和發(fā)布更容易調(diào)試，也更容易識(shí)別受影響的區(qū)域。而大型任務(wù)則會(huì)使軟件復(fù)雜度成倍增加，成為滋生錯(cuò)誤的溫床。

原則 8：盡量獨(dú)立

獨(dú)立的任務(wù)可以提高估算的準(zhǔn)確性。依賴性是軟件項(xiàng)目中最大的挑戰(zhàn)之一，因?yàn)楹茈y識(shí)別并會(huì)增加編程的復(fù)雜性。獨(dú)立任務(wù)的復(fù)雜性較低，有助于提高估算精度。

在估算和任務(wù)管理中，獨(dú)立任務(wù)指的是可以完成并發(fā)布的任務(wù)，而無(wú)需處理或等待其他任務(wù)。雖然由于軟件項(xiàng)目的性質(zhì)，不可能消除所有依賴關(guān)系，但必須努力盡可能將任務(wù)與其他任務(wù)隔離開(kāi)來(lái)。

隨著需求定義的深入，依賴關(guān)系會(huì)逐漸清晰。但是，如果在需求定義后仍不確定，那么領(lǐng)域建模會(huì)有所幫助。領(lǐng)域建模是埃里克-埃文斯（Eric Evans）創(chuàng)建的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain Driven Design）的一部分，它從業(yè)務(wù)角度說(shuō)明了對(duì)象之間的關(guān)系，并澄清了依賴關(guān)系。DDD非常有效，正如 SAFe（大規(guī)模敏捷框架）所闡明的那樣，"如果在敏捷中只對(duì)一件事建模，那就對(duì)領(lǐng)域建模"。

結(jié)論

估算的主要目的是幫助業(yè)務(wù)人員進(jìn)行商業(yè)決策。業(yè)務(wù)人員根據(jù)范圍、資源和時(shí)間這三個(gè)因素決定何時(shí)做什么，而估算與時(shí)間有關(guān)。他們的決策會(huì)因完成工作所需的時(shí)間長(zhǎng)短而大相徑庭。

• 原則一是明確不確定性三角的需求，對(duì)開(kāi)發(fā)階段和估算精度之間關(guān)系的研究表明，明確的需求對(duì)估算精度的提高最大。
• 原則二是在團(tuán)隊(duì)中定義完成的含義，即DoD。DoD 可以區(qū)分已完成的項(xiàng)目和未完成的項(xiàng)目，提高產(chǎn)出質(zhì)量，防止低估。
• 原則三是避免盡善盡美，逐步提高估算的準(zhǔn)確性。由于估算只是最佳猜測(cè)，而不是最后期限，因此當(dāng)情況發(fā)生變化時(shí)，應(yīng)通過(guò)協(xié)商進(jìn)行調(diào)整。范圍估算法和三點(diǎn)估算法通過(guò)范圍進(jìn)行估算，既能避免完美，又能幫助業(yè)務(wù)人員進(jìn)行決策。
• 原則四是依靠集體知識(shí)，即與小組成員一起估算，而不是單獨(dú)估算。這背后的理念是，集體估算比單獨(dú)估算更準(zhǔn)確，因?yàn)檫@樣可以防止疏忽。三人原則：業(yè)務(wù)人員、軟件工程師和測(cè)試人員，是審查需求以提高估算準(zhǔn)確性的最佳做法。
• 原則五是不進(jìn)行故事點(diǎn)估算。雖然"故事點(diǎn)"被廣泛提及，似乎是敏捷的最佳實(shí)踐，但無(wú)助于決策，盡量避免使用。沒(méi)有業(yè)務(wù)人員會(huì)用故事點(diǎn)來(lái)做決策，這不是商業(yè)中常用的衡量單位。
• 原則六是可以進(jìn)行粗略估算。在大多數(shù)情況下，業(yè)務(wù)人員會(huì)在有想法和確定詳細(xì)需求之前要求進(jìn)行粗略估算。在這種情況下，我們可以提出粗略估算，因?yàn)檫@對(duì)他們有幫助。但是，如果你是分包商，而客戶還沒(méi)有付款，就必須考慮是否應(yīng)該避免提供，因?yàn)榇致怨浪闶怯袃r(jià)值的信息，很多人都會(huì)想方設(shè)法榨取這些信息，但不付錢。
• 原則七是越小越好。大任務(wù)會(huì)增加軟件復(fù)雜性，成為滋生錯(cuò)誤的溫床。小任務(wù)能提高估算的準(zhǔn)確性。此外，因?yàn)樾∪蝿?wù)更容易確定受影響的區(qū)域并進(jìn)行調(diào)試，因此還有助于提高軟件質(zhì)量。
• 原則八是盡量獨(dú)立。依賴性是軟件項(xiàng)目中最大的挑戰(zhàn)之一，會(huì)增加軟件的復(fù)雜性。如果一項(xiàng)任務(wù)是獨(dú)立的，就更容易估算。通常，需求越清晰，依賴性就越明顯。如有必要，可以使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)技術(shù)之一的領(lǐng)域建模。