Waterfall中的变更控制

    尽管敏捷已经被大力推广，但涉及到合同的时候，使用Waterfall的管理仍然无可避免。尽管在Waterfall中，变更控制已经被应用和重视，但仍然有不少的项目还是要踩到这个坑。笔者最近就遇到这样一个案例。

    甲乙双方为了系统尽快上线，同意上线后再修复存在的Bug和变更。为了按时上线乙方也无条件实现了相当部分变更。然而在上线后乙方因成本困难无法修复所有问题。甲方则坚持所有问题应作为Bug修复。双方争持不下，陷入漫长的谈判。

    复盘这个项目，在执行变更控制的时候存在如下3个问题。

    1、没有严格执行变更控制流程。每一个变更都应该经过变更控制委员会（CCB，Change Control Board）去审批拒绝。并应有过程资料详细记录。而不应该由项目经理甚至开发人员自行和用户达成修改协议，随意进行变更。

    2、判断缺陷还是变更没有标准和流程。从第一个Bug或者变更出现时就应该按标准和流程去判断。Bug是要无条件修复的，变更是要额外预算和成本的。严格按照需求基线去比对判定。基线有明确描述但系统没实现的则为Bug，否则所有都为变更，需要提交CCB。这个在合同，在签署需求基线的时候就应该反复的强调、明确，并做好记录签署。

    3、必须要有变更预算。Waterfall的项目没有变更储备是不可设想的。在实施变更的时候一定要和管理层保持透明。变更储备使用情况。利用这个储备额度去限制变更。必要时，让用户进行置换，改变原来的基线。变更必须被限制。目的之一是利用这个限制，在预算之内实现高优先级的需求。防止潜变和浪费。

    最后，还是希望以后更多的软件开发项目可以使用敏捷的方法开发。避免Waterfall中各种的争执。如果真的有，那么请一开始就定好规则，按规则进行。