Scrum初体验

jopen 10年前

敏捷项目管理我们团队已经试行了近三轮,现将在实践过程中的体验分享给大家。

一、写在前面

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

Scrum初体验

(图1 基本开发流程图)

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

缺点:

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

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

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

二、体验Scrum

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

1) 第一轮迭代

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

Scrum初体验

(图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所示:

Scrum初体验

(图3 第二轮迭代周期图)

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

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

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

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

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

3)第三轮迭代

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

Scrum初体验

(图4 第三轮迭代周期图)

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

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

 

Scrum初体验

(图5 拟第四轮迭代周期图)

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

三、总结

    以上迭代流程并不是最优,还在不断地实践中优化。总体感觉,敏捷开发是不断自我进化的一个过程。通过不断地实践,在实践过程中进行不断地总结,不断完善和优化,使项目朝着健康、有序、向上的方向发展。

来自:http://www.cnblogs.com/xjk15082/archive/2012/09/25/2702165.html