需求变更管理

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

基本理念

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

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

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

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

统一渠道

CCB背后的道理

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

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

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

变更处理过程

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

1. 确定影响范围：一是行为需求类变更，二是数据、规则类变更；
2. 选择正确的评价者；
3. 对变更从现有业务影响程度做出评价；

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

1. 修改型变更：罗列出影响的数据、界面、类、方法等，逐项进行分析；
2. 新增型变更：采用类比法，找一个规模难度相当的功能进行工作量评估；

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

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

统一平台

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

1. 变更的生命周期管理，从提出、评估、接受、实现到最终验证，全过程跟踪；
2. 权限管理；
3. 变更的分类和分析功能，对需求进行不断的分类，统计出“变更类型”的前几位再进行有针对性的应对，是管理变更的重中之重。

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

　　需求变变更的目标是控制变更的影响，一方面我们要避免错误，另一方面是要提高变更的预测能力。“前车之鉴，后事之师”，不管从哪个角度讲，我们都需要对变更的历史进行分析。