团队如何处理当前的冲刺积压物品？

Question

Scrum和敏捷表示，当前sprint积压的项目应按优先级顺序进行处理，并且整个团队一次处理一个项目。

实际上，这似乎从来没有为我们的团队工作。对于所有团队成员来说，这些项目都太小（包括考虑配对）。所以我们最终可能在同一时间在整个团队中做两三件。

我很想听听其他团队是如何做到这一点的，以及他们通常会在给定的冲刺中承诺多少件物品。在目前的冲刺积压

Answer 1

整个团队接近每个项目的建议是为了避免在冲刺内创建迷你瀑布，其中项目从一个专门组传递到另一个专门组。这导致测试人员在短跑的第一天无所事事，然后在最后几天编程人员摆弄他们的大拇指时加班。团队应该把整个问题作为一个整体来处理，即使在各自的“专业化”之外，每个人都会参与其中。是的，编程人员可以测试，测试人员可以编写代码，两者都可以设计架构等 - 并在过程中学习新的东西（令人惊叹）。这并不是说每个人都应该很擅长所有事情 - 只是说像“我不测试，我是编码员”或“我不会写这个脚本，我是测试人员”这样的态度在Scrum团队中没有地位。

建议在冲刺内逐个处理项目，以确保最终实际上有东西被传递。限制进行中的工作（WIP）可以防止每个人都在每个项目上执行一些任务但没有任何项目在冲刺结束时完成的情况。

但是，这不应该被视为建议，而不是一个非常严格的规则。例如，当你有两个小故事和一个10人团队时，让所有团队都集中在一个故事上可能没有意义。

底线是：没有人应该告诉团队如何在他们自己之间划分工作，但应该期望他们在Sprint计划中交付他们的承诺。

Answer 2

项目应按照优先顺序在时间整个团队上前，和一个项目。

我不知道这是谁说的，我至少不记得听过或读过类似强调文字的东西了。当然，这也取决于您的商品是的故事还是单个任务。

如果它是一个故事（通常由多个任务组成），可能有实现这个目标的机会。然而，正如你所说，有时候这个故事并没有包含足够的任务来保持每个人的忙碌。通常与故事有关的任务强烈地依赖于彼此，例如，可能会有一个设计会议（涉及部分或全部团队），然后是一个或多个编码任务，然后是代码审查，功能测试，文档编制等。显然，在编码之前不能进行功能测试等等。

由于每个人都必须做某些事情，所以在任何给定时间至少有多少任务会与团队成员（或对）一起打开。考虑到有时任务由于各种原因（任务间依赖性，外部方需要的信息等）而被搁置，通常甚至更多。

在一个由4名开发人员组成的团队的一个Scrum项目中，我们遇到了非常相似的情况。我们的确努力按照优先顺序尽可能地讲故事，并且通常我们有多个故事和几个任务随时开放。一开始我们在冲刺结束时经常遇到几个半完成故事的问题。所以我们意识到将开放任务/故事的数量保持在最低限度是很重要的，也就是说，在开始新任务/故事之前，总是试图完成开放任务/故事。但实际上，这个最小值从来没有达到1.

至于每个sprint的故事数量，我们只是根据我们的（故事，然后是任务级别）估算，尽可能多地放入适合的数量。这当然很大程度上受到我们的速度的影响，这在一开始估计过高。几个月后，我们将其降至60％，而这一价值似乎对我们有用。

Answer 3

我认为这取决于你的团队的构成。如果你有一个团队，任何人都可以在用户故事中接受任何给定的任务，那么这很有效。如果你不这样做，那么有些人可能会有空闲时间。

根据优先级来处理用户故事的要点很简单...您将获得首先完成的最高优先级的用户故事。这从实际设定优先级的客户角度增加了最大的价值。

至于在冲刺期间需要承诺多少用户故事，取决于以下几个因素： 团队可用性，团队速度和冲刺持续时间。所以，我不确定你会知道在冲刺期间有多少人遇到了多少故事。

Answer 4

Noel，您的团队是否受过在Scrum团队中工作的培训？我的意思是你在开始这个项目之前把它们发送给了Scrum课程吗？

我见过这么多的团队因为错误地理解了博客上的书而写错了Scrum。

另外有一个经验丰富的Scrum Practitioner或Scrum Coach会帮助你很多。

具体回答你的问题，看看这个漂亮的免费的电子书，是不同比别人：

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf