我习惯于按照 Joel Spolsky 建议的方式来考虑时间估算 - 如果计划的项目需要超过 16 小时，则应将其划分为更小的任务。现在，我正在我的团队中实施 Scrum 以及基于故事点的估计。在我看来，故事点的一个好的单位将是理想的工时，而不是工时。如果我使用天数，我的大多数问题都会估计为 1/2 或 1。
您有什么想法，为什么在 Scrum 文献中最常提到使用理想的工日？
【问题讨论】：
标签： agile scrum estimation time-estimation
我不知道，但我准备推测这是因为“标准”scrum 长度是 30 天。如果您计划以 30 天为单位完成工作，那么您将需要比 1 或 2 周的 sprint 长度更粗略的度量单位。
我见过的大多数 scrum 实施的弹簧长度为 1 或 2 周 - 因此计算 “理想时间”更有用，因为相对任务规模更小。
就相对的工作量衡量而言，假设您使用 scrum 开发软件，我会计算单独源代码提交的数量，您可以如果您干净利落地开发每项任务并将其用作衡量标准，那么就做出来。
【讨论】：
故事点和估算游戏的目的通常是有效地判断几个冲刺的速度。
因此，使用什么单位进行估算实际上并不重要，只要团队中的每个人都以相同的方式进行估算，并且在每个估算会话中使用相同的单位即可。
确保不同的团队不试图关联他们的故事点也很重要。我认为的故事点不一定是你的。
所以 - 除了“选择看起来合适的东西”之外，我无法提供其他答案。
【讨论】：
在小时级别的估算过于细化。它还会导致过度的微观管理，这在某种程度上与敏捷原则背道而驰。
如果我有四个任务，每个任务估计半天，我可以相对自信地在两天内完成。
但是 16 个 1 小时的任务？我对在同一时间段内完成的任务没有信心，因为任何一项任务都存在太多的可变性。
【讨论】：
在我看来，故事点的一个好的单位应该是理想的工时，而不是工时。
这句话听起来真的，真的很奇怪，而且不是真的。您从哪里了解到故事点数和理想的工时之间存在相关性？ 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 文献中最常提到使用理想的工日？
无论如何，这已经过时了。未来情况可能会发生变化，但目前的共识是用无单位点进行估计。点与任何时间单位完全去相关，这是为了避免与现实世界单位的任何映射，工作能力应该用速度（团队在一次迭代中可以达到的点数）来衡量。
【讨论】：
谷歌搜索“scrum 理想工时”会得到 6500 个结果，而“scrum 理想工时”会得到 10000 个结果。没有那么大的区别。我没有注意到文献中的任何一种偏见。
真正有价值的事情很少在不到半天（最短任务持续时间）甚至一周（最短冲刺持续时间）内完成。
以小时为单位进行估算可能会产生错误的准确感。尽管 5 个理想工时是精确的，但它可能并不比 0.5 个理想工时更准确。
理想的人单位还传达了映射到现实世界中类似单位（例如小时或天）的概念。映射很少是直截了当的。这就是为什么许多敏捷专家更喜欢无单位的故事点作为任务大小的衡量标准。团队速度指标然后将抽象规模估计映射到现实世界时间。
【讨论】：
如果您遵循正确的敏捷实践，具有完整的单元测试覆盖率和红-绿-重构周期，那么只需不到半天的时间就可以完成少量有意义的任务。此外，使用天数可以抵消开发人员低估任务所需时间的倾向。当然，高估时间和过度交付比低估和交付不足要好。
【讨论】：