项目需求的变化是项目管理中最令人头疼的事情了，而且如果变更的管理和控制不好的话，往往还会导致项目组内部的开发管理的混乱，降低了软件开发的效率，增加项目的成本，甚至会导致项目的失败。
以变更为核心的项目开发管理适合以下类型的项目：
生命周期划分不是很明显的;
需求和范围不清晰，可能会频繁变化的;
大型的应用项目;
产品化持续开发的项目。
这些项目的特点是都不能按照基本的软件开发的生命周期模型按部就班地实施开发，即便是按照生命周期模型划分为各个里程碑或者阶段，往往由于客户方或者外界频繁的变化，导致项目组疲于应付这些外界的变化，而内部项目组在任务分配、工作检查或角色分工上会不同程度地陷于混乱状态。项目管理也往往会比较被动。
当然这种情况一般比较适合项目或者产品研发的中后期，前期的工作一般还都是比较整块的任务。
那么如何解决这个问题呢?实际上很多模型已经给出了答案，比如RUP、XP等，但是大家在学习和使用这些模型的时候，往往觉得这些模型提出的概念和实施比较难以操作和实施，另外就是不管是RUP还是XP，既然是一个方法模型，就不可避免要描述为一个完整的、系统化的理论模型，否则就体现不出理论的完整和逻辑的严谨。下面我们只是把以变更为核心的开发管理流程化，避免在频繁发生外界变化的情况下便被动为主动。
项目到了后期，这时候客户参与的也比较多，因此客户的需求变化也会比较多。另外随着测试的深入，测试发现的问题都需要项目组来处理和解决。因此我们把项目的某一个版本作为一个基线，后续的任务，不管是新的需求、变更的需求、缺陷修改还是其他的对系统的完善、升级、优化等等，都统一为一个Update，这儿只所以不叫CR(Change request)或者MR(Modify Request)是因为大家习惯把变更请求是作为被动的任务，甚至是当作项目范围的变化，而很少把变更看做项目任务的管理模式。因此我们把Update就定义为任何对现有系统的修改的工作。
每个变更类似一次小的瀑布的迭代开发，不同的迭代可以并行，关于配置的版本要管理好各个版本的分支。这个是非常重要的，不然版本的问题将会成为项目的定时炸弹。
文章来源于领测软件测试网 https://www.ltesting.net/