迭代会议问题总结

    到目前为止我们已经经历过了7个Iteration，但每次Iteration会议都有各式各样的问题。这里做一下总结，并研究一下改进方法，供大家参考分享。

    首先简单澄清一下，我们小组的Iteration会议召开方式和方法。我们组每周是一个Iteration时间比较短，所以每周我们仅固定召开一次大会。这次大会有两大部分：1、上一个Iteration的Review Meeting。2、下一个Iteration的Planning Meeting。时间是每周五下午13:30~17:30，4个小时。第一部分2小时，第二部分2小时。第二部分视情况可延长半小时。

    下面我们逐一分析：

   第一部分：Iteration Review Meeting

   这一部分又可分为三个议程：1、Case演示。2、回顾此次Iteration。3、技术讨论。我的理解，如果用敏捷Scrum的观点来看，1,2 两个会议可以理解为是：Sprint ReviewMeeting（评审会）和SprintRetrospective Meeting（反思会）。

   1、Case演示

   问题1：此部分没有客户参加，也没有相关利益者参加，只有我们团队本身的人员参加。流程是每个开发会上台讲他自己在本次Iteration中开发的内容。但是在讲的过程当中比较凌乱，而且都是以技术角度在讲述此次Iteration开发的内容。恰恰坐在下面听的也都是技术人员，所以经常开着开着就成了技术讨论会，而不像是演示会或者评审会了。

   分析：这个会议的目的是什么？如果会议的目的真的像Scrum的评审会，那么我可以负责的说，我们目前还做不到，至少我这个项目中客户无法能在IterationReview会议上评审产品成果。所以我认为没有价值的会议可以取消，此部分可以由PM在会下做产品验证即可。

   但是如果会议的目的是想让开发也了解我们整个产品到目前为止是个什么状况了，到什么地步了。那么我建议把演示流程严格定义下来。有两种方式，1、可以有TM一人负责讲述我们这个Iteration主要开发的功能。先做简单业务背景/场景描述，再做简单的设计说明，再演示功能。只要保障我们团队都了解产品开发的功能进度即可。有技术问题可以记下，但不要再这个会议上讨论。2、还是由每个开发自己描述自己开发的部分，但是也要如同1方式一样来讲。

   问题2：会议时间无法控制。

   分析：其实这个问题是由问题1引起的，因为讨论过多的技术问题，和细节的小Bug，导致会议进程的缓慢。

   2、回顾/反思会

   问题1：经过多次会议之后，我发现，有些人还是能发现我们Iteration中存在的问题，但是提出问题后，他们不会主动去想解决方案，或者想了也想不出来。最糟糕的是，他们视乎很依赖于我，认为我最后一定会给出解决方案或者参考意见，都等着我来总结。当我问大家：“大家认为这个问题还有更好的解决方案吗？”他们会说：“那你觉得是什么？我们按你说的做不就行了？”

   分析：大家的主动性还不够。平时工作当中大家及时发现了问题也不善于总结。所以在会议上，要么就是没问题可说，要么就是说了也不能找到解决方案。以前我会让他们提出问题，然后我就一个问题诱导他们找出最佳解决方案，发现到最后都成了我强迫他们认为我的方案是最佳的，导致执行效果不佳。但是这个问题确实我还没找到更好的方法。

   问题2：会议时间不可控，要么大家没话说，很快就结束，要么大家很多问题却无法收敛，拿不出解决方案而延迟会议时间。

   分析：1、没话说，这个问题倒好解决，我会引导大家，或者干脆自己抛出问题来，让大家讨论。2、无法收敛找不到解决方案，这个问题同上问题1。

   问题3：提出了问题，也有了解决方案，但是有的问题还是无法落实。

   分析：大部分情况还是好的，比如，我们提出问题“要提高测试环境更新频率提高”结果下个Iteration我们更新为每天一次。但是有的问题就，比如“超过2小时无法解决的问题，我们要提Block”。这个问题就不能很好的落实。我的想法是，像这类问题，多次提出都无法很好解决的问题，我们应该在每次反思会的时候都要拿出来说一下，并且每次都把字体加大一号，然后每次拿出方案，分析方案为什么没有做好，分析可行性与执行力。

    第二部分：Iteration Planning Meeting

   问题1：会议时间长。最近几次会议时间特别长，原因有两个。一、需求澄清时间长。二、计划时间长。

    分析：

    一、需求澄清的时间长，主要责任是我，主要原因有：1、开发没有及时知道我们下个Iteration要开发的内容。都是在会议上才知晓。改进方法：在IterationPlanning会议之前，最少1-2天，罗列好下个Iteration可能将要开发的条目即Sprint Backlog。2、需求分析做的还不够深入，以至于很多需求问题是在会议上讨论得出。改进方法：在Iteration之前，需要对下一个Iteration将要开发的内容做深入的分析，并挖掘客户的业务价值。我可以把这个阶段的工作叫做Pre-Iteration。如下图：

   二、计划时间过长，主要责任也是我。主要原因是：我过于要求细致，对每一个Story我甚至要求他们分解到设计层面。（也表现了我对团队的不信任，这非常的不好）。目前已改正，现在的方法是，对于Story由个人来认领，或者大的Story由两个或多个人来认领，认领后，由认领人或团体自行分解Task并估算时间。而不做Task的全体估算。

    欢迎兄弟姐妹们，大哥大姐大牛们拍砖！！！