最近和朋友吃饭,讨论到软件测试方面的问题,这位仁兄也是经验不足,像我抱怨好不容易按照之前评审的需求写完Case,现在又变更这么多需求,又得重新梳理需求写Case。其实参与过项目研发的人员都非常清楚,项目一旦启动,需求变更也会随之而来,需求变更是无法避免的。
不瞒大家,像博纳移动这么强大的研发团队,在项目启动之后变更需求也是常事。就拿最近V-3.4万能考勤开发过程的事情来说吧。万能考勤有个导出排班表的功能,排班表是以EXCEL形式展示的,这里涉及到排班表成员排列顺序的问题,当初原型评审时候,评审会议参与人员也都没有提到这个关于成员排序的详细需求,然后开发就默认按照创建班长时选择成员的顺序来展示了。待这个功能已经收尾的阶段,广州团队的产品经理突然提出,希望排班表导出后成员的排列顺序能由操作人员自己去选择。像遇到这种情况,这种需求是否需要直接加入当前Sprint计划呢?那么我们应该怎样来处理项目中出现的变更需求呢?最好的办法是建立一套正规的程序对项目的变更进行有效的控制。
参与项目这么长时间,结合平时的处理情况,我也总结了一下:
(1)评估变更对项目的影响:如果属于变更需求,进行分析,变更会对项目成本、进度、质量等因素产生哪些影响;
(2)设计变更的备选方案:列出几种可能的变更处理方案,比如说非常紧急的变更需求马上批准,而对项目影响较少的变更可以稍后再处理;
(3)提出变更申请:正式提出书面的变更申请需求;
(4)征求项目干系人的意见:所有与变更有关的项目干系人;
(5)提交相关项目管理人员,批准或者否则项目变更;
(6)追踪变更的实施情况:变更批准后,我们需求跟踪变更的执行情况,并且要记录在案。
时间: 2024-10-05 04:09:40