前面我们已经详细描述了一次迭代式开发的完整过程，首先是项目计划的前期分析——工作量评估和优先级评估，然后是制订迭代式的项目计划，最后是按照项目计划执行项目。每天，运用Burn-Down Table监控项目进程，随时掌握项目进度的偏差（是滞后还是超前），然后制订相应的应对方案予以调整，直到最后的项目结束，一切似乎进行得比较顺利。但真实的情况往往不是这样，这里忽略了一个最重要的因素，那就是需求变更。
如果没有需求变更，我们就不需要采用迭代式开发了，瀑布模型足矣。正如我在第一章谈到的，我们的软件开发存在着风险，这个风险就是需求变更。需求变更无处不在，就如同我们人类面对的浩瀚无垠的宇宙，必须得有防护措施应对可能的风险。需求变更的防护措施是什么呢？那就是采用迭代式开发。那么，迭代式开发是怎样防护来自用户的需求变更呢？我们用一个情景剧来详细解读。
A先生是一个项目经理，他准备开始一个新的软件开发项目。他首先组织需求人员与客户一起进行了深入的需求调研，进行了详细的需求分析，最后制定出一份需求规格说明书，与客户进行签字确认。同时，他又组织了设计人员，与需求人员进行讨论，将所有的需求进行任务分解、工作量评估，以及优先级评估。随后与公司领导讨论，与客户领导协商，确定项目需要配备的人员、花费的资金，以及所需的时间。最后，一个迭代式的项目计划制订出来。
万事俱备之后，项目开始进入执行阶段。A先生制作了一个Burn-Down Table监控项目进度，开始了第一个迭代期。一切进行得比较顺利，项目顺利地完成了第一个迭代期的所有任务，顺利提交第一份交付物。正当大家认为项目会一直这样顺利地进行而喜笑颜开时，事情发生了——客户看到第一份交付物时，对一些功能不太满意，对这样那样的功能提出了修改意见，甚至还提出了新的功能——需求变更发生了。
当客户对需求提出变更时，我们往往第一反应就是记录，然后回去照着做，但很多经验证明这样是不对的。不加分析而草率地修改客户提出的变更需求，是造成客户频繁变更需求的根本原因。我们前面提过，客户提出需求的一个重要特点就是，当软件没有真正设计出来时，客户往往是说不清楚自己的真正需求的。因此，当他再次看到上次提出变更以后修改的内容，很有可能还不满意，这就意味着还要继续改，直到他满意为止。这样，反复修改是再所难免。
当客户提出需求变更时，我们首先应当弄明白的是客户为什么要提出这样的需求。这时候，需求分析员应当站在使用者角度，站在业务角度，去理解这样的需求，理解其提出来的动机。也许客户在做这个操作时要查看一些相关信息，也许这个数据和那个数据有逻辑关系，甚至其原因就是一个非计算机专业的人看到这个界面不容易理解、有误解，或者操作就有困难。
当理解了用户提出变更的真实动机以后，随后分析的就是这样的变更有没有必要，可不可实现，或者是否有更合理的解决方案。每次我们都会将一些客户提出的不合理的，或者无法实现的需求变更退回去，并且提出我们的理由。只要遣词得当、理由充分，客户往往能接受我们的建议而取消这些需求（多用建议的语气，少用命令的口吻）。而另一些变更需求，我们常常从用户表面的语言中分析出他们真实的需求，并提出一个更加合理的建议。这样做，客户不仅会欣然接收你的建议，而且会有一种你就是他肚里的蛔虫那种感觉，对你更加信任，你在客户心里的威信也就随之增加。
当客户提出变更需求，并且经过分析已经确定出修改方案以后，A先生就马上回去组织人员进行设计和开发了，殊不知这将是项目后期出现巨大隐患的重要原因。迭代式开发的正确做法应当是怎样呢？这个问题我们下回详细分解吧。
一次迭代式开发的研究：软件开发的风险
一次迭代式开发的研究：什么是迭代式开发
一次迭代式开发的研究：怎样进行迭代式开发
一次迭代式开发的研究：迭代开发从这里开始
一次迭代式开发的研究：准确的工作量评估
一次迭代式开发的研究：功能的优先级评估
一次迭代式开发的研究：一个迭代式项目计划
一次迭代式开发的研究：开始真正的工作
一次迭代式开发的研究：从容应对需求变更
一次迭代式开发的研究：需求变更的关键步骤
一次迭代式开发的研究：Where you are
（续）