用于估算任务持续时间的最佳时间分辨率是多少？
是 0.5、1、2、5 天还是应该减少到 0.5、1、2、4 小时，然后再持续到几天？
更改标签文本是否应该成为任务？（预计到达时间 < 1 分钟）
建议？
问问题
436 次
8 回答
3
Scrum 使用 0、0.5、1、2、3、5、8、13、20、40 和 100 的值。这些值的时间以小时为单位，当您计划更详细时（将功能请求分解为技术工单）和天，当您计划更大的图景（大图功能）时。
一般来说，如果你估计一张票超过 20 小时（或 20 天），你的任务应该被分成更小的部分。
于 2009-07-27T11:52:51.730 回答
2
好吧，这真的取决于。就个人而言，我喜欢更小的任务（应该以小时为单位估计，通常使用接近斐波那契数列的东西：0.5、1、2、3、5、8，...）。
关于小任务，通常也应该估计。即使是很小的更改也需要一些工作，例如创建测试，查看其他测试是否损坏，发送到服务器等。您可以在系列中为这些内容创建 15 分钟 :)
于 2009-07-27T11:55:11.133 回答
2
未来真的很难预测。
单位（分钟、小时、天、周、两周）无关紧要。
选择一个让你的经理满意的单位。
请注意，30 分钟、0.5 小时或 0.0625 天的估计只是猜测，而不是事实。
0.0625 天或 30 分钟的估计值看起来非常精确，因为它有很多小数位。然而，任何关于需求、架构、语言、库、单元测试或其他任何方面的歧义都会使这个数字不正确。
你所能期望的最好的结果是，所有估计的平均值在它们展开时都相当接近实际事实。这意味着一半的估计值太低，一半的估计值太高。这也意味着你的估计中的一部分将与你的经理所希望的准确度相去甚远。
于 2009-07-27T11:55:41.380 回答
1
计划和估计所需时间绝不是您项目的目标，因此这些单元必须服务于某些目的。
使用的好规则是：将任务分成更小的块，直到您确切知道下一步应该做什么（并且它没有计划）。这种“确切地知道该做什么”的事情有点主观，但超过 2 天的任务很少属于这一类。
于 2009-07-27T13:46:39.713 回答
0
我想这取决于你想要的准确度。
我个人使用分钟作为“天”或“月”可能会误导时间段。例如，如果您说某事需要 1 天 - 这是否意味着 24 小时扎实工作？还是8小时？或者一个工作日内平均 3-4 小时的生产力？
应列出所有任务，但如果它们很小，您通常可以将它们分组。但请记住，仅仅因为它只是更改标签文本，所以涉及更多时间，而只是更改标签，您必须找到它，打开文件，进行更改，提交更改，更新任何文档，测试它等等 - 所以任务很少只需要不到 1 分钟。
还要尝试设置任务时间的上限。如果您添加的任务超过 3-4 小时，请将它们分解为更小的子任务并列出。这会给你一个更准确的估计。
于 2009-07-27T11:59:16.897 回答
0
我发现自己将任务分为以下几类：
- 半天
- 一整天
- 整整一个星期
- 几个星期
在我做大量二级支持的工作环境中，拥有更细粒度的系统是没有意义的。在计划中稍作懈怠也是很好的，这样您就可以花一个小时对您的工作环境进行一些小的改进。
于 2009-07-27T13:03:17.553 回答
0
如果合适的话，我倾向于使用小时单位（1 小时、4.5 小时、6 小时等）。一旦天数逐渐进入等式，那么我倾向于不使用小时数，而是将天数作为唯一使用的单位（3d、7d、10d）。稍微高估会为您在此过程中遇到的那些不希望但预期的并发症留出空间。
于 2009-07-27T14:20:02.057 回答
0
est. work effort - 完成某件事需要多长时间 - 和 est. 什么时候完成（又名持续时间） - 什么时候预计根据其他任务完成某事。
你永远无法预测未来，任何估计都只是 - 一个估计 - 能够以 1/2 小时的增量预测 1 周的可能性不是很大，如果前 6 个任务需要 5 分钟怎么办。更多要完成，您将获得 1/2 的折扣（工作 3 小时后）。
我建议创建一个工作分解结构 (WBS) 来确定工作量，然后将任务分组为不少于天和不超过周的分组（取决于项目的整体持续时间 - 你永远不希望有一个代表更多的增量然后是整体工作量的 2-3%）。这将允许程序在任务（正常工作条件）之间切换，而无需满足特定的 1/2 小时交付的压力。
于 2009-07-28T12:23:42.967 回答