10.1 变更管理的理念
需求变更的根源无非两种：第一种是我们错了，捕获的信息不全面，分析结果不正确等。第二种是业务变化了。因此我们应该尽可能避免犯错，同时加强预测。但需求变更最终还是无法避免的。
》变更管理的目标是控制变更，而不是避免变更。
》控制变更的目的，则是减少变更对开发工作的影响。
想要对变更进行有效地控制，最重要的就是两个方面：
》统一渠道。如果对变更没有集中处理，那么想对其进行有效的控制就根本无从谈起。针对同一渠道，大部分做法是CCB。
》统一平台。如果所有变更都没有有效的记录，分析，那么就很难对其进行合理的分析。正对统一平台，大部分做法是“变更管理系统”。
10.2 统一渠道
统一渠道的两个主要原因：
》变更可能是相互冲突的。如果变更渠道不统一，可能会引发新的问题。
》变更量无法引起重视。统一渠道能更好的统计变更工作量，让客户意识到变更的成本，减少来路不正的变更。
10.2.1 CCB背后的道理
10.2.1.1 正确认识CCB
CCB的核心成员只有两个，分别代表用户团队和开发团队，其他组成人员都是协作者和决策者。因为对于所有变更而言，这两位并非都能做出最终的决定。
10.2.1.2 使CCB称为真正的统一渠道
很多情况下，客户代表并不把需求提交给CCB，而是直接提交给开发团队，从而是CCB形同虚设。其背后的原因，主要是客户对沟通成本理解的问题。
10.2.2 变更处理过程
(对于变更处理过程，PMP的变更处理流程或许更完善。)
10.2.2.1 值得关注的问题是，变更是否能够打破基线。
通常来说，变更都是不允许打破基线的。但也有一些例外情况：
》出现了影响生产的需求，或者需求变更项的优先级比基线内优先级更高时，通常都是使用置换法，从基线中换回一个工作量相当的任务，将其放到下一轮迭代中。
》出现了对前面假设有巨大影响的变更：暂停迭代，重新考虑基线。
》工作量较小，重要性或者跟基线内需求的关联性非常强：直接加入基线。
10.3 统一平台
10.3.1 变更管理平台的选择
在选择变更管理平台时，有以下几个方面的功能是很重要的：
》支持变更的生命周期管理，即从提出，评估，接受，实现，到验证，实现全过程的管理和跟踪，还应该支持重新激活等。
》有效的权限管理体系，让需求变更的提出者，评价者，实现者能在同一平台中各取所需。
》分类和分析功能。能对变更进行自定义分类，在此基础上提供相应的查询分析功能。
这里推荐的平台包括：Rational的ClearQuest，开源的Mantis，免费的BugFree等。
10.3.2 变更管理平台的应用要点
千万不要谈及变更就说变更数量，更重要的是对变更进行分类，统计，分析。(这也是快速软件开发中非常强调的点)
