改变Scrum的每日站会（Daily Scrum）-译

Bob Jiang

2013-11-26

Page content

本文讲述了改变Scrum每日站会的一个小故事。我们从典型的以人为中心转变到以Sprint Backlog里的故事为中心。这个想法来自于Jeff Sutherland的一篇论文。

本文的目的是简要描述我们为什么和怎样进行每日站会的变化，它的优缺点，以及我们得到的反馈。在开始之前，先介绍一下背景。

背景

团队已经采用Scrum和每日站会，也有Product Owner（PO）角色。

何时何地出现了改变每日站会的需求？

改变的需求来自于团队的回顾会议。

在改变之前，每日站会按照标准的方式进行。每个团队成员将回答3个经典问题：_1）昨天我完成了什么？2）有什么障碍？3）今天我将要完成什么？_当一个人完成后，下一个人继续。这种方式关注正在说话的每个团队成员。

几个月（许多迭代）之后，许多人抱怨每日站会效率低。基于大家对于这种效率低的原因的反思，团队达成结论，每日站会本身的这种方式可能导致了效率低。

提出什么行动计划？

我们读过Jeff Sutherland的论文https://jeffsutherland.com/ScrumMetricsHICSS2013BWSubmissionFinal.pdf 并且非常喜欢关于改变每日站会的提议。Jeff提议在每日站会上检查Sprint Backlog中每个故事的功能，而不是每个团队成员的。作为教练，我留意到这篇论文，或许团队有兴趣学习一下。事实上，团队很高兴有这个提议，于是团队落实了行动计划，以在下一个迭代来验证这个变化。

这个改变是如何执行的？

在接下来的迭代中，团队在相同的地方开始每日站会，但是这次是基于Sprint Backlog中的每个故事回答3个经典问题。也就是说一个以上的团队成员（取决于几个人参与这个故事）都会说围绕着具体的故事他们完成了什么，将要完成什么，是否存在障碍，以及完成这个故事还需要什么。直到手上这个故事所有相关的问题都解决了，团队才会继续进行下一个。这个流程持续到Sprint Backlog中最后一个故事讨论完。需要注意的是，建议从最重要的故事开始，按照重要性的降序继续讨论。

这个改变带来什么好处？

假设PO参与每一次的每日站会，这个方法可以让PO听到团队关于产品开发的进展——比如，这个方法面向的是产品，而不是谁完成了什么。重要的是正在开发的产品，以及在Scrum中，团队整体执行开发工作。从概念上，我们说团队工作是一组有共同目标（愿景）的人在高度协作的环境中工作。

改变的结果是，团队的效率几乎马上得到提升。假设这是由于这样的事实导致的，当讨论故事的时候参与的每个人都发言，从而提高了专注力。相比之下，传统的每日站会经常有干扰。比如，如果两个开发人员做同一个故事，团队不得不等到两个人在不同的回合中都说完了，才能充分地理解这个故事过去和将来的行动。

更重要的是，对故事专注力的改变，需要整个团队强化正在构建产品的知识，因此现在团队专心在产品上，而不是开发人员的任务。

每个开发人员说话不做限制的事实，允许其他团队成员（他们可能在自己的故事中受阻，或只是完成了一个故事）尝试一起合作关掉正在讨论的故事，而不是去认领一个新的故事。

这个改变的缺点是什么？

大家都知道，在接下来的回顾会议中我们分析了这样的流程改变，为了识别出优缺点。在这个案例中，观察到的主要缺点是，它很难检测到团队成员是否在工作。现在的每个站会中，讨论围绕着故事，而不是每个人在做什么。因此，团队成员必须更积极主动处理这种“闲置”的状态。

同样的，当团队成员非常忙碌的时候，可能也不是那么明显。

作为教练，假设这迫使团队需要更多更好地自组织的话，我的观点是这个缺点可以转化为机会。每个人负责有效地利用自己的时间。每个人负责查看开发流程是否停滞。而且每个人负责决定为了前行而如何一起工作。事实上，参加改变的团队发现一个方法来减轻这个缺点。比如，团队修改仪表盘，因此，查看流程中的每个团队成员的情况更容易。