Scrum和Story Points - 为什么理想的人日不理想的工时？

Question

我习惯于按照Joel Spolsky建议的方式考虑时间估计 - 如果预定项目需要超过16小时，则应将其分成较小的任务。现在，我正在我的团队中实施Scrum以及基于Story Points的估算。在我看来，一个故事点的好单位将是理想的工时，而不是人日。如果我用了几天，我的大多数问题都会有1/2或1的估计值。

你有什么想法，为什么在Scrum文献中最常提到使用理想的人日？

Answer 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，这不是一件坏事（至少不是最重要的）。但是不要忘记Scrum中理论上有两个级别的估算：产品Backlog级别，以点为单位，以及Sprint Backlog级别，以小时为单位。正如我在前一段中所提到的，PBI由任务组成，在Sprint计划会议的第二部分中它们应分成任务。然后以小时为单位估算任务，此处适用16h规则：任务不应超过16小时。如果确实如此，那就太大了，应该分成更小的任务（因为我们在评估大事时太糟糕了）。

  

你有什么想法，为什么在Scrum文献中最常提到使用理想的人日？

无论如何这已经过时了。事情可能会在未来发生变化，但目前的共识是以无单位估算。点与任何时间单位完全去相关，这是为了避免与现实世界单位进行任何映射，工作量应该用速度来衡量（团队在一次迭代中可以达到的点数）。

Answer 2

在小时级别估算太精细了。它也倾向于推动微观管理，这与敏捷原则有点对立。

如果我有四个任务，每个估计在半天，我可以相对确信在两天内我会很好地处理它们。

但是16个1小时的任务？我对那些在同一时期完成的工作缺乏信心，因为任何一项任务都会受到太大的变化。

Answer 3

故事点和估计游戏的目的一般是有效地判断几个短跑的速度。

因此，只要团队中的每个人都以相同的方式估算，并且在每个估算会话中使用相同的单位，那么用于估算的单位实际上并不重要。

确保不同的团队不尝试关联他们的故事点也非常重要。我认为的故事点不一定是你的故事。

所以 - 除了“选择合适的东西”之外，我无法提供答案。

Answer 4

• 谷歌搜索“scrum ideal man hour”给出6500个结果，而“scrum ideal man day”给出10000个结果。没那么大的区别。我没有注意到文献中的偏见。

• 在不到半天（最短任务持续时间）甚至一周（最短冲刺持续时间）内，很少有真正有价值的东西很少完成。

• 以小时计算估算可能会产生错误的准确性。即使5个理想的工时是精确的，但它可能不会比0.5理想工时更准确。

• 理想的人类单位也传达了映射到现实世界类似单位的概念，例如小时或天。映射很少直截了当。这就是为什么许多敏捷专家更喜欢无单元的故事点作为任务大小的衡量标准。团队速度指标然后执行从抽象大小估计到现实世界时间的映射。

Answer 5

如果你正在遵循适当的敏捷实践，完整的单元测试覆盖率和红绿重构周期，那么有一小部分有意义的任务将花费不到半天。此外，使用天数抵消了开发人员低估任务所需时间的倾向。当然，最好高估时间和超额交付，而不是低估和低交付。

Answer 6

我不知道，但我准备推测这是因为“标准”scrum长度为30天。如果你计划在30天内完成工作，那么你需要比你的短跑长度为1或2周更粗略的测量单位。

我见过的大多数scrum实现的弹簧长度为1或2周 - 所以计算“理想小时”更有用，因为相对任务大小更小。

就相关的努力量衡量而假设您正在使用scrum开发软件时，我计算单独源代码提交的数量，您可以如果你干净地开发了每项任务并将其作为一种衡量标准。