您的位置:首页 > 其它

需求变更管理

2013-04-26 09:21 134 查看
  需求变更频繁在困扰软件开发团队问题中排名第一,实际工作中不乏先例。《软件需求最佳实践》中“需求变更操作实务”讲到了如何管理需求变更,简单梳理一下。、

基本理念

  需求变更来源主要有两种:一是捕获信息不全面,分析结果不正确;二是世界变化快,业务需求发生了变化。对于算量产品而言,前者占80%以上,所以做好自己,管好自己更重要些。

  管理需求变更的目标不是避免变更,而是控制变更。控制变更的意义在于减少变更对开发工作的影响。

  如何控制需求变更呢?有两个方面的工作:统一渠道(变更管理委员会)、统一平台(变更管理系统)。之前一直没有做好需求变更工作,一是没有统一渠道和统一平台,二是没有做好需求变更的甄别工作。

  什么样的需求变化是需求变更需要明确下来,这是需求变更甄别要做的事情。简单的说,因需求变化引起开发工作量变化的,并且变化超过某个定量的情况,都应该被认为是需求变更。因此“某个定量”是多少,需要“变更管理委员会”确定下来,并且坚持执行下去。

统一渠道

CCB背后的道理

  为什么需要建立CCB(需求变更管理委员会)?因为这样可以有效避免“多对多”的沟通,可以有效减少“来路不正”的变更。

  CBB的核心人员只有两个,分别代表用户团队和开发团队(需求主管和开发主管),其他人员都是协作者和决策者。

  如何有效执行CCB呢?最重要的要避免研发团队走所谓的“捷径”。当需求变化引起了开发人员工作量发生变化时,必须要求开发人员将此项变化提交至CCB,经CCB决策后再做响应。

变更处理过程

  业务影响度分析是变更分析的首要任务:该需求变更是否必要?若必要它有什么样的优先级?

确定影响范围:一是行为需求类变更,二是数据、规则类变更;

选择正确的评价者;

对变更从现有业务影响程度做出评价;

  技术影响度分析主要策略有两个方面:

修改型变更:罗列出影响的数据、界面、类、方法等,逐项进行分析;

新增型变更:采用类比法,找一个规模难度相当的功能进行工作量评估;

  项目影响度分析基于上述两个维度,要考虑到成本和进度进行决策。

  是否打破基线呢?原则上不打破,但这个原则的前提是“基线划分合理”、“需求捕获正确”的前提下。若新增需求优先级更高,可以采用置换的方法,从原有基线中换回一个工作量相当的任务。若工作量较小,重要性很高,则直接加入基线。

统一平台

  变更管理平台主要提供以下一些功能:

变更的生命周期管理,从提出、评估、接受、实现到最终验证,全过程跟踪;

权限管理;

变更的分类和分析功能,对需求进行不断的分类,统计出“变更类型”的前几位再进行有针对性的应对,是管理变更的重中之重。

  《软件需求最佳实践》介绍了一些系统,比如Clear Quest,Mantis,BugFree,其实现在公司使用的JERA也基本可以实现需求变更的管理。

  需求变变更的目标是控制变更的影响,一方面我们要避免错误,另一方面是要提高变更的预测能力。“前车之鉴,后事之师”,不管从哪个角度讲,我们都需要对变更的历史进行分析。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: