我习惯于以 Joel Spolsky 建议的方式来考虑时间估计——如果一个计划项目需要超过 16 个小时，它应该被划分为更小的任务。现在，我正在我的团队中实施 Scrum 以及基于故事点的估计。在我看来，故事点的一个好的单位将是理想的工时，而不是工时。如果我使用天数，我的大多数问题将估计为 1/2 或 1。
你有什么想法，为什么在 Scrum 文献中最常提到使用理想的工日？
问问题
7137 次
6 回答
11
在我看来，故事点的一个好的单位将是理想的工时，而不是工时。
这句话听起来真的，真的很奇怪，而且不是真的。您从哪里了解到故事点数和理想的工时之间存在相关性？Scrum 早期可能使用理想的人工工作日，但对我来说，故事点 (SP) 是另一回事......
故事点是一种量化与由多个任务组成的特定产品待办事项 (PBI) 相关的相对工作量的方法。一些团队使用数字尺寸（即 1 到 10 的比例）来估计 PBI 的“尺寸”，其他使用 T 恤尺寸（XS、S、M、L、XL、XXL、XXXL），一些使用斐波那契序列（1、2、3、5、8、13、21、34 等）。顺便说一句，您是否注意到 SP 是无单位的？
如果我使用天数，我的大多数问题将估计为 1/2 或 1。
所以呢？那只是意味着您拥有小型 PBI，这不是一件坏事（至少对于最重要的 PBI 而言不是）。但不要忘记，Scrum 中理论上有两个估算级别：Product Backlog 级别（以点为单位）和 Sprint Backlog 级别（以小时为单位）。正如我在上一段中提到的，PBI 是由任务组成的，它们应该在 Sprint 计划会议的第二部分中拆分为任务。然后以小时为单位估算任务，此处适用 16 小时规则：任务不应超过 16 小时。如果是这样，它太大了，应该分成更小的任务（因为我们在估计大事情方面太糟糕了）。
你有什么想法，为什么在 Scrum 文献中最常提到使用理想的工日？
无论如何，这已经过时了。未来情况可能会发生变化，但目前的共识是用无单位点进行估计。点与任何时间单位完全去相关，这是为了避免与现实世界单位的任何映射，工作能力应该用速度（团队在一次迭代中可以达到的点数）来衡量。
于 2009-12-11T09:53:39.750 回答
2
在小时级别进行估算过于细粒度。它也将趋向于过度微观管理，这在某种程度上与敏捷原则背道而驰。
如果我有四个任务，每个任务估计半天，我可以比较有信心在两天内搞定。
但是 16 个 1 小时的任务？我对在同一时间段内完成的那些任务的信心要小得多，因为任何一项任务都有太多的可变性。
于 2009-12-11T09:58:06.390 回答
2
一般来说，故事点和估算游戏的目的是有效地判断几个冲刺的速度。
因此，使用什么单位进行估算实际上并不重要，只要团队中的每个人都以相同的方式进行估算，并且在每个估算会话中使用相同的单位。
确保不同的团队不会试图关联他们的故事点也很重要。我认为的故事点不一定是你的。
所以 - 除了“选择看起来合适的东西”之外，我无法提供答案。
于 2009-12-11T10:07:08.207 回答
1
谷歌搜索“scrum 理想工时”给出 6500 个结果，而“scrum 理想工时”给出 10000 个结果。没有那么大的区别。我没有注意到文献中对任何一个都有偏见。
在不到半天（最短任务持续时间）甚至一周（最短 sprint 持续时间）内，很少能完成真正有价值的事情。
以小时为单位进行估算可能会产生错误的准确性感。尽管 5 个理想工时是精确的，但它可能并不比 0.5 个理想工时更准确。
理想的人员单位还传达了映射到现实世界中类似单位（例如小时或天）的概念。映射很少是直截了当的。这就是为什么许多敏捷者更喜欢无单位的故事点作为任务大小的衡量标准。团队速度度量然后将抽象规模估计映射到现实世界时间。
于 2009-12-11T09:23:42.217 回答
0
如果您遵循正确的敏捷实践，具有完整的单元测试覆盖率和红-绿-重构周期，那么有意义的任务数量将非常少，只需不到半天的时间。此外，使用天数可以抵消开发人员低估任务所需时间的倾向。当然，高估时间和过度交付比低估和交付不足要好。
于 2009-12-11T09:20:45.280 回答
0
我不知道，但我准备推测这是因为“标准”scrum 长度是 30 天。如果您计划以 30 天为一组进行工作，那么您将需要比 sprint 长度为 1 或 2 周时更粗略的度量单位。
我见过的大多数 scrum 实现的弹簧长度为 1 或 2 周——因此计算“理想时间”更有用，因为相对任务规模更小。
就工作量的相对衡量而言，假设您使用 scrum 开发软件，我会计算如果您干净地开发每个任务并将其用作衡量标准，您可以进行的单独源代码提交的数量。
于 2009-12-11T12:25:47.413 回答