变更（CR，Change request）管理是项目管理中的最重要过程之一。
一个项目，从开始就处于不停的变化中。用户需求变了需要调整计划或者设计；测试发现了问题需要对错误代码进行变更；甚至人员流失了，也需要项目进行一定的调整以适应这种情况。Bug管理，需求管理，风险控制等本质上都是项目变更的一种。它们都是为了保证项目在变化过程中始终处于可控状态，并随时可跟踪回溯到某个历史状态。
孤立的看单个变更（CR）的生命周期，那么它是比较简单的，大致就是提出-审核-修改这么一个过程。但变更管理并不是单纯的一个数据库记录，做个备忘而已。在这么一个简单的流程中，变更管理要能体现出它的两个重要用途，一个是控制变更，保证项目可控；一个是变更度量分析，帮助组织提供自己的开发能力。
为了保证项目可控，项目管理者要充分了解变更的信息，衡量变更实施对项目的冲击，才能决定是否要修改。比如问题是否严重必须马上得到修改，问题的修改是否很复杂，是否会牵扯到很多方面。这些信息，大致可以归为俩类，一类是变更的自身信息，比如复现步骤等；一类是关联信息，比如某个功能变更实施后，对项目其它模块的影响分析，这类信息通常不可能由变更提出人来提供，而需要变更审核者结合多方面信息进行分析。
实施变更管理的一个更重要且更有意义的作用就是对变更进行度量分析。
在项目进行过程中，对变更进行分析，可以很好的了解项目当前质量状态（如果你承认统计学有它的科学性，那么你就会承认，项目各阶段的合理变更发展情况是有确定的分布形态的）；定时进行项目复盘，分析组织中变更的产生原因和解决方法，及时了解组织中常见错误并有针对性的改正，才能促使组织的开发能力不断得到提高。在CMM五级中，缺陷预防就是一个最重要的过程域，而要进行预防缺陷，离不开对历史项目的变更分析。如何分析变更数据是一个比较大的课题，它甚至和项目特点相关。我将在以后的文章中继续探讨这个问题。
变更的流程：
我们看下变更生命周期中的几个主要过程和这些过程的要求
提出：记录变更的详细信息，相当于一个备忘。需要记录的信息可能根据不同组织和不同项目的规定而不同。要点在于变更提出者能简明扼要的记录下有价值的信息，比如缺陷发生时的环境，要变更的功能……。
变更管理工具不仅要能方便的记录信息，而且要给记录者一些记录的提示信息，帮助记录者准确的记录变更。
审核：审核者首先要确认变更意义，确认是否要修改；其次审核者要确认变更可能产生的影响，根据影响分析决定是否要修改下变更的内容以及对项目其它方面做同步改变；最后就是指派项目成员实施该变更。
在这里，关键是审核者要能对变更的相关影响有清楚的认识，这认识并不是说如何修改变更，而是如果修改了该变更，有可能带来什么影响，是否值得修改。很显然，这些信息不是变更提出者在记录时会给出的，而应该是审核者自己辅助其它系统或者工具进行判断。
首先要保证修改实施是完全而彻底的，比如提了一个需求变更，不能只改了需求文档而不改代码或者用户文档。在组织分工情况下，如何协调多个小组的同步变更保证工作产品一致性正成为一个很严峻的问题。
实现变更的一个初始目的就是为了项目的跟踪回溯，那么，针对变更而做的修改也应该被记录下来并被和变更关联起来，实现whywhat的双向跟踪。
确认：确认验证变更确实得到了确实实施（或者拒绝变更的理由是合理的）。
U633687664
U582679646
