如何優化您的估算過程？

Question

估計任何給定任務將花費多長時間似乎是軟件開發中最困難的部分之一。在我目前的商店中，我們估計在迭代開始時以小時爲單位的任務，但一旦任務完成，我們就不會用它來幫助我們進行未來的估計。

您如何使用您從過去的估算中收集的信息來優化未來的信息？

Answer 1

到目前爲止，我所見過的最有趣的方法之一就是Evidence Based Scheduling，它是FogCreek FogBugz 6.0發行版的一部分。請參閱上面鏈接Joel的博客文章以獲取摘要和一些示例。

Answer 2

如果一個估計被吹掉了，試圖確定它是否只是隨機的（環境破壞了，有些人一旦掉了一個棘手的bug等），或者有些東西是你沒有識別的。

如果一個esimate太大，找出你認爲這會花費那麼長時間，並找出爲什麼它沒有。

這樣做有希望能夠幫助開發者進行估算。例如，如果開發人員認爲爲控制器編寫測試需要很長時間，然後最終花費的時間比他想象的要少，那麼對於類似範圍的控制器所做的下一個估計可以保留心神。

Answer 3

我估計會和我的隊友們迭代，直到我們達成共識。當然，我們犯了錯誤，但我們並沒有明確計算「速度」因素，而是在我們的新估計辯論中使用了收集的經驗。

Answer 4

我發現到目前爲止估算時間會讓你滿意。與其他任務的干擾，未預見的情況或項目影響將不可避免地改變你的時間框架，如果你不斷重新評估，你會浪費很多時間來管理你何時可以開發。

因此，對於我們這裏，我們給出了一個基於經驗的初步估計，以解決時間問題（我們不使用模型，我沒有發現在我們的環境中工作得很好的模型），但不要評估我們的KPI反對它，我們也不保證業務這個最後期限將會受到打擊。我們在這裏的發展方式在很大程度上是被動的，它似乎很好地滿足了我們業務對我們的要求。

Answer 5

估計結束時，幾乎總是有一個公然的原因，這導致了一個教訓。從內存中最近的：

• 用戶界面假定不存在（插入新行，並在GridView內嵌編輯的能力）.NET功能;吸取的教訓是在提交估計之前驗證所選類別的功能。這個錯誤花了一個星期。

• ftp進程假定FtpWebRequest可以與銀行的安全ftp服務器通話;事實證明，如果ftp服務器爲當前目錄返回除反斜槓之外的任何其他內容，則該類存在已知的錯誤;經驗教訓是谷歌的錯誤和類問題的'問題'，不只是'教程'和'示例'，以確保沒有'陷阱'潛伏。這個錯誤需要三天時間。

這些教訓進入一個項目評估與發展「清單」的文件，所以他們不會忘記爲下一個項目