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

為什么估算很重要？

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

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

決策三角

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

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

阿特拉斯敏捷鐵三角

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

原則 1：明確需求

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

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

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

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

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

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

原則 3：避免完美

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

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

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

三點估算

原則 4：集體知識

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

"三人原則"（Three Amigos）是敏捷最佳實踐之一，即由三個關鍵人物（業務人員、測試人員和軟件工程師）對需求進行審核，從而使集體知識變得有效。業務人員作為領域專家提出見解，軟件工程師從技術角度進行檢查，測試人員審查如何確保質量。如前所述，需求的質量和清晰度至關重要，因為它們對估算的準確性影響最大。

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

原則 5：不估算故事點

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

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

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

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

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

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

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

原則 7：越小越好

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

軟件復雜度和任務規模

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

原則 8：盡量獨立

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

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

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

結論

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

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