冲刺长度 - 2周vs 30天

Question

我想实现Scrum，但我不能决定Sprint的长度。 Ken Schwaber似乎将这30天与事实相关......但我无法想象在没有改变方向或重新优先权的情况下等待30天。

我们的项目通常只使用瀑布式方法持续1-3个月，而转向Scrum可能意味着更少的微调机会。

我在考虑一周的冲刺，但这看起来像是Scrum Micro Management。

有2周的冲刺可能是理想的，但我想知道其他人是否能够成功实施。有什么缺点？是否需要更多的工作/更少的工作/相同的工作来管理一个短冲刺的团队？

顺便说一句......对我来说，3周冲刺似乎很奇怪，谁进行了为期3周的冲刺？为什么不把它做4周。 ;）

Answer 1

我参加过一周，两周和四周短跑的团队。这真的取决于您的组织。我更喜欢1或2周的短跑。我正在运行的现有团队正在进行为期4周的冲刺，因为我们正在协调12种不同产品的工作。我希望很快将它们转移到2周的迭代次数。

定义长度的关键是“完成，完成”。对于一些团队来说，这意味着在生产中。对于其他人而言，它可能意味着业务部门使用内部版本来满足他们的需求。我首先定义完成，完成，然后看看如何构建你的sprint。理想情况下，所有故事都在冲刺结束时完成 - 而且您不仅仅是在做Scrummerfall。

Answer 2

我喜欢两个星期。它会对问题施加合理的时间限制，让您以更快的速度看待结果。 30天是永远的。对于像网站这样快速移动的产品，一周可能很容易成为正确的节奏。

Answer 3

我参加了1,2,3和4周的短跑。 1周冲刺太短，无法完成团队承诺，2制造是理想的，当我尝试实施3或4周冲刺时，我们无法有效利用QA团队。 （QA将在第一周有更多的闲置时间）

Answer 4

产品所有者应该总是有机会更改优先顺序和方向。 SCRUM的目的之一是通过查看负责按时交付的业务需求和开发团队来接受变更并让产品所有者负责优先级。

所以，即使你有一个为期3周的冲刺，也不知道产品所有者必须等待3周，如果他发现某些事情（可能）会打破冲刺。

在极少数情况下，由于新信息或新的优先权，您必须在中间停止冲刺并创建新冲刺。

Answer 5

  

我在考虑一周的冲刺，但这看起来像是Scrum Micro Management。

是的，但这会让你做更多的Scrum：你会每周做一个sprint计划，一个迭代演示和一个回顾展。缺点是开销，但是，与一个月的迭代相比，您花费更少的时间来规划，演示和“重新审视”一周的迭代。

迭代越短，团队学习过程的速度就越快。

现在，根据项目的类型，可能很难在一周的延迟中获得有价值的东西。

在我忘记之前，我没有做三周的迭代：o）

如果您进行四周的迭代，您还可以使用估计相同时间的任务替换尚未启动的任务 。

Answer 6

2周（10个标准工作日，如果你是M-F服装，或者如果你是M-S服装则是12个）是半个月（一个月通常有大约20个工作日，给予或服用）。此外，周比一天更模糊，但比月份更模糊，因此它使得测量单位在几周内变得更加灵活（更多给予/接受）开发项目。

然而，上次我做了scrum之类的事情，那是在一个学校项目上，并不是真正的scrum。所以这是10周内的7天周。对于那种情况，我真的很喜欢2周的区块。我觉得我可以做很多工作，但我们可以经常调整时间表和计划。

Answer 7

现在我们正在进行30天的冲刺，并完成桩。 30天冲刺对我们运作良好的一个原因是我们的计划和估计通常需要2天（收集和决定从积压的高级任务，承担高级别任务并分解它们，对分解的估计进行估算）任务，然后分配它们）。我们还预留了2-3天的bug修复和测试。

我们已经在那里工作了5天，因此进行为期2周的冲刺只会给我们留下5天的R＆amp; D.到目前为止，30天对我们来说是一个很好的平衡。

Answer 8

Sprint长度可能因项目而异，但在整个同一项目中应保持不变。最好的办法是为你的团队找到最舒适的冲刺长度，我已经使用Scrum两年了，现在我们已经安排了20个工作日的冲刺。

我的经验告诉我，在需要快速交付和相对简单的编程（CRUD操作，简单的网格和表格等）的项目中，更短的冲刺，比如两周，更明智。对于复杂度较高的事情（比如框架），可能最好选择更长的冲刺，例如四周冲刺。我目前的项目倾向于最后一个选项。

但重要的是选择适合团队和产品所有者的长度。