Scrum初体验的经验和教训

 一、写在前面

敏捷项目管理实施前，一直在倡导做项目、需求要敏捷，在保证质量的同时尽可能的快速完成开发任务，但很少有真正实践的机会。之前的需求开发流程基本如图1所示。

（图1 基本开发流程图）

该流程最大优点是需求能快速上线。需求方提出的需求，基本都希望能尽快上线。各开发针对自己开发的需求，在需求方要求的时间内完成对需求的开发，发布上线。

缺点：

1）不利于产品发展。开发人员满足于开发眼前需求，缺少对产品的整体认识，对产品发展的贡献不足；

2）不利于开发人员的成长。需求一个接一个的开发，纯粹为开发需求，缺少沉淀和总结，开发人员很累；

3）缺少团队合作。每个开发人员各自为战，欠缺开发人员之间的沟通。

二、体验Scrum

基于以上需求开发流程，我们尝试改变原有的方式，拟采用两周一迭代的敏捷开发模式。

1） 第一轮迭代

由于先前对于敏捷开发的认识并不是很足，于是乎第一次的迭代基本可用“摸着石头过河”来形容。整体周期如图2所示：

（图2 第一轮迭代周期图）

该迭代以2周为一个周期，整体开发周期为6天，2天为集成测试时间，PM资源权重为0.5。回顾这一次迭代，整个过程还是比较顺利，主要遇到以下几个问题：

1）紧急需求的插入（新增3个需求，约4人/日的工作量）；

2）对于一句话的需求，工作量评估不足（如，“XXX页面增加XX功能”需求。评估1.5人/日，实际需要3人/日。）

处理办法：

1） PM压缩部分时间投入于紧急需求的开发；分配部分任务给项目成员（其他任务完成较快的开发）；

2） 开发晚上加班处理对于工作量评估不足的需求；项目组成员共同协调处理。

总得来看，采用敏捷开发与之前的变化：1）每天晨会，开发间的沟通多了；2）开发对于整体需求认识度提升；3）项目成员开始相互协作，共同解决问题；4）紧急需求能快速响应，项目组内部消化。

2） 第二轮迭代

针对第一轮遇到的不足点（需求评估不足）以及项目开发周期的试用总结，对于第二轮迭代做了相应调整。如图3所示：

（图3 第二轮迭代周期图）

红色部分为变化的点。其中在迭代任务分配完，进行了整体需求的评审；开发周期从6天调整为7天；集成测试2天调整为1天；PM资源权重从0.5调整为0.7；项目完成后，增加了项目总结环节。

回顾该迭代，主要遇到的问题有以下几点：

1）紧急需求的插入；2）需求评审较晚，影响开发人员的开发时间；3）前端开发工作量评估不足；

针对以上问题的解决办法：

1） 周末PM加班处理紧急需求；2）相应开发加班赶进度；3）项目总结。

3）第三轮迭代

针对第二轮迭代遇到的主要问题（需求评审太迟，影响工作量评估，影响开发时间），将需求评审的时间再往前移。如图4所示：

（图4 第三轮迭代周期图）

第三轮迭代目前正在进行，已经感知到的问题有以下两个：1）需求评审还是太迟，影响工作量评估及部分开发工作；2）整个周期缺少设计环节，缺少对于技术的沉淀。

针对以上两个问题，拟对迭代再次调整。如图5所示：

（图5 拟第四轮迭代周期图）

将需求评审再次提前。需求评审完后，指定相应开发跟进需求，进行相关的设计工作，拟减轻迭代中的开发任务。

三、总结