软件变更控制是软件项目管理的重要组成部分。 变更控制做得好不好软件变更管理的流程，直接影响到项目能否顺利进行。 在GJB5000A中，变更控制涉及两个过程域和三个专用实践。 我不会详细介绍标准中的要求。 我只是想补充几个我认为对变革重要的知识点。
1. 项目不应受到可能永远不会发生的潜在变化的影响。
在项目进行过程中软件变更管理的流程，项目团队有时会听到有关可能影响项目的变更的谣言。 例如：我听说大型项目计划可能需要重大调整。 只是这个改变一直都是传闻，从未真正到来。
对于这种不确定的变化，我们需要做的就是将其视为风险。 在提供紧急措施和缓解措施后，我们应该将其搁置起来，让项目按照既定计划继续推进。 这样，当变化确实到来时，我们可以按照既定的应急措施进行处理，其影响就会减少； 如果它不来，也不会影响项目计划的执行。
2.项目变更控制必须有可遵循的流程
如果项目团队提前制定了有效的流程，那么即使突然发生变化，也没什么可怕的。 只要我们按照既定的流程进行，就不会对项目产生不好的影响。 但如果没有这个改变的过程，这个改变的影响将会非常大。
一个有效的变革过程可以分为两部分：第一部分需要变革的预测和变革的风险管理；第二部分需要变革的风险管理。 第二部分要求变更遵循影响分析、申请、授权审批、变更实施、变更验证等几个步骤。
3. 变更影响分析应确保所有受影响方都参与其中
任何受到变更显着影响的人都应该为变更影响分析做出贡献：程序员提供开发估计，测试人员提供测试估计。 如果变更会显着延迟项目进度，或者影响其他团队，或者需要额外资源，那么团队领导必须参与其中。
这正是：
必须根据流程进行更改。 没有过程，危害就会很大。
影响分析师必须全面，这样决策才可信
参考文献：《程序之美》系列：团队和项目管理之美，Andrew Stellman、Jennifer Greene、Scott Berkun，机械工业出版社
作者简介：王小双长期从事GJB5000的推广、实施、评估和改进工作。 创建“软件工程思考”微信公众号，一直在“软件工程思考”中分享GJB5000、CMMI和软件工程的知识和见解。 现致力于GJB5000软件过程改进和软件工程能力提升的咨询和研究工作。
