根据2021年最新的Agile & DevOps调查发现，很多组织在由传统开发模式向敏捷模式转变过程中，有66%左右组织会引入Scrum框架，如下图所示。而在团队实施Scrum的过程中，除了能够帮助组织实现快速交付、提升产品质量、提高客户的满意度等等，对于团队成员最为直观的一个感受就是多了很多会议，哪为什有这么多会？这些会都是必要的么？今天我们就来聊聊Scrum中的相关会议。
图片来源于：https://stateofagile.com/#ufh-c-7027494-state-of-agile
了解Scrum的同学比较清楚，Scrum框架中经常会提到的几个数字：3355，哪何为3355呢？我们来看一看
3个角色：SM（Scrum Master）、PO（Product Owner）、开发团队
3个工件：产品待办列表、迭代待办列表、迭代产品增量
5个会议：每日站会、迭代计划会、迭代梳理会、迭代评审会、迭代回顾会（也有成为5个活动）
5个价值观：承诺、专注、尊重、开放、勇气
3个角色各司其职，3个工件作为迭代过程中的输入输出，以及作为团队应该坚守的5个价值观，都是融入在团队的日常工作中的，至少从表面上来看，并没有占据团队太多的时间。而作为迭代过程中的5个关键会议/活动，往往带给团队的感受就是：自从运作Scrum以来，增加了很多会议，占据了太多个人时间，甚至大幅缩减了开发测试的时间，能不能把这些会议取消了或者减少几个？
这是我们经常在组织敏捷转型过程中听到过的最多的抱怨，那真实情况是这样的么，这些会议真的占据了团队太多的时间么？这些会议到底值不值得开？可不可以减少几个呢？带着以上几个疑问，我们来聊一聊。
会议时长
在早期的Scrum指南中，对Scrum各项会议的时长要求做了建议，对于为期2周的一个Sprint来看，分别建议会议时长控制在以下范围内：
每日站会：≤15min
迭代梳理会：≤120min
迭代计划会：≤240min
迭代评审会：≤120min
迭代回顾会：≤90min
由此粗略算下，总共的时长为已经大于8个小时，即超过了1个工作日的时间。试想在为期2周迭代安排里，10个工作日就有超过1整天的时间用于开会，大家的感受会是如何呢？那么这些会议到底值不值得开呢？我们再来看第二个问题。
关于Sprint活动中的这几个会议，除了每日站会，其他的似乎大家都觉得可有可无，为什么会有这样的想法呢？
会议目的
其实说到底团队成员并没有意识到这几个会议给Sprint活动带来的价值，下面我们来挨个梳理下：
第一，每日站会，其主要目的就是通过个人每日工作进展的对齐，来识别开发过程中的依赖和风险，促进团队内部更好的协作，确保迭代目标达成；
第二，迭代梳理会，主要用于下个迭代的需求梳理，PO与团队成员进行需求澄清，其目的是通过尽早的需求梳理活动来识别风险和依赖，并在计划会之前解决问题；
第三，迭代计划会，很显然就是根据需求优先级和团队资源安排迭代计划，明确迭代目标，团队共同决定需要完成那些故事（需求），如何完成这些故事，并跟内外部干系人对齐目标；
第四，迭代评审会，通过评审会将团队迭代交付成果展示给相关干系人，并获取反馈，用于支撑团队更好的进行产品改进，及时进行调整，确保开发的方向正确；
第五，迭代回顾会，通过定期的反思迭代过程中的团队做的好的、需要改进的方面，确保团队的持续改进、团队个人能力的提升，为打造高绩效团队持续投入。
所以明确了以上5个会议的目的，就不难发现，这些会议基本都是要开的，非常有价值的，能够帮助到团队更好、更快的交付价值及持续改进的。
既然都有必要，那就要思考第三个问题，如何能够高效的完成这些会议呢？
高效会议
那么到底应该怎么高效的开好这些会呢？其实无非是几个方面的工作：会前准备、会中控场、会后跟踪（另外有兴趣的同学也可以去搜下会议的7P原则，也是帮助我们如何高效开会的）。
会前准备，团队每个人都要意识到，接下来的这个会议目的是什么，我需要准备什么？每个人提前预留思考的时间，能够帮助我们更高效的开好会议。
会中控场，会议中不断发散的讨论往往是大家觉得会议冗长、无效的根本原因，所以一定要有人来进行控场，这个角色一般都是SM，或者PO也可以，总之能够把大家从发散的讨论中拉回主题，确保围绕会议的目的展开。
最后会后跟踪，也是非常关键的一环，尤其对于会后有遗留风险、问题跟踪解决的，一定要确保能够形成闭环，否则就会给大家造成的感觉是浪费时间，会议低效，没有解决任何问题，久而久之，就不想去开会了。
最后还有一点，大家产生会议太多的想法是因为我们是在原来已有会议的基础上增加了这5项会议，比如说团队本身就还有其他的评审会、汇报会、讨论会以及职能部门的例行会议，这些会议零零散散加起来也占据了近1天的时间，尤其是身兼多职的同学，开会的时间2~3天都算少的了。哪对于整个Sprint来说，我们倡导的是希望所有的会议都能够减少并融入到这5项会议中，具体怎么冗余，我们可以根据团队实际情况来进行调整，并不一定是会议的形式，可以以其他一些可视化的方式进行展现，比如每周的例行汇报会议，就可以通过团队的各项可视化看板来展现给管理团队，从而避免了向领导去额外汇报，节省时间。
在实际的操作中，我们对这些活动经过优化后，Scrum整个会议的时长变化为：
每日站会：≤15min
迭代梳理会，改为迭代梳理活动，分散在迭代过程中
迭代计划会：≤90min
迭代评审会：≤30min
迭代回顾会：≤60min
这样算下来，会议的直接时长缩减到4小时以内，比原来少了一半的时间，既能改善大家的体验、达到会议目的，也大大提升了会议效率。
所以，对于Spring过程中的这些会议，我们按照以上原则，逐步的去引导团队执行，更重要的是要能够看到通过这些会议团队达成目标、解决相关问题，慢慢的大家感受到了这些会议带来的价值，就不会抱怨这些会议在浪费时间。
