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

為什么估算很重要？

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

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

決策三角

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

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

阿特拉斯敏捷鐵三角

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

原則 1：明確需求

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

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

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

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

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

盡管 DoD 被定義為敏捷最佳實踐，但也可以（或應該）用于瀑布式項目，因為無論項目管理類型如何，它都能帶來巨大的好處。而根據(jù)項目的不同，DoD 也有很大的不同。

原則 3：避免完美

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

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

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

三點估算

原則 4：集體知識

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

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

德爾菲法（The Delphi method）是另一種利用集體知識進行估算的技術(shù)。一組專家交換信息并進行多輪討論，直至達成共識。德爾菲法也證明了集體估算優(yōu)于個人估算，因此自 20 世紀 50 年代問世以來一直被廣泛使用。

原則 5：不估算故事點

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

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

我們必須使用常見的業(yè)務(wù)指標，如小時、天或周，而不是故事點，因為業(yè)務(wù)使用這些指標，而且與職業(yè)、國家等無關(guān)。只要有助于業(yè)務(wù)決策，項目之間的度量標準可以不同。

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

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

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

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

原則 7：越小越好

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

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

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

原則 8：盡量獨立

獨立的任務(wù)可以提高估算的準確性。依賴性是軟件項目中最大的挑戰(zhàn)之一，因為很難識別并會增加編程的復雜性。獨立任務(wù)的復雜性較低，有助于提高估算精度。

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

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

結(jié)論

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

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