當被問及估計和/或在閱讀我的同事估計他們經常讀一些這樣的：分配給單個開發任務的可接受時間上限是多少？
我認爲，當單個任務的估計是5個多小時，你應該認真考慮將任務分成更小的子任務。
與像21小時估計的問題是，你可能會失去很多小時沒有管理過不了解它，直到爲時已晚。另外，大的估計值可以是表示任務定義不清。當然這不是一個非常嚴格的規則，因爲很容易理解它的例外。
所以我的問題是：
當我們做計劃時，我們將事情分解成4個小時的任務（最長）。而且，我們只計劃每週工作4天。 （我們的身影，時間休息是採取與會議等）
根據我的經驗，80％的利用率也是一個不錯的數字。我很佩服你的團隊在將事情分解成4個小時的時候的紀律。 :) – 2009-08-19 08:50:17
我在哪裏工作，我們有24小時是最使個人卡可以獲得一個極限。如果不止這一點，它應該被分解成足夠小的塊，以便在日常站立後可以看到移動，否則就會有幾小時內停滯並且可能需要額外資源來解鎖。我個人的偏好是儘量不超過16小時，根據估計所需的小時數，有些卡可能會膨脹，因爲發現了新問題，導致卡片在吞噬大量時間方面變成一種黑洞衝刺。
因爲你已經指出，這需要比X長或許應該被分解成小任務的任務，越小越好，因爲大多數開發人員都在估計真的不好，話說我已經提供了準確的估計3天工作（24小時），但你的團隊可能不同，所以肯定去爲最小可以
如果你跟蹤你的估計/實際歷史，你也許可以通過精確繪製小時，弄清楚到底是什麼號碼是適當的爲你的團隊。
這是一個非常好的建議，我曾嘗試過去做。雖然沒有成功。 1.不幸的是，我沒有直接訪問數字...既不是所有的估計值或註冊時間。 （我不是經理） 2.任務說明和小時註冊是完全獨立的系統，因此它們通常會不同步。因此，如果不是不可能將註冊時間映射到原始估計值，通常很困難。 不幸的是，當我和我的經理討論這些問題時，他們對改進流程似乎並不感興趣。 – JohannesH 2009-08-19 01:04:22
@ JohannesH-謝謝。如果你有興趣，我只是試了一下，並將結果發佈到我的博客上。我不得不說，它並沒有像我想的那樣完全出來。 http://bit.ly/4DaPlq – 2009-08-19 18:58:53
在規劃項目中，我不喜歡任何短於2天的任務。在任何不到一天的時間內進行封頂似乎都是非常嚴格的，因爲這不會解決任何具有重要發現組件的任務。
我們簿6小時的日子，假設其他2個小時就會得到拍攝了會議和其他雜項任務。
這很有趣，我想我們同意。我並不是想要提出一個嚴格的上限估計，我只是認爲最高估計會引發一個問題：「你將如何處理這些時間」。如果你不能細分這樣的高估，那麼它可能有很高的風險。但是，當然你不應該只是爲了達到任意的下限估計而創造子任務，它應該有明確的目的，比如使規範更精確和/或易於管理。在一天結束時，很難在規格過度和規格不足之間取得平衡，我只是很好奇它是如何做到的。 ;） – JohannesH 2009-08-19 00:53:19
我看到兩個觀點：開發者的估計和項目經理的控制。
但從
我不認爲這對設定上限的任務推定規則開發者的角度。至少我不能設置一個適用於我工作的所有項目。
通常，如果任務過於複雜以至於無法估計，那麼通常，規則將打破要小部分估計的任務，或者如果沒有提供其他細節（作爲項目經理，我總是詢問有關估算的詳細信息），估算難以向項目經理/客戶/其他利益相關者證明是合理的。考慮到這些，我們的任務持續時間爲4小時（但從未少於4小時），而且任務持續1周（有時爲2周，但估算基於歷史數據）。
從項目經理的角度來看
我喜歡在周級別的持續時間來管理任務。詳細的子任務任務是一個微觀管理問題（通常是團隊/技術領導者在那裏控制），並將大量的進度跟蹤轉化爲可能的虛假數據。
我投票結束這個問題作爲題外話，因爲它不是關於編程。 – 2017-11-08 09:38:46