个人站点地址：nowherewoman.com
这里想要分享的不是敏捷开发要开什么样的会，因为这类文章太多而且肯定比我专业。我是想从一个实践者的角度来写下一些开会的趣事以及如何解决的。
开会在敏捷开发中非常重要，几乎所有的设计和决定都是在会议上大家一起完成的，其中planning meeting是重中之重，是一个sprint的开始，在一定程度上决定了这个sprint的产出。
【基本情况】
参加会议的人员，PO, TEAM（Scrum master由其中一名团队成员兼职），其他相关人等（根据story的情况，有时候会加入DBA,UX）
会议的时间，期望时间是两个小时
会议的内容，PO 介绍本次sprint的内容，由团队成员写出AC并且估算点数
【遇到过的问题】
1. 一个两周的sprint，PO竟然拿出差不多四周的量来介绍，最后团队成员至选择了一半的story。story的介绍就用掉了两个小时
2. 对于某个story，当PO介绍完后，铺天盖地的问题就会从团队成员口中出来，问到最后发现需求不清，这样半个小时过去了
3. 对于在planning meeting中需不需要写AC，有一次竟然争论了一个小时，最后大家都崩溃
4. PO介绍完story后的离开，留下团队成员写AC，但是真正开始写AC的时候发现问题一个个冒，最后的所有AC都打上问号
5. 有一次开会一名资深的开发不在，团队其余成员想出的解决方案第二天被这位资深开发提出质疑，团队成员一方面认为他说的有道理，另一方面为白白浪费掉的讨论时间愤怒。
6. 有一次为了以一个需求的解决方案几个开发人员都提出自己的看法，并且每个人都觉得自己很有道理，谁也说服不了谁
。。。。。
每次一到开planning meeting的时候，都像是被诅咒了一样，时间拖延的太行，互相之间争论不休，谁也说服不了谁，大家最后不欢而散。所有的道理大家都懂，团队成员对于敏捷的理解都还算很资深的，都是想更好的实践。但是一到争论的问题点时，大家又都像被魔咒了一样根本停不下来。
【目前的觉得还比较好的解决方案】
会前准备：
PO将所有的需求拆分到最小，并且会找资深点的开发refine一遍
将以前两周一个sprint缩短到一周一个sprint，让PO把注意力放到优先级最高的的story上，尽力将需求整理好
将所有的story打印到纸上，不要为公司节省这点资源。要相信，当团队成员拿这纸片分组讨论并且把想到的东西写写画画下来，比所有人盯着显示屏幕投入度高
准备好彩色的笔和便签，理由请参照上一条
将会议的agenda写到板上显眼的位置，要做到这点，需要提前跟PO讨论下这次会议需要几部分，每部分大概多久，以及是否会有额外的要决定的事情。放在显眼的位置，尤其会提醒onwer的timebox。没办法，本项目组人太活跃，根本停不下来。
会议开始
第一部分PO介绍story的时间缩短到十分钟，团队成员只问跟需求相关的问题，严禁讨论解决方案，界面以及边界值怎么处理等等问题
第二部分团队成员分组讨论story，写AC. 一组最好是两个人，一方面多个人多个视角，不过另一方面组小能增快story的讨论速度。AC不需要严格的GIVEN-WHEN-THEN的格式，只需要描述出主要点即可，这样节省时间。但是这里必然讨论到具体的方案，有界面的画出界面，有数据库的写出数据库的设计方案，边界值问题，以及是否需要与别的系统交互等等，越细越好。期间有任何不清楚的问题都要向PO提出，得到最快的答案
第三部分 一个个介绍自己手中负责story的scenarios，这个过程大家都站起来，提高效率，在介绍的过程中，任何人都有权质疑，发表意见，直到大家都没有问题位置
第四部分 每当对一个story达成共识以后，需要给出个预估的点数，如果第三部分进行的好，点数基本不会偏差太大，如果偏差太大，则证明还是没有讨论清楚，继续反复讨论直到大家点数差不多为止
会后
由一个人负责把所有会议中讨论出来的AC通过附件形式放到系统中，为之后AC Refine作准备