作為Stack Overflow的首席Web開發(fā)人員和長期的技術主管，我了解到準確的估算對于公司的健康和生產力至關重要。多年來，我花了很多時間來開發(fā)我的理論，以了解為什么估算和分類分解如此重要，并針對如何做到最好而設計自己的方法。 

下面，我嘗試提煉出我學到的教訓，以便其他人可以嘗試并改進我的技術?，F(xiàn)在，我應該清楚，以下建議對我有用。我敢肯定，有其他方法可能對其他人更好。隨時在評論中分享您最喜歡的方法。

為什么開發(fā)人員要求提供估算值？

對開發(fā)工作進行估算的動力通常來自組織中的非開發(fā)人員。估算有助于計劃和協(xié)調產品發(fā)布，與其他團隊同步工作，確保正確分配資源以滿足產品需求，當然還可以在聘用您的團隊來完成工作時為客戶提供準確的賬單外部公司。 

有了這個清單，很明顯有很多合理的理由要求您進行估算。并且由于多種原因（內gui，良好的意愿，估算請求者的壓力），您甚至可能給出最佳估算。但是，正如我們許多人所學到的那樣，雖然給某人一個數(shù)字很容易，但要給它一個準確的數(shù)字卻要困難得多。而且由于其他人對提供的數(shù)字的依賴性，錯誤的評估有時會造成比根本沒有評估更大的損害。

好的估算可以提供什么

通過了解其先決條件（以及它們要求的組織和計劃水平），準確的估算將使您能夠在最短的時間內以高質量的水平交付工作。它將幫助您避免錯誤的開始以及不必要地丟棄代碼的痛苦。這將有助于最小化范圍更改。它使您能夠以最有效的方式來組織和計劃工作，并且還將極大地幫助上一節(jié)中提到的所有其他利益相關者。 

估算規(guī)則

那么您應該如何估算呢？估算技術是每個開發(fā)人員必須自己做出的個人決定。下面將針對過去曾為不同人群使用的不同技術提出建議，以得出最終估計。 

也就是說，這里有一些重要的指導原則（與估算技術無關）。 

除非您對所需的功能有很好的了解，否則請不要編寫代碼

雖然這與進行實際估算沒有直接關系，但它是列表的頂部，因為它是編寫高質量軟件的重要因素，可以實際執(zhí)行客戶所需的工作。準確的估算可以為他人帶來好處，準確的估算可以為您帶來的主要結果是，您可以確信自己正在從事的工作，已經考慮過架構和實現(xiàn)可能產生的各種問題，并且您在分解工作和進行估算時已將這些考慮在內。

始終根據(jù)規(guī)格估算

如果不是基于對功能需求的深入了解而做出的估算，很可能會導致估算不準確，因為它無法說明所有必需的功能。即使召開會議討論需要什么，除非將其寫下來并且所有利益相關者都同意其內容，否則應該假定其中一個利益相關者對需求的理解與其他利益不同。

如果規(guī)范中有未解決的問題或缺少詳細信息，請不要對該部分進行估算或從事該部分的工作

規(guī)范編寫過程的重要部分是查看規(guī)范并根據(jù)需要提出問題。請花些時間來介紹會影響功能的情況和實現(xiàn)細節(jié)。標出缺少重要細節(jié)的部分（這些通常是規(guī)范中最復雜的部分）。 

編寫規(guī)范需要時間，有時某些要求直到項目后期才被理解。很好，可以接受。這樣的結果是，無法對規(guī)范中不完整的部分進行準確的估算。

如果估算者尚未徹底檢查規(guī)格，則估算將不準確

如果不查看規(guī)格，估計器就沒有適當?shù)哪芰砉烙嬐瓿煽蛻舳怂韫δ艿哪芰?。解決這一問題沒有真正的辦法，在這種情況下做出估計實際上與需要完成的工作相關的機會很小。

從事這項工作的開發(fā)人員應執(zhí)行估算

除將要進行工作的人以外的其他人做出的估計更難于正確。即使估算是基于估算者理解的完整規(guī)范，它仍然存在一些主要缺點： 

• 每個開發(fā)人員的工作速度都不同，因此一個開發(fā)人員的估算通常不會轉移給第二個開發(fā)人員。

• 每個開發(fā)人員都會分解并以不同的方式計劃他們的工作。

• 不同的開發(fā)人員擁有不同的領域知識集，這也使得估計用于學習/理解更改后果的時間非常不同（如果您不具備領域知識，請務必在估計中考慮額外的時間） 。

• 如果開發(fā)人員不進行估算，那么他們將錯過計劃項目執(zhí)行的極其寶貴的步驟，這將有助于避免不必要的工作并按計劃交付功能。

在整個項目過程中（包括范圍變更）保持規(guī)范和最新估計

理想情況下，隨著需求和范圍的變化，規(guī)格和估算值應在整個項目過程中保持最新。對于正確執(zhí)行質量檢查，它將是必不可少的，對于將來需要進一步了解該功能的任何人，它都將是非常方便的參考。

學科

不要欺負自己對未正確定義的部分進行全面估算

一旦您與利益相關者達成了一個階段，人們就開始參與進來，讓開發(fā)人員成為估算的作者，這可能會導致出現(xiàn)壓力，要求對尚未完全定義的工作進行估算。最好的意圖可能會發(fā)生這種常見情況。需要制定計劃，并且往往需要沒有直接方法進行定義過程的人員來制定計劃。當這些計劃依賴估計時，它可能會使開發(fā)人員陷入困境。

在這種情況下，非常重要的一點是要明確：可行的估算必須基于明確定義的工作。向利益相關者明確這一點很重要。并且，在這樣做的同時，請確保突出顯示您想要給他們一個可靠的估計，而在不了解整個工作范圍的情況下，幾乎肯定會得出不可靠的估計。在有需要的情況下，您總是可以提供夸大的，最壞的情況下的估算，但是應該避免這種情況，并且在必須時，一定要讓利益相關者知道估算本身可以進行更新并變得更加準確。有關項目定義的更多詳細信息是已知的。

不要根據(jù)外部時間來估算時間。刪除功能。

可能發(fā)生的另一種令人不安的情況是，當利益相關者試圖根據(jù)外部依賴性或其他業(yè)務需求來指示估算值時，即使與實際估算值不一致。希望使開發(fā)人員能夠對此估計值做出承諾，將確保在這些時間限制內完成工作（或者如果沒有，則開發(fā)人員可以對錯過最后期限負責）。到現(xiàn)在應該很清楚，任何不基于對定義明確的要求進行實際分解的估計都不應被認為是可靠的，或者實際上根本不能給出。在這種情況下，正確的響應是協(xié)商時間表的范圍。如：如果您要在此日期之前發(fā)布，那么我們需要減少需要完成的工作量。

將小時轉換為幾天：切合實際

您的估計最終應該設置一些小時來完成定義的任務。為了進行規(guī)劃，通常會在項目的早期就詢問您需要編碼多少天。我發(fā)現(xiàn)以小時為單位創(chuàng)建精細估算并將總小時數(shù)轉換為幾天數(shù)更為準確。在執(zhí)行此操作時，請確保將諸如其他職責（錯誤職責，其他項目），管理職責，休假和假期等因素考慮在內。另外，請確保說明開發(fā)人員需要執(zhí)行的例行任務（會議，電子郵件，規(guī)格審查，計劃）。我發(fā)現(xiàn)，假設每天進行超過6.5個小時的生產性項目工作，可能會導致生產率預期與實際結果不匹配。 

將您的細目分類和估算公開，并征求反饋

一旦您完成了分解并完成了估算，最好將其在線發(fā)布并與您的項目經理和團隊成員共享。即使他們比您對規(guī)范的細節(jié)不太熟悉，其他人也可能會在您的細目分類中發(fā)現(xiàn)漏洞，或者可能對您未曾想到的特定項目的估計值提出疑問。切記：隨著您進入項目的越遠，修復問題的成本就成倍增加。更改一條估計線很便宜。不能從頭開始重寫模塊?；~外的時間來征求反饋。

公開發(fā)布估算值（并就任務完成情況保持最新狀態(tài)）也使您對進度更負責（以一種很好的方式）。負責任的PM將定期檢查您的進度，尤其是在看起來事情停滯時（無論如何，您都應與PM保持公開溝通）。

可以給出估計范圍以及置信度

如果無法及時完成整個規(guī)格的估計，請為可以使用的零件提供完整的估計，并為不完整的部分提供范圍/可信度。使用您的判斷：您可能會要求您對一個大型項目進行100％的置信度評估，但是如果規(guī)范尚未準備就緒，那么請清楚您的評估涵蓋的范圍。從長遠來看，對于每個人來說，60％的時間充滿信心并擁有60％的信心要好于不說或不以任何內容為基礎準確地計算出一個數(shù)字。然后，隨著規(guī)格變得更加完整，估計值也應隨之而來。

減輕風險并考慮較大項目的迭代

大型項目（任意定義：預計需要兩個月以上的時間，盡管可能會有所不同）面臨著一系列挑戰(zhàn)。他們將擁有更大的估算值（因此有更多機會弄亂估算值），他們將有更多的人依賴于預計的發(fā)布日期而不論其依賴程度如何，他們更有可能擁有大型規(guī)格，而并非所有功能都預先定義，并且它們更有可能（至少在某些域中）具有發(fā)布/迭代的周期。如何在估算中說明這些？

雖然每個項目都需要根據(jù)自身需求進行處理，但是具有迭代功能的大型項目的一般方法應該是在宏觀和微觀層面上都使用上述準則。如果非常大的項目中有一個工作部分在規(guī)范中已完全定義，而其余部分則是松散定義的，則請對第一部分進行細分和估算。如果需要整個項目的完整估算，請根據(jù)對功能的了解對整個事情進行非常保守的估算，并附上您的假設和對數(shù)量的信心，并繼續(xù)努力完成整個規(guī)格并完成所有工作。您的問題得到了回答。 

這也適用于迭代：如果項目計劃需要一個連續(xù)的發(fā)布周期，并且在整個迭代過程中不斷完善和重新定義功能，那么從定義上來說，這對于從頭開始進行準確的估算將是極具挑戰(zhàn)性的沒有定義的功能要求。在這種情況下，您對評估的信心就不能像使用完整功能說明那樣自信。如果這是現(xiàn)實情況，并且要求您提供前期估計，那么除了對假設不明確的部分進行非常保守的估計之外，沒有其他事情要做，請注意您的假設和置信度。不幸，

確保留出時間處理拉取請求，測試和發(fā)布問題 

這是很容易忘記的事情，在按時交付功能以及最后階段交付時，拖拉時間進行拉動請求測試和產品發(fā)布（尤其是當這些都不重要時）會在每個人的口中留下難聞的味道。質量檢查和發(fā)布最終會持續(xù)拖延。在PR是流程必不可少的部分的情況下，尤其是當它們成為非常繁忙的審閱者的瓶頸時，將它們添加到估算中的時間可能并不容易。雖然不一定會增加開發(fā)人員的時間（盡管可能會增加反饋的數(shù)量），但會增加交付時間。負責任的開發(fā)人員應根據(jù)項目職責的具體情況，在規(guī)劃和做出可交付成果的承諾時要考慮到這些因素（例如：

技術技巧

最好的估計包括將要執(zhí)行的工作分解為小任務-越小越好。估計任務，將其分解，然后重復直到它們變得足夠小為止。這是非常徹底和準確的估計方法的本質。建立粒度目標。我建議最多兩個小時，然后分解任務，直到全面解決。如果您的任務超過閾值，請進一步細分。然后總結一下。 

您可以使用多種工具來組織此工作。我更喜歡使用Trello卡（每個主要任務一張，帶有一個小節(jié)清單，以及一個用于粒度的復選框），盡管這確實需要人工計算工時。您還可以使用Excel，MS Project，F(xiàn)ogBugz（或那里的許多其他項目組織工具之一）。最重要的是，您使用的工具適用于您和您的流程，并且不會增加組織開銷。

還有其他估算方法（我在本文中對估算實踐進行了更深入的介紹）。特別是在敏捷世界中，從Planning Poker到許多其他游戲。如果這對您有用，并且可以幫助您獲得準確的估算，請繼續(xù)使用。請記住，依賴于將估算責任從將要進行實際工作的開發(fā)人員身上擺脫的技術可能會有風險。 

您是否想過如何最好地提供估計，以便開發(fā)人員和開發(fā)團隊可以與組織的其余部分一起工作？讓我們知道您在提示中的提示和技巧。