如何更好地执行会议
⇨⇦
团队引入Scrum的初期，会有一个常见的现象，就是成员们发现开的会变多了，自己安静开发写代码的时间变少了。在这篇文章中，我尝试基于自己曾经参与和指导过的Scrum团队阐述一下这些会议的意义，以及如何规划并且让团队更好地执行Scrum会议。
Scrum的会议及其意义
标准的Scrum流程包含了四个类型的会议，即Sprint Plan、Daily Scrum、Sprint Review和Sprint Retrospective。首先我们要知道，Scrum是敏捷开发的一种实践，它自然也遵循敏捷开发原则。它的目标是交付可使用的软件，所以上面提到的这些会议都对这个目标有着直接的帮助。
Sprint Plan会议主要是计划当前迭代的工作内容做计划。和传统开发流程里面项目例会或者启动会不同，Sprint Plan着重于Product Owner 和Dev Team的交流和互动。通过Product Owner的讲解，Dev Team的理解和提问，整个团队对于每一个Work Item最终都会达成充分一致，同时对于每一个Work Item的工作难度、涉及范围、可出现的问题和潜在的难点都会有充分的预判。最终在这个基础上，团队对Work Item的工作量（复杂度）进行打分。这些会上工作看似耗时，但是它的作用是把开发中可能遇到的问题提前暴露。如果以整个Sprint周期来衡量，这种充分的沟通能缩短开发时间，而且最大限度的规避了开发中出现问题的风险。所以Sprint Plan会议占用的时间是完全有意义且必要的。
Daily Scrum作为每天都会进行的会议，主要保证了团队成员充分的沟通。虽然时长较短，但是因为它需要每个成员介绍自己当天的工作内容、第二天的工作计划以及目前的困难，从流程上确保了大家必须提前安排好自己的工作。而且这个会议也能督促没有工作的成员主动领取任务。
Sprint Review作为团队工作的验收，要求成员通过现场演示的方式展示自己的成果。这种验收方式践行了敏捷宣言中＂可工作的软件高于详尽的文档＂。Product Owner作为最终用户的代表，基于实际可演示（可工作）的软件进行验收。
Sprint Retrospective作为对当前Sprint的总结，看似和产品开发无关，其实在某种意义上可以说是最重要的会议。敏捷的原则就是在实践中不断总结和改进。Sprint Retrospective会议就是专门为团队总结Scrum执行过程的问题而设立的。
对于一个新成立或者刚开始实践Scrum的团队，建议在第一次Sprint Plan或者启动会的时候对上述Scrum各种会议的作用和意义有一个简单介绍，尽量让团队成员认识到它们的重要性，从而最大限度的避免对会议的抵触情绪。
当然，仅仅了解会议的重要性还不够。为了保证会议高效而有序的进行，需要在会前、会中以及会后做很多工作，让团队切实感受到重要性。接下来我们针对不同类型的会议简单介绍一下如何执行的。
Sprint Plan会议
Sprint Plan会议最主要的就是讨论和评估Product Backlog里面的Work Item。首先，Product Owner需要在平时就注意维护好Product Backlog，即保证Backlog里面的Work Item都反映了最新的需求，内容具体明确，优先级合理。
其次，在开始Sprint Plan会议前，Product Owner需要预先对需要讨论的Work Item在进行一次梳理。必要的时候，可以和团队的技术骨干或者主要开发人员事先沟通。这样的好处是，在Sprint Plan会议中，团队针对每个Work Item的讨论更加高效，避免会上花大量时间思考和讨论具体的需求细节。
另外，Sprint Plan会议还有一个可能引起拖延的问题就是对Work Item的打分。在标准的Scrum流程中，团队成员需要根据自己对Work Item的理解，在不被其他成员影响的情况下独立打分，然后针对不同的分数进行讨论，直到达成一致为止。但是实际情况往往是，团队成员由于各自的专业技能不同、知识面不同、能力不同，打出的分数各不相同。或者由于一些技术细节，导致几名成员讨论的时候各不相让。最终导致一个Work Item迟迟无法确定Effort。虽然充分的讨论有助于提前发现问题和规避风险，但是这种过于陷入细节的争论却不利于会议的进程。因此可借鉴的做法是，在对Work Item打分的时候，选一个对此任务最为熟悉的成员打一个基准分，然后大家针对这个基准分投票。如果有不同意见再讨论。
最后，当团队工作量已经饱和后，理论上来说Sprint Plan会议就结束了。但是为了应对估算误差导致Sprint后期没有任务可做的情况，可以适当多估算几个Work Item作为备用。
Daily Scrum会议
Daily Scrum会议相对简单，因此只需要注意成员在发言的时候避免几个人过多的讨论细节，导致会议无限期延长的情况。一旦出现这种情况，Scrum Master需要及时制止。
另外，有的团队因为Product Owner参与多个Scrum团队，或者Product Owner和Dev Team距离较远（地理位置、时差），导致无法每次都参与Daily Scrum。为此可以考虑Dev Team的一个成员作为Product Owner Agent，临时代理Product Owner的职责。对于相对简单的需求问题可以直接决定，而对于那些不好判断的问题则在会后单独和Product Owner沟通。而这个Product Owner Agent的人选建议从测试人员中寻找，因为在Dev Team中测试人员对于需求的理解和把握是相对准确且中立的。
Sprint Review & Retrospective会议
Sprint Review一定要保证每一个Work Item都是以演示的形式进行验收。对于功能性的Work Item，演示起来相对比较好实现。而对于那些非功能性Work Item，比如架构设计、技术调研、可行性分析等，则看上去很难演示。对此，一般的做法是，对于架构设计，通常在Work Item分解到Task的时候就包含和设计、评审、更新三个部分。而在评审部分，团队成员和相关技术专家已经Review过设计，并且在后续的更新环节针对评审结果做了修改。因此在最终的Sprint Review会议可以直接略过，或者简单介绍一下评审结果。对于技术调研和可行性分析，则需要在Sprint Review会议上演示调研分析的成果，譬如例子程序、测试报告、分析报告等。总之，Sprint Review会议里面要求的演示并不仅仅指狭义的界面操作，也可以是文档、例子、报告等一切能够展示工作结果的东西。
Sprint Review的演示不宜过长，一般控制在每个5分钟之内，这就要求每个Work Item的负责人在会前准备好自己的演示环境和步骤。有一个可行的做法，就是在会前每个成员都在自己的测试环境准备好演示要用到的场景，会议开始后轮流接入投影仪演示。对于一些比较耗时或者操作等待时间很长的演示，也可以实现通过屏幕录像的方式进行演示。这么做可以让成员在演示前细心准备，也就是进行必要的测试。而进一步的，能够让团队在开发过程中就对自己负责的Work Item的质量进行持续关注。
Sprint Retrospective会议是对Sprint流程的总结会，因此需要注意不要成为对Sprint结果，或者对于团队成员的总结会。Retrospective经常会变成成员的批评与自我批评会议，这其实是不对的，需要Scrum Master特别注意。Scrum倡导的是团队而非个人，因此Retrospective总结的也是团队而非个人。
鉴于东方人大多比较含蓄和内敛，Retrospective也有可能变成无声静默会议。这时候需要Scrum Master在会议前就能总结出一些待改进的事项，会上带头提出，引导其他成员参与。或者采取轮流发言的机制，强制每个成员都要参与。但是无论什么手段，都要确保对流程不对结果，对事不对人。
最后，为了防止Retrospective只抱怨不解决，会议记录需要明确提出来的每个问题的提出者、内容、解决方案、负责人和截止时间。在下一次Retrospective会议中，Scrum Master可以先汇报上次Retrospective会议的记录以及解决结果。这样做的好处是用实际行动表明成员提出的每一个改进建议都是被重视被落实的，鼓励大家继续提出问题并改进。同时要指出，对于解决结果来说，某个问题最终没能解决也是一种可接受结果。
一些通用原则
准时参会
– 会议开始前5分钟之前，可以申请迟到。
– 会议开始后5分钟内到场，不算迟到。
– 会议开始后5分钟之后，算迟到。
– 每一个迟到的成员需要给团队发红包或请吃零食等。
发言权
– 只有对项目有直接贡献的成员可以发言
准时结束
– 绝不拖堂
– 未讨论的内容另行组织会议
会议记录
– 除Daily Scrum外，所有会议均保存会议记录，使用统一模板
– 会议记录包括：时间、参会人、议题、决议、负责人和截止时间。
总结
Scrum流程中，各种会议是其主要的组成部分，也是推进Scrum进行的基础。确保这些会议有序高效的进行是能否成功开展Scrum的关键。因此团队，特别是Scrum Master要对此给予足够的重视。
上面提到的一些原则、经验和流程仅仅是基于我之前参与过的Scrum项目总结而来的。而实际上，Scrum团队各不相同，会议的内容、进程和安排也不会完全一样。这需要整个团队不断地尝试、磨合、改进。最重要的，确保会议的讨论是有意义的，是得到团队认可的，才能最终达到目的。