用于估算任务持续时间的时间分辨率是多少？
它是0.5,1,2,5天，还是应该像0.5,1,2,4小时一样下降到几个小时，然后再持续几天？
是否应该更改标签文本？ （ETA <1分钟）
建议？
答案 0 :(得分：3)
Scrum使用0,0.5,1,2,3,5,8,13,20,40和100的值。当您计划更精细的细节时，值的时间以小时为单位（将特征请求分解为技术门票）和日子，当你计划更大的图片（大图片功能）。
一般情况下，如果您估计超过20小时（或20天）的机票，您的任务应分成更小的部分。
答案 1 :(得分：2)
嗯，这真的取决于。就个人而言，我喜欢任务要小一些（应该以小时计算，通常使用接近Fibonacci系列的东西：0.5,1,2,3,5,8 ......）。
关于小任务，通常也应该估算它们。即使是微小的变化也需要一些工作，比如创建测试，看看是否其他任何一个都没有破坏，发送到服务器等等。你可以在系列中创建一个15分钟来完成这样的事情：）
答案 2 :(得分：2)
预测未来真的很难。
单位（分钟，小时，天，周，星期四）并不重要。
选择让您的经理满意的单位。
请注意，估计30分钟，0.5小时或.0625天只是猜测，而不是事实。
估计0.0625天或30分钟看起来非常精确，因为它有很多小数位。但是，任何关于需求，体系结构，语言，库，单元测试或其他任何内容的含糊不清都会使这个数字不正确。
您可以期待的最好的是，您所有估计的平均值与他们展开时的实际事实相当接近。这意味着您估计的一半会太低而一半会太高。这也意味着你估计的某些部分确实非常远离你经理所希望的准确性。
答案 3 :(得分：1)
规划和估算所需的时间绝不是您项目的目标，因此这些单位必须达到某种目的。
使用的好规则是：将任务拆分为较小的块，直到您知道完全下一步应该做什么（并且它没有计划）。这种“确切知道该做什么”的事情有点主观，但超过2天的任务很少适合这一类。
答案 4 :(得分：0)
我想这取决于你想要的准确度。
我个人使用分钟作为“天”或“月”可能会误导时间段。例如，如果您说某事需要1天 - 这是否意味着24小时可靠的工作？还是8个小时？或者一个工作日内平均3-4小时的生产力？
应列出所有任务，但如果它们很小，您通常可以将它们分组。但请记住，仅仅因为它只是更改标签文本，所以只需要更改标签就有更多时间，你必须找到它，打开文件，进行更改，提交更改，更新任何文档，测试它等等 - 所以任务很少只需不到1分钟。
还尝试对任务时间设置上限。如果您的添加任务超过3-4个小时，请将其分解为较小的子任务并列出这些任务。这将为您提供更准确的估算。
答案 5 :(得分：0)
我发现自己将任务分类为以下类别：
在我的工作环境中，我们进行了大量的二级支持，拥有更精细的系统是没有意义的。在规划中有一些松懈也是很好的，这样你就可以花一个小时来改善你的工作环境。
答案 6 :(得分：0)
如果适当的话，我倾向于使用小时数（1小时，4.5小时，6小时等）。一旦天进入等式，那么我倾向于不使用小时并且将天数作为唯一使用的单位（3d，7d，10d）。过高估计可以为您提供足够的空间来容纳您在此过程中遇到的不良但预期的并发症。
答案 7 :(得分：0)
est。工作努力之间存在差异 - 完成某事需要多长时间 - 以及什么时候会完成某事（也就是持续时间） - 当预计某些事情会根据其他任务完成时。
你永远无法预测未来，而且任何估计都只是 - 那是 - 能够以半小时为增量预测1周的可能性并不是那么好，如果前6个任务需要怎样5分钟。更多完成，你是1/2关（工作3小时后）。
我建议创建一个工作分解结构（WBS）来确定工作量，然后将任务分组到不少于一天的分组中，而不是每周分组（取决于项目的整体持续时间 - 你永远不想拥有增量占整体工作量的2-3％以上）。这将允许程序在任务之间切换（正常工作条件），而不必承受特定的1/2小时交付的压力。