你如何對編碼任務做出非常快速（和骯髒）的估計？

Question

所以你剛剛被The Boss放在了現場。 你有15分鐘的時間想出一個新的功能的信封估計的背面。你的老闆（幸運的是）認識到你不能在那個時候提供一個準確的估計，所以期望的東西是在正確的數量級。

問題是你如何在準確到一個數量級的時間框架內做出估計？

---

注意，這意味着是一個快速和骯髒的估計，不是可能從問題有望像this

Answer 1

我個人拒絕這種類型的東西。但後來我爲自己工作，所以我不回答老闆。只是一個客戶，但更容易讓他們明白自己很難在現場做。

Answer 2

在這種時候，我記得麥肯齊兄弟的規則就轉換成公制：「加倍，並添加三十倍的。」

我一般拿出我原來的速度有多快想它會做的事情，然後雙擊它，因爲我低估了我總是，然後添加30進行測試，根據我使用的單位。

Answer 3

回想過去完成的類似任務，以及他們花了多長時間完成的任務。

如果之前你沒有做過類似的事情，試着將任務分解爲子任務，然後每個子任務進一步下去，直到沒有任何子任務被留下，聽起來需要花費比1-2天更長的時間最天真的可能方式;如果你不能分割一個估計時間超過3天的任務，這通常意味着你並不真正瞭解執行該任務的內容;做一些快速的研究。一旦所有的東西都被分解了，把它加起來，把結果加倍，並把它作爲你的估計。

如果你不知道如何處理的問題，足以做到以上，和你的老闆是呼吸你的脖子，所以你不覺得你可以研究那裏，然後，而是儘量給你的老闆的估計你需要花多長時間去做足夠的理解問題所需的研究，才能給他一個合適的估計。

Answer 4

最好的方法是嘗試快速分解所有主要的子組件，

1. 更新數據模型腳本（在2和表3項）
2. 更改輸入畫面（3個新輸入）
3. 檢查輸入（3個新輸入）
4. 更新數據。
5. 顯示結果 等...
6. 構建單元測試

指定有關每個粗略估計，如果你想不出一個放下至少2小時的，因爲即使是最簡單物品可能需要至少一個小時，但2倍將允許不確定性。

至少你會以爲你將不得不這樣做，這將是在幅度的正確順序爲請求的項目。

Answer 5

將手指放在嘴裏，舔，揮動空氣，根據過去的經驗組成一個數字。然後加倍。

真的，它的正義體驗很重要。你可以想象這項任務需要你做什麼，而且你知道需要多長時間才能做到這一點。將其加倍以用於意料之外的項目。這也是爲什麼你從不問初級程序員這樣的估計。

Answer 6

我無法想象一種我根本無法做出估計的情況 - 更常見的情況是，我可以想象出多種情況，這會導致項目的時間框架大不相同，這取決於各種事情這可能會合理地出現。我不想說謊 - 你可以用你的老闆做的最糟糕的事情就是製作一些東西。

所以我解釋了每種可能性。當然，這隻適用於一位理解的老闆，但如果你的老闆太無知或愚蠢，他拒絕聽完整個解釋，你還有其他問題。

例如，下面是我爲最近的情況做了這樣的事情，我實際上不得不這樣做。

x264，我工作的視頻編碼器，實現了一種非常原始的隔行編碼形式，因爲它非常易於實現。我們想要實現這種編碼的完整形式，但我不知道在這種情況下對簡化版本做出的假設有多少會失敗。

所以我想通過不同層次的事情，可能需要改變，並使估計範圍 - 呃，至多，它可能已經接近工作，但這是可疑的。而最糟糕的是，還有一大堆東西需要改變。所以，我告訴我的老闆，這可能是最好的，因爲規範非常複雜，儘管不知道任何複雜性，但我懷疑由於程序中缺少相關的代碼，幾乎沒有這種複雜性實際上已經實施最後，我說得對 - 所需的修改相當複雜，他們將項目外包給了一個在H.264隔行編碼複雜性方面擁有更多專業知識的承包商。

Answer 7

我最近在讀Agile Estimating and Planning，不能推薦它。

Answer 8

如果我被迫提供估計沒有足夠的時間來正確調查目前的問題，我傾向於大量高估。解決辦法幾乎總是比我想象的要困難得多。如果我認爲某件事需要一天，那麼我說兩天。如果我說一件事需要一個小時，那麼我說一天。我試圖用這些評論來說明的是，除了拼寫錯誤等最平凡的任務之外，即使是一小段代碼改變也可能爆發一整天。對於我認爲可能需要一天或更多時間的任何事情，我估計會翻倍。我知道這樣做可能很困難。管理層希望小數目。您希望在其他開發人員面前顯得聰明而且有能力。另見Scotty Factory。

即使您有質量檢查小組成員會測試您的代碼，您也必須記住測試代碼也是您的工作。確保將其納入任何估算。這是我看到很多開發者忽略了他們的估算過程。

Answer 9

如果你真的需要很快估計，你可以做任務分解結構，每個任務爲1-2天或更小，並且在估計每個任務之後，通過提供最小和最大估計值。

最小值和最大值之和指定整個任務的時間間隔。這給你的老闆提供了有關風險的信息，這總是非常有用。

您將獲得一些間隔，例如， 12-15天或5-30天 - 這比16天更有用，而不是提到的間隔。

這對Steve McConnel Software Estimation: Demystifying the Black Art的好書很有用。

Answer 10

我通常把任務分解成幾塊，但我不估計這些事情的時間小於半天。只要在故障後至少有5或6個元件出現故障，我發現大多數情況下這些故障是平衡的（有些任務需要一個小時以上）

當然，最小時間分割和某些舒適程度所需的件數需要根據問題領域而有所不同 - 至少有5或6個半天塊似乎對我最近被問到的東西來說是正確的，但需要每隔幾個月。

當我要求代表其他人的估計，我抗拒了一點，遵循類似的做法慷慨填充系統（「雙和添加X」上述可能是一個很好的近似）

Answer 11

因素＃1是未知數，你是對的，你不能全部瞭解它們。但是，你通常會知道當時沒有人能爲你回答的一些主要問題。

因素＃2是手頭工具和資源的感知難度和可用性。

---

結果=大約一倍你估計

Answer 12

• 分解任務分成部分和時間

• 工作中的不低於1/2，每天單位分配給每個部分。這將防止微調度

• 項目估計的大問題是低估。如果您知道任務很好，幾乎可以看到代碼，則可以將任務加權爲1.如果存在某種不確定性或任務需要未知技術，則根據不確定性等級將其乘以更高的係數

• 不要太擔心每個部分的準確性。這些錯誤往往會抵消爲真正重要的事情就是總工期

總是有采取樂觀的時間尺度，並通過PI乘以它好老待命。比其應該更頻繁地工作！

Answer 13

除了必要的細節之外，我從語用程序員那裏得到的建議是在數週內表達15天以上的估計值，並估計數月後的8周以上;以便該單位反映估算的準確性。在30周內要非常小心。

您也可以根據您已經完成的類似任務進行估算。

Answer 14

要大小的正確順序估計，你需要：

• 沒有引進新的技術或框架想要的功能;
• 分離純開發時間和開發人員（以及客戶和可用性測試你的估計..;在安全的估計範圍
• 大小功能（不是2倍;
• 得到你早先估計的反饋大2倍多的人）
• 穩定的開發團隊。
• 沒有項目啓動開銷。
• 來的工作時間只有估計你做你自己。

Answer 15

想想一個數字，加倍然後再加倍（即第一個數字是你頭上的第一個數字的四倍）

當一個老闆說「完成一個項目需要多長時間」，他意味着它完成並部署到用戶的時間。程序員將（自然而然地）只考慮完成編程所需的時間（物理輸出問題解決方案的時間），因此通常會低估。

經驗法則是：

「第一號」是你認爲它會帶你完成基於剛纔描述的任務範圍任務的天數。 （當然，你還沒有被告知過任何事情）。

，第一多是給老闆的第一演示/樣機後重新編碼所需的額外的時間，他說「好，太好了。但你能添加...」

第二多的是時間需要重新編碼recode達到正確的生產標準。

第三個時間是測試的時間，文檔&部署和所有其他管理員的東西，你需要做的，以實際獲得的東西出來和生活。

而第四個倍數是你的上述意外事件。

這應該給你一個安全的估計。當然，你應該堅持更徹底的計劃和估計工作。

Answer 16

我相信答案總是「六至八週」。

Answer 17

「六到八週」工作得很好，另外一個工作原理是基於數據模型。

想象一下，應用程序需要的數據庫表（或類似的）的數量，乘以你需要爲每個表編碼模型，CRUD，UI等等的天數，並且將30％到50％的最重要的是時間。