0

我们是一个由 3 名开发人员组成的小组，他们使用 Scrum 在一个项目上工作。

我们使用6 小时/天/开发人员进行容量规划。我的问题是 - 如果我们使用 2 周的 Sprint 并且一天中的大部分时间（5-6 小时）都在做 Sprint 计划，我们是否应该将这段时间视为迭代的一部分（也就是说，这就是我们使用6 小时/天的原因考虑这样的事情）。

对我来说，这超出了容量规划，因为6 小时/天/开发只是为了说明开发人员每天做的正常事情的生产时间......

4

4 回答 4

2

您应该根据故事进行容量规划。这周你能写多少个故事？通过这种方式，您不需要考虑计划，因为它不是一个故事。

如果您的故事的大小如此不同，以至于如果不考虑它就无法真正进行明智的计划：

  • 以任意“点”估计故事（基本上将它们按比例排列）（好）

或者

  • 打破你的故事，让它们都变得同样小（更好）

无论哪种情况，您都不需要考虑任何地方的计划。

于 2013-10-23T14:05:25.017 回答
1

在 sprint 迭代中不应考虑 Sprint 计划时间。但冲刺计划应该在 2-3 小时内完成，而不是一整天都完成。既然你说你的团队只有 3 人，那么理想的 sprint 计划应该在这段时间内完成。因此，一天中的剩余时间仍可用于 sprint 任务。

于 2013-10-24T16:19:27.087 回答
1

我尝试了一些不同的方法，但以下是最适合我的理想：

  • 将开发工作视为“闭门造车”成本：如果她从不被电子邮件、会议、电话、午餐、啤酒跑等分心，需要多长时间。
  • 为您的团队确定“闭门造车”成本与现实生活之间的比率。在“闭门造车”中进行计划（开发人员更容易估计）并使用历史来确定比率。这也允许您尝试降低比率（免费苏打水/午餐递送、上午 10 点到下午 4 点之间的电子邮件过滤器等）
  • 将冲刺视为一整天的计划、稳定和审查。因此，对于两周的冲刺，将第 1 天用于计划，第 9 天用于稳定，第 10 天用于审查/回顾。

因此，如果您有 5 个开发人员在为期两周的 sprint 中每天工作 8 小时，并且您计算出您的关门/开门比率为 1.5，那么您有5.33 个关门时间 * 5 个开发人员 * 7 天 = 186.6 小时的工作时间计划。

如果您有一个强大的 SCRUM 主管（或其他流程领导者）并推动您的团队对“完成”有一个完整的定义（即记录、测试、伙伴构建和集成测试），那么您将不需要稳定日，但是到达那里需要一些努力。

这种混合过程的好处是，您可以使用开/关比率来了解每个开发人员的工作习惯（有些人是很好的估计器，比率为 1，有些人对一切都很悲观，可能比率低于 1）。

于 2013-10-25T19:40:48.790 回答
0

不，您不应该将 sprint 计划视为 sprint 迭代的一部分。

在计算开发团队的能力时，不考虑团队在 sprint 计划中花费的时间，因为在这次会议上花费的时间对故事的开发没有贡献。

于 2013-10-23T20:39:04.547 回答