敏捷管理Scrum的五大会议，怎么开才不浪费时间，且更有意义？

在敏捷的项目管理中，团队发挥每个人的主观能动性，做到团队自组织，在这个过程中，需要不断同步信息，在Scrum运行过程中，通过会议让团队成员都参与进来，每个会议内容不同，但是都非常重要。

在项目开始的时候，有交付计划会议，在这个会议中，定下来项目的总体基调，而接下来就是每一个迭代，通过迭代计划会议，每日例会，迭代评审会议，迭代回顾会议，不断实现增量，产生成果，交付给客户。

一、交付计划会议

交付计划会议可以说是项目的启动会议，在这个会议中，定下这个项目的基调。这次会议的目的是，居于用户的需求已经优先级，通过交付计划会议，确定项目里程碑，发布的目标，团队成员，项目团队的规章制度，包括例会、计划会、评审会、回顾会的时间和要求。

1、开会的时间一般是项目启动开始的时候，时长2个小时。

2、参会人员：Product Owner、Scrum Master、开发团队、公司高层、客户等。

3、开会议题

Product Owner 介绍项目背景，项目的目标，介绍团队成员，每个人团队成员自我介绍，大家互相认识；
Product Owner讲述Product Backlog，对应的业务价值和优先级；
Tech Lead和QA Lead做可行性及时间的评估，对于技术框架选型确认；
团队针对Release Backlog和优先级达成一致；
高层宣布项目正式启动，开始项目；

4、会议输出

规划到release的 Product Backlog 条目，优先级；
各个 Backlog 条目的初略需求；
Release里各个story的时间的评估；
团队组成、人员安排、技术框架选型；

交付计划会议开完以后，就要开始工作，每个交付分成几个迭代，每个迭代开始就是迭代计划会议。

二、迭代计划会议

每个迭代开始，就要开始迭代的机会，在这个会议上，确认迭代包含的Story，这些Story时间、优先级，讲解需求，分配任务，对于成果交付标准达成一致。

1、开会的时间一般为迭代开始第一上午，会议持续时间大概是2个小时。

2、参会人员：Product Owner、Scrum Master、开发团队。

确定团队成员的Capacity，需要去掉假期、会议的时间，一般8%的会议时间，2个星期大概有一天的开会时间；
Product Owner跟团队确定这个迭代需要做的Story、优先级，Product Owner给开发和QA讲解详细的需求；
开发团队确定技术框架、根据需求确定技术方案；
开发、QA明确需求以后，开始认领任务；
团队确定DoD，统一完成的认识；

3、会议输出

规划到迭代的Story条目、优先级、详细时间估算；
开发，QA明确需求，确认技术方案；
开发，QA认领任务；
团队Capacity；
团队完成的共识DoD；

开完迭代计划会议，大家就开始进入了项目迭代阶段，在迭代的每一天，都会开每日站会。

三、每日站会

迭代计划会议完成以后，就要开始进入开发测试阶段，在这个阶段，需要大家全力合作，高效率完成任务，这就需要大家知道彼此的进度，解决遇到的问题，而这个就在每日站会来解决。在这个会上，主要就是更新任务状态，解决遇到的问题。

1、开会的时间每天上午10点，会议持续时间大概是15分钟，不能超过这个时间，如果超过，需要重新评估开会，包括开会的方式、内容。

2、参会人员：Scrum Master、开发团队

昨天每个人做了什么？完成了什么，什么东西可以提交测试；
工作中遇到了什么问题，会不会阻塞进度，解决了同步下解决方案，这个可以作为技术分享，如果没有解决，看看有没有什么方案，如果要讨论会后讨论，要跟进会后有专人跟进；
今天准备做什么；
所有的团队成员知道各自的工作进展，这个可以为各自的合作提供基础，比如说前后端合作，开发、QA的合作，这样就不需要等，可以协商进度；
得到问题的列表，这些问题都需要跟进，需要外部资源就需要Scrum Master去协调；
更新任务板，得到最新的燃尽图，这样就知道任务实际运行与计划的差别，进而做出下一步行动；

每日例会需要大家准时参加，同时也必须参加，不能把自己的进度发给Scrum Master，这样可以同步进度，不能发现问题，解决问题，同时同事之间的协作如果没有沟通会降低效率。

四、迭代评审会议

当迭代运行到最后一天，需要邀请Product Owner、Scrum Master、客户开会，对迭代成果进行演示并接受评价，根据反馈结果，提出新的产品Backlog

1、开会的时间一般为迭代最后一天下午，会议持续时间大概是2个小时。

2、参会人员：Product Owner、Scrum Master、开发团队、客户、公司高层

开发或者QA演示迭代成果，Product Owner检验迭代成果，检查是否完成迭代计划中的迭代目标，并且使用迭代成果；
对于迭代的成果提出自己的意见和建议，把这些安排放入到迭代Story里面，更新产品的Backlo；
迭代成果，如果需要，Product Owner和客户同意，就可以发布了；
问题列表，根据问题列表，更新产品backlog；

五、迭代回顾会议

迭代完成以后，团队检视最近 Sprint 中有关个体、交互、过程、工具和他们的 Definition of Done 的情况如何。对于迭代的工作进行复盘总结，对于团队的工作进行反思，这样才能促进团队的能力提升，效率提升。

1、开会的时间一般为迭代结束下午，会议持续时间大概是2个小时,围绕如下三个问题进行讨论。

本次迭代有哪些做得好；
本次迭代我们在哪些方面做得不好；
我们在下次迭代准备在哪些方面改进；

2、团队确定问题优先级，并根据优先级确定团队能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪。

3、主要针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的地方以及持续跟踪计划，在会议中不讨论具体问题(如技术方案等)。

4，将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事。

5、需要按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪。

六、团队成员抱怨会议多怎么办

会议太多是很让人沮丧的，特别是工作每天排满，同时白天开好几次会，工作需要晚上加班完成，这样导致大家对于开会抵触。

敏捷开发方式需要快速迭代，信息快速流转，很多事情需要依靠开会来同步信息，这样就会发现会议比较多，这个时候需要做好解释，同时落实行动，让团队成员理解会议多，同时支持开会。

1、开会之前做好准备

所有的成员都是带着思考、想法来到会议室，这样到了会议室就马上开始讨论，节约时间，这就需要Scrum Master做好开会前的引导。

2、开会的时候要专注，不要自由发散。
在开会的过程中，Scrum Master能够控制开会的议题，而不会让团队成员自由发散，导致开会总是超时。我们在开会的时候都是围绕主题，如果有人跳出主题一分钟以上，Scrum Master就要把想法记下来，然后把大家拉回到主题，发散出来的问题，可以以后再讨论。

3、在安排任务的时候，把会议也作为一项任务安排进来。
很多人觉得烦是因为开会的时间不算做工作，或者临下班开会，这样占用员工的时间。在统计时间的时候，要把会议时间计入，这样开发就不会反感。