1

我知道最佳冲刺长度会因情况/公司而异。话虽这么说,有没有人成功使用灵活的冲刺长度?另外,我想知道是否有人对短(1 周)与长冲刺有强烈的看法?

背景:我们目前使用 1 周的冲刺进行开发。我们的产品负责人似乎对此很满意;但是,为了灵活起见,我曾多次要求增加某些项目的 sprint 长度。在所有情况下,我们都坚持短冲刺。

4

2 回答 2

3

像往常一样:这取决于。

我目前在一个冲刺周期在两到四个星期之间变化的组织中。我个人对此并不热衷,因为很难衡量速度,而且对于组织的其他成员来说,将他们的日程安排与开发团队相匹配也很棘手。

另一方面,这确实意味着很少有故事会延续到下一个 sprint,我们可以更轻松地考虑缺席、意外错误等 - 这通常会导致 sprint 被彻底取消。

我参与过尝试过一周冲刺的团队。在实践中,与 sprint 计划、测试计划、部署等相关的开销意味着我们最终需要大约两天的实际开发时间:因此很难完成大型战略工作。我相信团队现在使用看板工作,根本没有固定的 sprint 持续时间,因此更快乐。

于 2011-11-30T16:31:21.697 回答
1

我们确定每个项目的 sprint 长度。如果我们正在运行一个将持续 3-4 周的小项目,运行为期一周的 sprint 在那里没有任何意义,我们会切换到几乎类似于看板的方法。

如果我们正在运行一个 1 到 2 周之间的长期项目。然而,我们不做的是绝对灵活地设置 sprint 长度,最终它给我们带来了报告混乱。然而,我们所采用的是将 sprint 的长度加倍。不是为了完成零散的任务,而是为了完成两个 sprint 加载,而不必解释我们为什么要重新安排内容。我们仍然尽可能避免这种情况。

于 2011-11-30T16:27:41.153 回答