两次教本一般的SCRUM会议

两次教科书一般的SCRUM会议

上周五和本周二，我经历了两次教科书一样的SCRUM会议。
背景：
我准备在公司推进敏捷项目管理方法。想办法得到了软件开发部部门经理的支持。于是乎在新立项的G维护项目中进行实验。

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

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

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

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

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

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

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

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