敏捷开发模式中的四种会议

从敏捷开发流程模型图当中可以看出，在敏捷实施过程当中，有四种会议，分别是计划会，每日站会，回顾会，评审会，其中数计划会最为重要。应该来说会议是有点多的，不是流传一种说法嘛，不开会的团队的一定不是一个好团队，好的团队一定经常开会。经常开会是需要时间的，因此有利有弊，如果会议时间和节奏控制的不好，就会占用掉团队很多的精力和工作时间，那就得不偿失了。在敏捷开发模式中，每种会议都有其特殊的职责和使命，不同的会议上所讨论的内容是不一致的，只要把握住会议的关键点，就可以为团队的敏捷模式服务。

关于开会，日常工作当中各种会议、培训、沟通等都会占用掉大量的工作时间，因此会议贵精不贵多，在最短的时间内达成最有效的决议，这才是一个有成果的好会议。产品团队必然也会面临这样的问题，在敏捷团队内部，除了必要的全员培训外，尽量保持在团队内部只有敏捷的这四个会议，其余的沟通和会议都可以由PO和SM去参加，然后回来传达给团队成员即可，这样可以减少团队整体的时间消耗，保证团队的工作效率。

Sprint Planning敏捷迭代计划会议

在每个敏捷迭代开始之初，由产品负责人讲解需求，并由开发团队进行估算工时的计划会议。 在会议上需要：排列需求优先级；分析和评估产品Backlog并确定该迭代的目标；计划会议上还需要制定迭代计划，包括： 根据产品Backlog（功能点）创建Sprint Backlog（即迭代任务）；然后为Sprint backlog中的任务做估算；团队成员从产品Backlog中挑选他们承诺完成的条目。

敏捷的迭代实现始于计划会议，所以一个好的计划会议是每个迭代成功的基础，一般分两个阶段进行，两个阶段参与会议的人员会不一样；

计划会议的目标：

1、基于敏捷规划产生的Product Backlog以及优先级，通过计划会议，确定迭代的目标、团队成员、形成Sprint Backlog，明确评审会、回顾会时间；

2、分解Sprint Backlog并确定相应的完成时间，并由团队成员共同挑选这些Sprint Backlog；

阶段一参与人员：产品经理、Product Owner、Scrum Master、团队成员，有业务人员的话还可以邀请业务人员一起参加。

会议时长：1-4小时

一般参考进程安排如下：

1、Scrum Master公开迭代时间表；

2、产品经理和Product Owner讲述Product Backlog，对应的业务价值和优先级；

3、团队针对Sprint Backlog和优先级达成一致；

4、Scrum Master和团队成员共同确定Sprint Backlog；

阶段二参与人员：Scrum Master、团队成员，其他人员选择性参加

会议时长：1-4小时

一般参考进程安排如下：

1、团队成员针对Sprint Backlog共同分解任务；

2、团队成员共同进行工作量评估(每个Task不超过2天)，确定开始时间和完成时间；

3、团队成员共同认领任务；

4、共同确定DoD，团队达成一致；

5、团队共同确认迭代目标和价值；

如果单个迭代内安排的Product Backlog安排的比较多的话，一般迭代计划会议需要开一个整天，虽然时间有点长，但这个会议会确认整个迭代的详细计划和安排，因此也是值得的。

Daily Stand-up Meeting每日站会

团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，团队成员通常会在会议上讲述如下3点内容：

1) 昨天我做了什么

2) 今天我计划要做什么

3) 我遇到了什么问题，妨碍了我尽可能有效地工作

Scrum Master记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。

Sprint Review敏捷迭代评审会议

在迭代结束前给产品负责人演示并接受评价的会议，并根据反馈结果，提出新的产品Backlog

参与人员：产品经理、Product Owner、Scrum Master、团队所有成员

会议时长：1-4小时，视演示内容而定

主要是检验迭代成果，检查是否完成迭代计划中的迭代目标，有可能的话要求用户参与测试流程，并得到用户对产品的认可，鼓励用户自己进行测试设计和进行破坏性测试，充分暴露产品的设计和功能问题。

由Scrum Master来推进会议进程，Product Owner记录用户反馈，根据结果维护产品 backlog，一般在迭代结束前做一次。

Sprint Retrospective敏捷迭代回顾会议

在每个迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：

1) 本次迭代有哪些做得好；

2) 本次迭代我们在哪些方面还能做得更好；

3) 我们在下次迭代准备在哪些方面改进；

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

参与人员：Scrum Master，Product Owner，团队成员。

会议时长：0.5-1.5小时

主要针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的点以及持续跟踪计划。

Scrum Master将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事。需要按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪。

案例分析

案例一：某Team在每日站会中，Scrum master准时组织大家开始晨会，成员一个接着一个说，昨天做了什么事情，今天计划做什么事情，遇到什么问题，成员A说昨天遇到了一个问题未能解决，Scrum master问遇到的是什么问题，成员A详细说明了该问题，这时成员B说这个问题他也遇到过，他是通过XX方式解决的，讨论后成员A明白了，然后继续晨会，由于小组成员有10个人，整个会议开下来大概花费了30分钟。

问题分析：Scrum master不应该在每日站会上询问详细的问题细节，而应该转移到会下询问，当团队成员之间进行讨论的时候，Scrum master需要及时拉回来，讨论应该转移到会下进行，晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。

案例二：某Team在开回顾会议中，Scrum master详细总结了本次迭代中有哪些做不够好的，并指出了对应的事和人，接着对应的责任人开始述说哪些地方确实是做的不够好及其原因，最后给出改进措施然后结束会议。

问题分析：回顾会不是批斗会，不应该只说做的不好的，做的好的也要说，Scrum master主要是鼓舞大家的士气，应该先从做的好的方面开始说起；并且做的不好的方面都只对事，不对人，做的不好是整个Team的责任，不仅仅是某几个人的责任；最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。

在敏捷的迭代执行过程中，上述四种会议会随着每个迭代一直进行，基本上形成了一个闭环，可以让团队在每个迭代的执行过程当中去学习和总结，从而正确的按照敏捷的要求去做，使团队真正的敏捷起来。