我们是一个由 3 名开发人员组成的小组,他们使用 Scrum 在一个项目上工作。
我们使用6 小时/天/开发人员进行容量规划。我的问题是 - 如果我们使用 2 周的 Sprint 并且一天中的大部分时间(5-6 小时)都在做 Sprint 计划,我们是否应该将这段时间视为迭代的一部分(也就是说,这就是我们使用6 小时/天的原因考虑这样的事情)。
对我来说,这超出了容量规划,因为6 小时/天/开发只是为了说明开发人员每天做的正常事情的生产时间......
我们是一个由 3 名开发人员组成的小组,他们使用 Scrum 在一个项目上工作。
我们使用6 小时/天/开发人员进行容量规划。我的问题是 - 如果我们使用 2 周的 Sprint 并且一天中的大部分时间(5-6 小时)都在做 Sprint 计划,我们是否应该将这段时间视为迭代的一部分(也就是说,这就是我们使用6 小时/天的原因考虑这样的事情)。
对我来说,这超出了容量规划,因为6 小时/天/开发只是为了说明开发人员每天做的正常事情的生产时间......
您应该根据故事进行容量规划。这周你能写多少个故事?通过这种方式,您不需要考虑计划,因为它不是一个故事。
如果您的故事的大小如此不同,以至于如果不考虑它就无法真正进行明智的计划:
或者
无论哪种情况,您都不需要考虑任何地方的计划。
在 sprint 迭代中不应考虑 Sprint 计划时间。但冲刺计划应该在 2-3 小时内完成,而不是一整天都完成。既然你说你的团队只有 3 人,那么理想的 sprint 计划应该在这段时间内完成。因此,一天中的剩余时间仍可用于 sprint 任务。
我尝试了一些不同的方法,但以下是最适合我的理想:
因此,如果您有 5 个开发人员在为期两周的 sprint 中每天工作 8 小时,并且您计算出您的关门/开门比率为 1.5,那么您有5.33 个关门时间 * 5 个开发人员 * 7 天 = 186.6 小时的工作时间计划。
如果您有一个强大的 SCRUM 主管(或其他流程领导者)并推动您的团队对“完成”有一个完整的定义(即记录、测试、伙伴构建和集成测试),那么您将不需要稳定日,但是到达那里需要一些努力。
这种混合过程的好处是,您可以使用开/关比率来了解每个开发人员的工作习惯(有些人是很好的估计器,比率为 1,有些人对一切都很悲观,可能比率低于 1)。
不,您不应该将 sprint 计划视为 sprint 迭代的一部分。
在计算开发团队的能力时,不考虑团队在 sprint 计划中花费的时间,因为在这次会议上花费的时间对故事的开发没有贡献。