在进行CSM（认证Scrum Master）授课时，我听到的最常批评之一是“Scrum团队有太多的会议了”。
由于Scrum具有每日Scrum站会、Sprint计划会议、Sprint评审会议、Sprint回顾会议，甚至可能还有产品待办列表精化会议，也就不难理解为什么人们会这样评论。
但是让我们看看这是不是真的。
一个实验
这里有一个实验，我希望你能试试，尤其是如果你认为Scrum会议太多。
从5-10中选择一个随机数。然后回想一下，你的团队是什么时候开始以敏捷方式开始工作的，或者他们是什么时候开始能较好地以敏捷方式工作的。
在你的工作日历（无论是在outlook、Google、苹果日历，或者其他什么程序）中，定位到这个月。现在，记得你在上一段中选择的随机数吗？再向前回滚随机数所对应的月数。
因此，例如，假设你们团队在十月份开始掌握敏捷的诀窍，而且你选择了5这个随机数。那样的话，你需要从十月向前回滚五个月，即查看五月份。
接下来，审视那个月的情况，记下你在这个月的所有会议。如果你和我以前做过同样的事情，你可能会发现在敏捷转型之前你已经有了同样多或者更多的会议——只是会议不同而已。
您可能偶尔会与相关干系人开会。你会和你的老板召开一次周会。你可能会有几个工作小组。然后会有设计评审会，可能是评审设计、技术、数据库或别的什么。你可能有一个周例会。可能还有些代码审查或评审会。可能在白板前会有些一次性的设计讨论会。加上几个电话会议。此外还需要考虑的是，你可能会有一些会议并没有排入日历中，所以你现在可能看不到。
完全有可能你敏捷前的会议数量比敏捷后还多。
当然绝不会对每个人来说都是这样的。但是，在我亲自进行这项实验时，有大约一半的人在开始Scrum之前有更多的会议。而最有可能在敏捷转型前拥有更多会议的人，是那些需要与其他人协同工作的团队成员。
为什么我们会觉得Scrum有太多的会议？
那么，为什么会普遍感觉Scrum有太多的会议呢？
是因为这些会议都有名字。当我们给某个事物命名时，它就可能会成为批评的对象。人们会抱怨“那些该死的Sprint计划会议”以及“烦人的每日Scrum站会”（他们可能会使用更丰富多彩的语言来抱怨）。
在Scrum之前你日程上的大多数会议都是没有名字的，而且也不是例行进行的会议。他们更像是“与玛丽的设计讨论会”、“与阿施施的代码审查会，”或“珍妮特的测试用例讨论会”。
你可能有过很多设计讨论会，但他们并不全是与玛丽一起召开的，也绝对不会有“与玛丽的讨论设计会”这种正式名称。
而当一个会议例行进行的并且被命名时，遭受批评也就变得容易多了。
如果Scrum运行的好，给人的感觉是帮助而非累赘。
Scrum的会议绝对有可能会成为累赘。并且，确实有很多团队在开会上花费了太长的时间。每当向一个团队建议多花点时间在某个Scrum会议上时，我都必定会告诉二十个或者三十个团队要减少会议时间。（尤为常见的是冗长的Sprint计划会议和产品代办列表精化会议。）
但是，一旦做得好，Scrum就会帮助而非妨碍产品的快速开发。每个会议都应该做到类似于：
- 正确的时间
- 正确的时长
- 正确的与会人员
- 以及正确的详细程度
Scrum框架的设置使这成为可能。如果一个Scrum团队对其会议不太感兴趣，那么Scrum Master应该仔细审视一下会议是如何进行的。
很可能，会议应该继续进行，但要更有效率，而不是放弃会议。
总会有些团队成员会批评任何会议。对某些人来说，就算是十年开一次会，仍然会嫌多。但是，一旦会议运作的很好，许多Scrum团队成员就会发现，他们在会议上花费的时间会比采用Scrum之前更少。
原文链接：https://www.mountaingoatsoftware.com/blog/do-scrum-teams-meet-too-much
作者：Mike Cohn
译者：李洁（Jerry Li）
