如何更好地进行每日立会？

如何运作好一次每日立会？有哪些最佳的技巧和方法？ 很多敏捷团队都实行每日立会实践，但是 Joakim Karlsson 认为：“坦白讲，大多数每日立会都很乏味无趣。”它们变成了每个人都必须被迫参加的会议，更糟糕的是：以前每周一次类似的会议，现在却每天都有。

Paul Wynia 提供了一个项目的实例，其中项目带头人没有敏捷培训以及相关经历，每日立会因此变成了每日进度报告会议：

她会让每个人详细讲述各个功能特性、bug 和前一天与别人的交流，还有自己的工作，包括对于马上开展的这一天的工作的估算。然后，她会与每个人讨论几乎所有的工作条目。发展到后来，人们会带着笔记本参加会议，其中写满了所有的工作细节，还要记录她分配的新任务。这个团队只有 5 个人，她竟然能将每日立会延伸为每天 30 到 45 分钟的会议，人们感觉无聊至极。

Paul 接下来建议：立会应该限制在 10 分钟之内，最多不能超过 15 分钟。对于他自己指导的团队召开的立会，如果时间超出了，他允许团队成员自行离开，这等于给 Scrum Master 一个信号，说明会议的运作方式有问题。

Joakim 推荐：

• 关注目标——与资深团队成员分享信息，他们会帮助整个团队在迭代中完成工作。
• 关注团队——与所有人分享信息，而不是只告诉管理人员。
• 在其他时候讨论——不要在立会中解决问题，可以安排后续时间解决，而且允许感兴趣的人参与。
• 有准备而来——要是不想拉长立会时间，团块成员需要知道你的工作成果和待完成任务。
• 关注成果—— Joakim 发现：“相比告诉别人自己正在完成系统的哪个部分，讨论成果能够提供更为积极的态度。”
• 做出承诺——他让人们向其他团队成员承诺自己要完成的工作，而不仅仅是机械地说接下来的 24 小时要做些什么。
• 指出障碍——你是不是要接触 60 多份文件才能完成某些细小的变更？

Mike Cohn 推荐团队在任务板前举行立会，询问发言的人他们在开发哪个故事。同时，Mike 指出：团队规模如果超出 9 个人，成员会很容易对他人正在着手的工作失去了解。

Drew Stephens 指出：他的团队使用“以用户故事为中心的每日立会”。想很多敏捷团队一样，Drew 也是从相对传统的立会开始的，但是当团队规模变大时，他却陷入了困境。

已经没有哪个故事的工作量能够占用整个团队的工作能力了，因此我们开始并行开发多个故事。我们也注意到：很多故事处于活跃状态的时间更长，而且开始出现被我们称为“任务尾巴”的东西（也就是一个故事陷于停滞，有一些属于该故事的、未经验证的任务连续多日处于低优先级状态）。出现任务尾巴，我们发现两个主要原因： 1. 代码质量低下导致 QA 人员发现奇特却稳定出现的 bug 流。
2. 当一个故事看起来接近“完成”状态时，开发人员转而开发其他故事，可之前的故事并没有完全完成。

作为这些因素的结果，我们的立会变得令人困惑：一个人谈到的故事与上一个人提到的完全不同，要想确定一个故事的进度变得很困难。人们关注的不再是要完成什么任务才能结束当前活跃的故事，而是每个人在做什么或是要做什么。个中区别并不是很大，但是带来的问题却越来越严重。

他们的解决方案是：把正在进行中的故事过一遍，每个开发该故事的人针对该故事回答 Daily Scrum 的三个问题。如果人们同时开发多个故事，他们就要跟大家说明多个故事的情况（这可能是个“异味”）。Scrum Master 会追踪谁已经发过言，如果有人说完一个用户故事后又提到另一个故事，这可能就是个障碍了。

Artem Marchenko 有如下建议：

• 不许打字——如果有人在笔记本电脑（或其他设备）上做记录，他们就获得了（本不应获得的）重新阐释团队成员发言的权力。
• 如果团队在向 Scrum Master 汇报，那么 Scrum Master 就应该移开眼光，不与团队成员对视，极端情况下甚至可以转过身去。

在与 Henrik Larsson 的访谈中，Jason Yip（文章《光站起来还不够——每日立会的模式》的作者）指出了立会的视角发生的变化：

我曾更多地将其视为进度报告会议。然后我发现立会更关注的是承诺，主要感谢 Mike Cohn 的著作。近来，我更多将其视为解决问题的过程。现在，我最钟爱的形式是“走到板前”的风格，当然要有任务板 / 故事板。我希望更多地强调完成工作的重要性，而不仅仅是让人们尝试着忙起来。 说过这些，立会还是有些方面是这些年没有变化的，比如保证“仪式”气氛高昂的重要性，还有要与团队共同分享，而不是向领导报告。

你的团队使用了哪些有成效的方法呢？

InfoQ 之前的类似内容：好立会的标准是什么？

查看英文原文： Daily Standup Tips - a Roundup