7

在 Scrum 团队中，在继续之前完成一个故事有多重要？

我们的 Scrum Master 非常教条地在继续之前完成一个故事。我可以看到，在这种情况下，开发似乎更加“受控”，而且 Scrum Master 可以非常准确地了解团队成员在任​​何给定时间的工作内容......但我对这真正购买的东西感兴趣我们？

显然，Scrum Master 希望尽量减少燃尽与现实的差异，以避免冲刺结束时的冲击——但如果冲刺持续两周，燃尽会持续更新，并且在站立会议上传达阻碍者——任何这样的分歧都会受 sprint 长度的限制，并通过通常的渠道（即站立或单独与 scrum master 交谈）在 sprint 中期可见。任何剩余的问题都可以在每两周一次的回顾中处理。

提出这个问题的原因是，我似乎发现我的工作效率最高，方法是在我认为合适的任何给定时间保持说 2 个（或 3 个，如果一个特别容易的话）故事在进行中。这似乎有助于帮助完成任务的潜意识背景思想。如果有几个故事相关，它还可以让我更好地理解大局。

我们的故事通常需要一两天的工作量。

那么，一次处理几个故事是否令人不悦，如果是这样，一次一个故事会给你带来什么？

4

5 回答 5

4

我认为这真的取决于团队来决定。我认为你在关于燃尽的文章中提到了这一点，最重要的是始终如一地履行你的冲刺承诺。如果他们真的是自治的，那么真正如何发生这种情况应该取决于团队。我现在的团队，我们的标准是同时处理多个故事；这是我们设置的性质，因为我们试图在整个团队中真正传播故事的所有权。如果您有更短的故事和更多的个人所有权风格，这对您来说可能是一个不同的规范。

于 2010-02-18T03:35:57.740 回答
3

我个人认为一次一个故事效果很好，因为它可以让你专注于一项任务。多个故事之间的上下文切换成本可能很高。这对我来说是个人喜好，但不同的人工作方式不同。尽管我认为您的 Scrum Master 的方法论是正确的，但如果您一次找到多个故事的非常有说服力的理由，并且可以证明它实际上有助于进步，那将是一个很好的案例。

于 2010-02-18T03:06:39.627 回答
1

IMO，这里有一个潜在的问题。有时在处理一个故事时，我需要来自另一个部门/团队的东西，例如对需求的澄清或页面的图形，这意味着我不会在继续一个故事之前完成一个故事。虽然您在站立会议上讨论阻碍者时确实提到了这一点，但这种情况可能会发生在由外面的人帮助我完成一个故事的情况下，这样我的盘子上可能会有多个。因此，我可以有多个故事，因为我被某些东西挡住了，但仍然想要有成效。

一般来说，我不喜欢尝试管理代码库的多个副本或频繁切换我的代码，所以我更喜欢一次只做一个故事，假设没有障碍。我正在使用的代码库的大小约为 1.1 GB 的数据，分布在 82,000 多个文件中，因此拥有多个副本可能会比我想象的更痛苦。

我个人对此的猜测是，由团队来设定标准并确保它对他们有用。如果有人一次喜欢一个故事，而另一些人喜欢多个，那么一切都很好，很酷。如果每个人都喜欢在不同的完成点有多个故事，那也可以。

于 2010-02-18T15:02:54.840 回答
0

不要占用积压... 根据我的经验，当故事的大小在 1 到 2 天之间时，它们往往由单个开发人员实现。如果您同时工作 2 或 3 个故事，这可能会减少其他开发人员可以从中挑选的积压工作的数量并危及 sprint。

...但要做好阻塞计划 另一方面，同时工作 2 或 3 个故事意味着如果您在一个故事上暂时受阻，您可以立即在另一个故事上工作。我发现每次开始一个新故事时都会有一些开销。这种开销使我很难在一天中用一个新故事填补一个小时的“空白”，而将上下文切换到我已经开始的故事要容易得多。

最重要的是，让团队决定……然后在回顾中审查结果。如果您的故事、任务和工作流程支持团队成员一次可以处理 2 个（也许 3 个）故事而不牺牲生产力或可预测性的环境，那么您的 SM 应该尊重这一点。但与此同时，您应该在每次回顾期间诚实地审查结果，并准备好在 SM 认为它不起作用时进行更改。

于 2010-02-19T15:40:30.057 回答
0

我通常认为如何最好地工作的决定应该几乎完全由团队做出。ScrumMaster 的角色是帮助和支持团队，而不是在 sprint 期间质疑团队的工作方式。

公平地说，有时让 ScrumMaster 指出可能的缺陷或风险是个好主意——这属于“帮助和支持”的范畴。对你个人关于 sprint 内部应该是什么样子的想法持教条主义的态度并不是我希望 ScrumMaster 表现的那样。这听起来有点像将角色误解为经理的角色，事实并非如此。

至于我们是如何做到的：我们几乎总是同时处理多个故事。目前，我们有一个由三名开发人员和一名测试员组成的四人 Scrum 团队，而且我们几乎总是同时有至少两三个故事。在上一个 sprint 中，我们试图从 sprint 早期的所有故事开始，以达到我们有基本设计和对潜在问题可能是什么的好主意的地步。当然，在那之后我们并没有同时处理所有的故事。

我知道在风险管理方面，您可能希望确保在处理下一个故事之前为一个故事完成所有工作。但是，缺点是当您以后遇到无法预料的问题时，您可能没有足够的时间来解决这些问题。通常问题在实施阶段就表现出丑陋的一面，而且通常很早就出现了。因此，您基本上将一种风险换成另一种风险。

哪种风险更容易处理应该由团队决定。毕竟这是他们的 sprint，虽然我认为 ScrumMaster 提到对 sprint 进展方式的担忧是完全公平的，但他不应该强迫他的想法是在团队中工作的最佳方式。

最后，我认为归结为以下两点：

  1. 是的，我们确实同时处理了几个故事，到目前为止效果很好。

  2. 请记住，ScrumMaster 是为团队工作，而不是相反。

请注意，我主要是在谈论同时处理多个故事的整个团队，而不是一个开发人员。我看到的问题是，您需要确保不会通过保持开放来阻止任何故事，这样其他人就无法继续工作。再一次，这是一个环境和偏好的问题。在测试方面，我们的测试人员通常针对不同的故事有几个测试任务，因此如果某些错误阻止他继续测试某个功能，他可以轻松地切换到不同的任务。

于 2010-02-20T14:14:35.023 回答