3

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

实际上，这似乎对我们的团队不起作用。要么项目太小，以至于所有团队成员都无法发挥作用（包括考虑配对）。所以我们最终可能会在任何时候在整个团队中完成两三个项目。

我很想听听其他团队是如何做到的，以及他们通常在给定的 sprint 中承诺多少项目。

4

4 回答 4

3

当前 sprint backlog 上的项目应按优先级顺序处理，整个团队一次一项。

我不知道这是谁说的，我至少不记得到目前为止我听过或读过类似强调的文字。当然，这也取决于你的项目是故事还是单个任务。

如果它是一个故事（通常由几个任务组成），则可能有机会实现这一目标。然而，正如你所说，有时故事只是没有包含足够的任务来让每个人都忙。与故事相关的任务通常也相互依赖，例如，可能有一个设计会议（涉及部分或整个团队），然后是一个或多个编码任务，然后是代码审查、功能测试、文档等。显然，一个可以在编码之前不要做功能测试等等。

由于每个人都必须做某事，因此在任何给定时间打开的任务至少与团队成员（或成对）的数量一样多。考虑到有时任务因各种原因（任务间依赖性、需要来自外部各方的信息等）而暂停，通常甚至更多。

在一个由 4 名开发人员组成的 Scrum 项目中，我们遇到了非常相似的情况。我们确实努力尽可能按优先顺序处理故事，通常我们随时都有多个故事和几个任务打开。一开始，我们经常在冲刺结束时遇到几个半成品的故事。所以我们意识到将打开的任务/故事的数量保持在最低限度是很重要的，即始终尝试先完成打开的任务/故事，然后再开始新的任务/故事。但实际上，这个最小值从来都不是 1。

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

于 2010-07-01T19:53:21.627 回答
1

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

基于优先级处理用户故事的要点很简单……您首先完成优先级最高的用户故事。从实际设置优先级的客户的角度来看，这增加了最大的价值。

至于在 sprint 期间要提交多少用户故事，这取决于几个因素：团队可用性、团队速度和 Sprint 持续时间。因此，我不确定从了解其他人在 sprint 中处理了多少故事中可以获得多少价值。

于 2010-07-01T20:12:18.360 回答
1

整个团队处理每个项目的建议是避免在 sprint 中创建小型瀑布，即项目从一个专业组传递到另一个专业组。这导致测试人员在 sprint 的头几天无事可做，然后在编码人员摆弄拇指的最后几天加班。团队应该作为一个整体来解决问题，每个人都参与进来，即使是在他们各自的“专业化”之外。是的，编码人员可以测试，测试人员可以编码，并且都可以设计架构等 - 在此过程中学习新的东西（令人惊叹）。这并不是说每个人都应该擅长一切——只是说“我不测试，我是程序员”或“我不会写这个脚本，我是测试员”这样的态度应该在 Scrum 团队中没有位置。

还建议在 sprint 中一项一项地处理项目，以确保最终确实交付了一些东西。限制进行中的工作 (WIP) 可以防止出现每个人对每个项目都做了一些任务，但在 sprint 结束时没有完成任何项目的情况。

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

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

于 2010-07-02T09:30:26.967 回答
0

Noel，你的团队是否接受过在 Scrum 团队中工作的培训？我的意思是你在项目开始之前把他们送到了 Scrum 课程吗？

我见过很多团队在使用 Scrum 时失败了，只是因为他们误解了博客上的书中所写的内容。

拥有经验丰富的 Scrum 实践者或 Scrum 教练也会对你有很大帮助。

要具体回答您的问题，请查看这本不同于其他的不错的免费电子书：

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

于 2010-07-02T18:52:48.187 回答