但凡有過商業項目開發經驗的程序員都在開發時間估算方面遇到過各種狀況，其中最常見的是——實際的開發時間總比估算的多很多。

很多人說不清楚為什么會這樣，本文就來帶你探究一下影響開發時間估算的因素有哪些！

作為個體軟件工程師而言，你通常沒有足夠的背景、教育經歷或經驗來確定時間進度，所以你應該與項目經理進行溝通，向他們解釋時間進度表中需要考慮的事項（不僅僅是編寫代碼所需的時間），然后構建一個估計時間的方法。

如何估計開發時間取決于你所參與的項目的規模，比如是一個小型項目、中型項目還是一個大型項目，或者僅僅是一個項目的某一部分。

0 1

估計小型項目的開發時間

根據定義，一個小型項目是一個軟件工程師可以單獨完成的項目。對項目進度的主要影響是這個軟件工程師的能力和生產力。

估計小型項目的開發時間比估計大型項目要容易得多，也更加準確。小型項目不會涉及并行開發，并且在進度表中只需要考慮單個開發人員的生產力。

毫無疑問，估計小型項目的開發時間，第一步是識別和理解需要完成的所有工作。如果此時項目的某些部分還沒有被清晰定義，那么在進度表中就會引入相當大的錯誤，因為這些未定義的組件，不可避免地要花費比你想象的多得多的時間。

在估計某個項目的完成時間時，設計文檔是項目中最重要的部分。如果沒有詳細的設計，那么就不可能知道項目由哪些子任務組成，以及每個子任務將花費多少時間來完成。一旦你將項目分解成適當大小的子任務（一個合適的大小，就是清楚地知道完成它需要多少時間），你需要做的就是將所有子任務的時間匯總起來，從而產生一個合理的初步估計。

然而，人們在估計小型項目的進度時最常犯的一個最大的錯誤是，他們會把子任務的時間加到進度表中，而忘記了會議、電話、電子郵件和其他管理任務的時間。

他們還容易忘記增加測試時間，以及發現和修復缺陷（和重新測試）的時間。

因為很難估計軟件中存在多少缺陷，以及解決這些缺陷需要多少時間，所以大多數管理人員會將進度表中第一次估計的值擴大2~4倍。

假設程序員（或團隊）在項目上能夠保持合理的生產力，那么這個公式可以用來很好地估計小型項目的開發時間。

0 2

估計中型項目和大型項目的開發時間

從概念上講，中型項目和大型項目是由許多小型項目（分配給各個團隊成員）組成的，它們結合起來形成最終的結果。

因此，第一種估計大型項目進度的方法，是將其分解為一堆較小的項目，然后估計每個子項目的開發進度，再合并（匯總）起來進行總體估計。

這是估計小型項目進度的放大版本。

遺憾的是，在現實情況中，這種估計方式會帶來很多問題。

第一個問題是，中型項目和大型項目會存在小型項目中不存在的問題。

一個小型項目通常只有一個工程師，并且正如前面所提到的，對小型項目的時間安排完全取決于這個工程師的生產力和可投入時間。

在一個較大的項目中，許多人（包括工程師以外的人）都會影響到對進度的估計。一個擁有關鍵知識的軟件工程師可能在休假或者生病幾天，耽誤了另一個工程師獲取所需信息來開展工作。

從事大型項目開發的工程師通常每周都會有幾次會議（這些會議在大多數日程安排中都沒有提到），這些會議會讓他們持續下線幾個小時，也就是說，在這段時間內他們沒有在編程。

在大型項目中，團隊組成結構也可能會發生變化，例如，一些有經驗的程序員離開了，而另一些人不得不繼續學習其他子任務，而且新加入項目的程序員需要時間來跟上進度。

有時候，即使是為新員工配備一個計算機工作站，也要花上幾周的時間（例如，在一家非常官僚的大公司的IT部門）。

等待購買軟件工具、開發硬件以及來自組織其他部分的支持，也會造成進度安排失效的問題。

這樣的例子不勝枚舉。很少有進度估計能夠準確地預測出這些會消耗多少時間。

最終，估計中型項目和大型項目的進度會包括4個任務，即把項目分解成多個較小的項目，估計這些小項目的進度，增加集成測試和調試的時間（也就是讓各個小項目結合到一起并且正常工作的時間），然后通過一個乘數因子得到最終的合計結果。

這種方式并不精確，但是它到今天依然有效。

0 3

估計開發時間的問題

因為項目進度估計涉及對開發團隊未來能力的預測，所以很少有人相信計劃的進度是完全準確的。

然而，常見的軟件開發進度預測尤其糟糕，其中有以下一些原因：

它們是在研發項目。研發項目包括做一些你以前從未做過的事情。它們需要一個研究階段，在此期間開發團隊需要分析問題并試圖確定解決方案。通常，沒有辦法預測研究階段需要多長時間。

管理層已經預先制定了時間表。通常，市場部門決定其想要在某個日期之前銷售產品，而管理部門則通過從該日期向前倒推時間來制訂項目計劃。在要求開發團隊估計子任務的時間之前，管理層已經對每個任務應該花費的時間有了一些先入為主的想法。

這個團隊以前做過類似的事情。管理層通常會認為，如果你以前做過某件事情，那么第二次做起來會更容易（因此會花費更少的時間）。在某些情況下，這是有道理的。如果團隊做的是同一個研發項目，那么第二次做就會更容易，因為他們只需要做開發，可以跳過（至少大部分）研究階段。但是，認為項目第二次做總是更容易的假設很少是正確的。

沒有足夠的時間和資金。在很多情況下，管理人員會在項目必須完成的前提下，設置某種資金或時間限制，否則該項目就會被取消。對于那些薪水跟項目進展掛鉤的人來說，這是錯誤的。如果讓他們在說“是的，我們能滿足計劃”和找一份新工作之間做出選擇，大多數人即使知道機會很渺茫，也都會選擇前者。

程序員會夸大他們的效率。有時候，當軟件工程師被問到他們能否在一定時間內完成一個項目時，他們不會謊稱需要多長時間，而是對他們的表現做出樂觀的估計，但是實際上在工作中很少會站得住腳。當被問及他們可以產生多少有效工作時，大多數軟件工程師會給出一個圖表，展示其有史以來在一個較短時間內的最大產出（例如，在“危機模式”下每周可工作60~70個小時），但是他們很少會考慮意料之外的困難（例如，出現一個很嚴重的系統缺陷）。

進度取決于額外的時間。管理層（和某些工程師）經常會認為，當進度開始延后時，程序員總是可以多投入“幾個小時”來趕上進度。結果是，進度往往比他們期望的會更加延后（因為他們忽略了工程師大量加班所帶來的負面影響）。

工程師就像搭積木一樣。在項目進度安排中一個常見的問題是，管理層認為可以通過向項目中增加程序員人數來提前發布軟件。然而，正如前面所提到的，這并不一定是正確的。你不能通過在一個項目中增加或者減少工程師人數，就期望項目進度能產生相應的變化。

對子項目的估計是不準確的。實際的項目進度安排是以自上而下的方式制訂的。整個項目被分成幾個較小的子項目，然后這些子項目又被分成幾個子項目，依此類推，直到子項目的規模非常小，有人可以準確地預測每個子項目所需的時間。但是，這種方法會面臨三個挑戰：

• 是否愿意盡力以這種方式來安排進度（即對項目提供正確、準確的自上而下的分析）。

• 是否能夠對小的子項目進行準確的估計（特別是軟件工程師，他們可能沒有經過適當的管理培訓，所以不清楚哪些因素是在估計進度時需要考慮的）。

• 是否愿意接受進度預估的結果。