一次迭代式开发的研究：从容应对需求变更

前面我们已经详细描述了一次迭代式开发的完整过程，首先是项目计划的前期分析——工作量评估和优先级评估，然后是制订迭代式的项目计划，最后是按照项目计划执行项目。每天，运用Burn-Down Table监控项目进程，随时掌握项目进度的偏差（是滞后还是超前），然后制订相应的应对方案予以调整，直到最后的项目结束，一切似乎进行得比较顺利。但真实的情况往往不是这样，这里忽略了一个最重要的因素，那就是需求变更。

如果没有需求变更，我们就不需要采用迭代式开发了，瀑布模型足矣。正如我在第一章谈到的，我们的软件开发存在着风险，这个风险就是需求变更。需求变更无处不在，就如同我们人类面对的浩瀚无垠的宇宙，必须得有防护措施应对可能的风险。需求变更的防护措施是什么呢？那就是采用迭代式开发。那么，迭代式开发是怎样防护来自用户的需求变更呢？我们用一个情景剧来详细解读。

A先生是一个项目经理，他准备开始一个新的软件开发项目。他首先组织需求人员与客户一起进行了深入的需求调研，进行了详细的需求分析，最后制定出一份需求规格说明书，与客户进行签字确认。同时，他又组织了设计人员，与需求人员进行讨论，将所有的需求进行任务分解、工作量评估，以及优先级评估。随后与公司领导讨论，与客户领导协商，确定项目需要配备的人员、花费的资金，以及所需的时间。最后，一个迭代式的项目计划制订出来。

万事俱备之后，项目开始进入执行阶段。A先生制作了一个Burn-Down Table监控项目进度，开始了第一个迭代期。一切进行得比较顺利，项目顺利地完成了第一个迭代期的所有任务，顺利提交第一份交付物。正当大家认为项目会一直这样顺利地进行而喜笑颜开时，事情发生了——客户看到第一份交付物时，对一些功能不太满意，对这样那样的功能提出了修改意见，甚至还提出了新的功能——需求变更发生了。

当客户对需求提出变更时，我们往往第一反应就是记录，然后回去照着做，但很多经验证明这样是不对的。不加分析而草率地修改客户提出的变更需求，是造成客户频繁变更需求的根本原因。我们前面提过，客户提出需求的一个重要特点就是，当软件没有真正设计出来时，客户往往是说不清楚自己的真正需求的。因此，当他再次看到上次提出变更以后修改的内容，很有可能还不满意，这就意味着还要继续改，直到他满意为止。这样，反复修改是再所难免。

当客户提出需求变更时，我们首先应当弄明白的是客户为什么要提出这样的需求。这时候，需求分析员应当站在使用者角度，站在业务角度，去理解这样的需求，理解其提出来的动机。也许客户在做这个操作时要查看一些相关信息，也许这个数据和那个数据有逻辑关系，甚至其原因就是一个非计算机专业的人看到这个界面不容易理解、有误解，或者操作就有困难。

当理解了用户提出变更的真实动机以后，随后分析的就是这样的变更有没有必要，可不可实现，或者是否有更合理的解决方案。每次我们都会将一些客户提出的不合理的，或者无法实现的需求变更退回去，并且提出我们的理由。只要遣词得当、理由充分，客户往往能接受我们的建议而取消这些需求（多用建议的语气，少用命令的口吻）。而另一些变更需求，我们常常从用户表面的语言中分析出他们真实的需求，并提出一个更加合理的建议。这样做，客户不仅会欣然接收你的建议，而且会有一种你就是他肚里的蛔虫那种感觉，对你更加信任，你在客户心里的威信也就随之增加。

当客户提出变更需求，并且经过分析已经确定出修改方案以后，A先生就马上回去组织人员进行设计和开发了，殊不知这将是项目后期出现巨大隐患的重要原因。迭代式开发的正确做法应当是怎样呢？这个问题我们下回详细分解吧。

一次迭代式开发的研究：软件开发的风险
一次迭代式开发的研究：什么是迭代式开发
一次迭代式开发的研究：怎样进行迭代式开发
一次迭代式开发的研究：迭代开发从这里开始
一次迭代式开发的研究：准确的工作量评估
一次迭代式开发的研究：功能的优先级评估
一次迭代式开发的研究：一个迭代式项目计划
一次迭代式开发的研究：开始真正的工作
一次迭代式开发的研究：从容应对需求变更
一次迭代式开发的研究：需求变更的关键步骤
一次迭代式开发的研究：Where you are
（续）

评论

2 楼 fangang 2011-12-27  

按照一个比较正规的流程应当是，用户首先提出一个原始的业务需求，然后是业务调研、需求分析，完了以后才编写需求规格说明书、签订合同、制订项目计划。但是，如果项目需要招投标，那么在没有进行业务调研、需求分析的情况下，开发公司就必须要核算成本、报价、签订合同、制订项目计划。在这种情况下只能凭经验估了，这也是没有办法的事情。事实上，很多情况下，第一次投标，开发公司的目标就是拿下这个标，开价常常比成本低。

按照规定，合同一旦签订，需求就不能再变，但实际情况并非如此。在软件开发过程中，不论客户还是开发方，都有变更需求的需要，关键是变更的幅度有多大。大范围的、结构性的变更是开发方所承受不起的。但在局部的、细节上的变更是允许的，甚至是合理的。现在，一个项目下来，总是或多或少也一些需求变更。

但是，开发公司最头痛的是客户对需求总是变来变去，出现反复。出现这种情况的最重要的原因之一是客户对需求的变更考虑的不周全。当客户发现了一个需求上的问题，然后草草提出一个变更意见，过几天发现这个变更意见存在其它的问题，需求的反复变更就出现了。避免这种情况最有效的办法就是让客户对问题经过深思熟虑以后再提出来，也就是抑制客户随意提出变更。因此，一开始一定要客户在需求规格说明书上签字，之后每一次变更都要让客户走一个变更流程、签字确认，加大客户提出需求和变更的代价，可以使客户对其更加慎重，有效避免这种随意性。

项目计划也是同样的道理。如果在投标阶段没有准确把握某些需求，到需求分析阶段才发现问题并非如此简单，这时候怎么办呢？客户是人而不是机器，当你使客户意识到实际的需求比他当初提出的原始需求复杂很多时，客户更在意的是项目的成功而非那一点点时间。因此，客户会理性地调整项目计划，以保证项目最终成功。这里面的关键就是你如何与客户沟通。

1 楼 ylyxf 2011-12-27  

按照文章的解释，应该先有需求规格说明书，然后才有估算和计划。
但是前几篇文章中，博主说道需求是逐步明确的，那么在项目开始阶段的需求规格说明是不详细的，如何拿给客户签字？估算值会不会偏差过大？用户或者我们的老板往往在合同一签订以后就要计划，我还没明确做什么，也只能胡乱写计划，到时候完不成，又陷入水深火热中了。

还有，如果需求分析人员已经进厂调研，说明项目合同已经签订了，那么在签订合同前的报价是不是只能依据经验估算，而不能参考通过需求规格说明书确定以后的估算工作量？

这里的这些矛盾点我总也想不明白，希望指点一二。