主题：【文摘】一个关于项目管理的通俗讲解 -- 【子衿】

楼主正文中提到了变更管理，您的问题其实应该在这里面找答案。说到迭代是因为有个印象在某个帖子里您曾表示希望做一次真正的瀑布式的开发。

软件开发中有一个比较独特的东西在项目管理知识体系中难以找到对应，就是配置管理。配置管理与变更管理有相交，而变更控制其实是更大的项目范围管理的一部分。

在配置管理中，最基本的一点就是建立基线。举个例子，假设在9月1日的时候，截至当前的需求经整理得到一个版本v0.1，那么在当次迭代中，随后进行的设计、编码、测试等等工作都是基于这个0.1版的东东，就有了对应的设计v0.1，编码v0.1，测试v0.1......在所有这些工作进行的同时，需求也在发生变化并被捕捉到，而这些发生变化了的需求，就反映在v0.2中，如果不涉及对软件框架的重大影响，一般不在v0.1的迭代中涉及。只在到达v0.1的里程碑后，才考虑v0.2。

这个是比较现实的，如果动不动就放到下一个项目中去，签合同的双方都会很难受的。或者，试着将一次迭代理解成一个“子项目”您会比较容易接受？