上周五和本周二，我经历了两次教科书一样的SCRUM会议。

cu_Cbear

转：redouble

上周五和本周二，我经历了两次教科书一样的SCRUM会议。

背景：
我准备在公司推进敏捷项目管理方法。想办法得到了软件开发部部门经理的支持。于是乎在新立项的G维护项目中进行实验。

上周五下午，是G维护项目的一次迭代汇报会议。
会议中，我帮助项目组成员回顾了已经完成的工作，同时分析了工作没有按照计划完成的原因。会议的效果如下：

1.下一次迭代的估算时，每个成员每周流出1天的工作量来应付突发的事件。
2.讨论出了若干实际的方法来解决项目中出现的沟通的问题。

本周二上午，是G维护项目的迭代规划会议。会议中：

1.先约定了以后会议的一些常态规范和约定
2.计算了本次迭代项目组所有可用工作量的小时数
3.请产品经理按照优先级的顺序给大家讲解需求
1.产品经理由于没有按照部门规定的用例格式书写需求条目，被部门经理严重批评
2.过程中，我尽量的引导了所有项目组成员对需求条目进行讨论和澄清
4.针对每一条需求，项目组成员进行了DELPHI的估算方式
1.估算以小时数为单位，而不是功能点
2.针对每一条的估算分割成了开发和测试两部分
5.由于有另外一个产品经理的需求还需要占用项目组的时间，因此要求两个产品经理对需求条目进行合并，并对优先级进行了协调。
6.项目组成员对本迭代的需求进行了认领
1.开发经理也会承担一部分开发任务。按照原来的计划方式，开发经理会承担很多难度较大的需求条目。工作量过载会导致开发经理成为瓶颈。采用这样的计算方式，避免了出现上述的问题。其他的开发人员帮助开发经理分担了工作。
2.测试人员只有一名，但是测试的工作量已经溢出，因此要求开发人员分担了一些测试执行的工作。
3.最终达到了工作量的大致平衡分布。

当然，规划会议中也出现了一些问题：

1.对于某一条需求，分割粒度不够。有两个开发人员估算了40小时，开发经理估算了20小时。按照一般的约定，应该由产品经理再次分割指16小时之内。但是强势的部门经理坚持认为该需求不能在分割了。基于当时的环境，我没有坚持。
2.还是针对该条需求，开发人员的估算存在明显的分歧（包括部门经理在内），出现了短暂的紧张气氛。由于我意识到该条需求具有明显的潜在认领者（开发经理），因此我也没有坚持针对他的估算必须达成一致。
3.针对于需求的描述格式。由于部门内部发布了用例的规范格式，因此当然要求产品经理进行遵守。但是针对这个特定的项目（用户的角色非常单一），我们都发现，描述功能比描述场景可能更加合适。因此，在日后的改进工作中，有必要发布用户故事的格式规范。
4.在浏览需求条目时，发现了不同的需求条目之间存在着依赖关系，即某需求的开发的开始和估算依赖于另外一条需求。我在本次会议中没有处理这个情况。我觉得这其实是由于被依赖的需求条目还需要被拆分。但是，我准备在下一次迭代中再处理这种情况。
5.本次规划中发现需求来源于两个产品经理。这一次虽然协调的比较顺利，但以后还是需要尽量避免。

虽然出现了一些问题，但是我还是对这两次会议非常满意了！关于部门经理非常强势的问题，由于本次实验部门经理也非常支持，因此我会在以后的私下聊天中，逐步改变部门经理的管理方式。

感谢以下一些图书的作者：
《SCRUM敏捷项目管理》
《SCRUM敏捷项目管理实战》
《硝烟中的SCRUM和XP》
《敏捷无敌》
《敏捷估计与规划》