你應該在估算任務時走多遠？

Question

什麼時候使用估計任務的時間很好的解決方案？

它是不是像0.5,1,2,5天，或者你應該下降到0.5,1,2,4小時，然後繼續幾天？

對標籤文本的更改應該是任務嗎？ （ETA < 1min）

建議？

Answer 1

Scrum使用0,0.5,1,2,3,5,8,13,20,40和100的值。當您計劃更精細的細節時（細分功能請求），值的時間以小時爲單位技術門票）和日子，當你計劃更大的圖片（大圖片功能）。

一般來說，如果你估計一張票超過20小時（或20天），你的任務應該分成更小的部分。

Answer 2

嗯，這真的取決於。就我個人而言，我喜歡將任務縮小（應該以小時估計，通常使用接近斐波那契數列的東西：0.5,1,2,3,5,8，...）。

關於小任務，通常他們也應該被估計。即使是很小的變化，也需要做一些工作，比如創建測試，看看其他人是否打破了，發送到服務器等等。你可以在這個系列中創建一個15分鐘的類似這樣的東西:)

Answer 3

真的很難預測未來。

單位（分鐘，小時，天，周，晚）無關緊要。

選擇一個讓你的經理開心的單位。

只需要清楚，估計30分鐘，0.5小時或.0625天只是一個猜測，而不是事實。

估計0.0625天或30分鐘看起來非常精確，因爲它有很多小數位。然而，關於需求，體系結構，語言，庫，單元測試或其他任何內容的任何歧義都會使這個數字不正確。

您可以期待的最好的結果是，您所有估算的平均值與其展開時的實際情況相當接近。這意味着你估計的一半太低，一半太高。這也意味着你的估計的一小部分將會真的非常離開你的經理希望的準確性。

Answer 4

我想這取決於你想成爲多麼準確。

我個人使用分鐘作爲「天」或「月」可能是誤導性的時間段。例如，如果你說一件事需要1天 - 這是否意味着24小時堅實的工作？還是8個小時？或者一個工作日內平均3-4小時的生產力？

所有的任務都應該列出來，但是如果它們很小，你可以經常對它們進行分組。但請記住，僅僅因爲它只是改變標籤文本，所以需要更多的時間來改變標籤，你必須找到它，打開文件，進行更改，提交更改，更新任何文檔，測試等等 - 因此任務很少只需要不到1分鐘。

也試着把任務時間的上限。如果您添加了超過3-4小時的任務，請將其分解爲較小的子任務並列出這些任務。這會給你一個更準確的估計。

Answer 5

我發現自己整理任務分爲以下類別：

• 半天
• 全天
• 全周
• 幾個星期

在我的工作環境，我們做了大量的二級支持，擁有更細化的系統是沒有意義的。在計劃中有些鬆懈也是很好的，所以你可以花一個小時對你的工作環境做一些小的改進。

Answer 6

規劃和所需估計時間是不是你的項目的目標，所以這些單位必須服務於某種目的。

使用的好規則是這樣的：將任務分成更小的塊，直到你知道恰好爲接下來你應該做什麼（而不是規劃）。這個「確切地知道該做什麼」的事情有點主觀，但超過2天的任務很少適合這個類別。

Answer 7

我傾向於使用的小時爲單位他們應該是適當的（1H，4.5H，6H，等）。一旦進入等式，我傾向於不使用小時，並將天數保留爲唯一使用的單位（3d，7d，10d）。高估略有餘地，以容納這些不期望但預期的併發症，你會沿途。

Answer 8

工作努力 - 應該花費多長時間才能完成工作 - 以及何時完成工作（也就是持續時間） - 當某些工作預計會根據其他任務完成時有所不同。 。

你永遠無法預知未來，任何EST就是這樣 - 一個EST - 中能1周預測出半小時爲單位的可能性不是很大，如果第6個任務需要5分鐘。更多要完成，你是1/2（工作3小時後）。

我會建議創建一個工作分解結構（WBS）來確定工作量，然後將任務分組到不少於一天的分組和不多於一週的分組（取決於項目的總體持續時間 - 您從不想要一個增量佔整體工作量的2-3％）。這將允許程序在任務（正常工作條件）之間切換，而無需滿足特定的半小時交貨壓力。