【本文翻译自Mike Cohn的博客】
Scrum团队应该在每日站会中测试逐人和逐条进行更新，然后进行回顾以了解有效的方法
我想解决一个我最近遇到的问题，这个问题每一、两个月就会出现一次。我最近收到了以下电子邮件：
我们的大多数团队每个迭代完成10个或更多的用户故事。在回答每日站会的3个问题时，可以很清楚每个人在做什么，但不清楚每个故事的表现以及故事何时陷入了困境。例如，如果没有人处理一个故事，则该故事的问题将不可见，因为在站立时没有人提及该故事。所以我们现在开始
逐条（Story-by-Story）而不是逐人（Person-by-Person）讲故事了。虽然现在很清楚每个故事的进展情况，但是很难弄清楚每个人在做什么。有些人在处理多个故事，而另一些人可能在每日站会上根本不说话。
解决此常见问题的一种可能方法是，这些团队每个迭代做了太多的故事。根据我对成功完成的迭代的数据分析表明，一个团队平均每个人每个迭代大约能完成1-1.5个用户故事（实际上任何类型的产品待办列表条目（product backlog items）都是这样）。因此，一个六人团队应该在每个迭代中完成大约6-9个用户故事。短周期（一到两周）迭代的团队应该处于范围的底端；进行三到四周迭代的团队应该处于顶端。这意味着，具有较长迭代的团队会在其迭代中执行较大的用户故事。我讨厌听到每个人在每个迭代中完成一个用户故事的答案，因为这听起来像每个人都领取一个用户故事，并在整个迭代期间独自处理它。事实不是这样的。
用团队人数来表达条目（items）数量只是表明结果的一种显而易见的方式：更多的人，完成更多的用户故事。我想重申一下，并非每个人在每个迭代中都独立完成一个用户故事。解决上述问题的另一种方法是在物理看板前进行每日站会，并让人们指出他们正在从事的工作。我总是喜欢尽可能地做到这一点。我经常要求演讲者“指出您正在做的事情”。假设任务看板（task board）维护良好，我们能很容易看到相关任务对应的用户故事。另一个解决方案是为在迭代计划中要完成的每个用户故事指定一名“负责人”。此人负责了解该用户故事是否正在适当地开展。该人本质上是“故事所有者（story owner）”，但我们每天将花费2-5分钟的额外工作。这不是繁重的任务。这个人可能是故事的主要贡献者，也可能不是。这好像无关紧要。
另一个可能的解决方案是检查所涉及团队的规模。我发现理想的团队规模是5-7人。标准的敏捷建议恰当的规模是5-9人。如果可能，我会尽量保持在较低的规模。如果团队人数超过9人，很容易就无法追踪人们在做什么。最终大多数团队一开始每天逐人（Person-by-Person）召开站会，但有些团队遇到这里描述的问题就开始采用逐条（Story-by-Story）讨论问题。并非所有团队都需要这样做。如果您所在的组织中只有少数几个比较均衡的团队，我会随机地将其拆分，并告诉一些团队在完整的迭代中使用逐人（Person-by-Person）讲解的站会，而另一些团队则逐条（Story-by-Story）讲解。之后，我会召集大家进行简短的跨团队回顾，并让人们说说进展如何。我希望团队能够听到其他团队的结果，然后做出一个正确的决定：下一步该做什么。
网友评论