bigtall的敏捷日记（1）

虽然接触敏捷已经很久很久了，零零碎碎实施过，但是始终没有机会将传统的项目管理方法彻底抛弃，现在终于决定要彻底投入敏捷的怀抱了。为此我准备了整整一年的时间。我将会在这一系列的文章里，请你和我一起分享这个改变的过程。

传统的scrum方式有三个角色：产品经理(Product Owner)，scrum教练(Scrum Master)和组员(Team Member)。因为我们以产品研发为主，所以在角色上有一些改变：

• 把产品经理的角色分散到每一个组员，但是保留一个经验比较丰富的人专门对backlog进行验收
• 把scurm教练的保持SCRUM流程的那一部分职责分离出来，作为“教练”的角色。教练一般是其他部门的人（比如项目管理部）担任，负责对敏捷过程中产生的任何问题进行纠正和解答
• 保持传统的项目经理角色，负责backlog的分解和任务跟踪事项。

目前公司有两个项目在进行scrum方法的实施，A项目已经完成了两个迭代，B项目刚刚完成了一个迭代。两个项目各有特点，A项目是他们的部门经理直接找我，让我担任他们的scrum教练，而B项目则是因为被批工作分配不饱满，才找到我让我知道实施敏捷方法。正是因为前提的不同，导致了两个项目的实施效果也有一些差异。考虑到两个项目支持力度的差异，所以我也给两个项目安排了不同的实施方法。

对于A项目，我采用的方法是这样的：

• A项目除了实施Scrum之外，还加入了“结对测试”，具体的结对测试方法，可以参考我今后几天的文章
• 没有使用软件，而是使用了传统的scrum card的游戏方法，但是指派专人对数据进行同步

对于B项目，我采取的方法是这样的：

• 仅仅进行scrum方法的实施，没有结对。这么做的另外一个方法是该项目处于项目收尾和新版本开始前期的研究阶段，可以协作的工作比较少。
• 使用软件进行scrum记录

另外，两个项目都采用的方法如下：

• 前期仅对backlog进行评估point数，每个point对应0.5个工作日。但是不要求对分解的task进行评估
• 每天要开站立会议，A项目选择在早上9点，B项目选择在下午5点
• 每一个sprint开始于计划会议，结束于回顾会议
• 在回顾会议之前要有一个产品演示会议

刚才已经说了，两个项目因为采用scrum的前提不同，结果相差也比较大：

• A项目因为是自发的行为，他们的PM在此之前自己零碎实验了将近3个月，所以实施效果也相对较好
• B项目有一点临时抱佛脚的意味，所以在实施过程中比较松散和随意。

不过两者都有如下几个共同点：

• 队伍士气非常高昂，尤其是A项目，明显看到工作效率的提升
• 团队成员都比较认同Scrum的方式，认为比之前的项目管理方法有了质的提高
• 我个人感觉，只要使用了scrum方法来管理项目之后，没有人再愿意回到以前的管理方法中去了

（待续）