A while back I talked to a CEO of a contract development shop. He wondered how 敏捷 could help him with fixed price, fixed scope contracts to deliver software.
当然，这些合同附带的要求永远不会完整或完全准确。首先想到的是停止订立不可能的合同。对于这位首席执行官而言，至少在目前看来，鉴于他从事业务的背景，这似乎是不可能的。
在任何固定成本/范围合同中，都有一段时间，当事双方必须就要求，交付的软件和预算的缺点进行对话。
在瀑布式交付中，所有进度报告都是代理。您报告的是无形的，未完全集成或未测试的设计，测试用例或代码。这都是关于信仰的报告，因为它尚未通过工作软件进行验证。
当提出更改请求时，无需实际使用该软件的经验。仅此而已，其影响在成本思考，修改现有工件的成本，通过代码，测试用例和文档产生的连锁影响方面将是显而易见的。通常会考虑到收益和风险，但是由于猜想，糊涂，这些收益和风险往往会受到通货膨胀的影响。确实清楚的是，变更请求流程会占用时间，批准变更将花费更多的资金。互动常常感觉像是一场拔河。一方争辩说要花更多的钱，而另一方则在平等地为另一方努力。
当关键时刻到来时（测试的尾巴很长），很明显，直到该点为止的所有进度报告都不可靠。做出前期承诺并在线签字后，您将有一个巨大的机会来建立信任。如果吹下去，就会沉没。那时，很难就实现目标进行对话，尤其是在律师介入时。
但是，如果您使用的是敏捷方法，则每隔几周演示一次小型软件。合同双方的人都看到了切实的进展。他们有机会纠正对需求的误解，并填补彼此理解中的空白。合同双方的人都可以看到并体验到需求中的缺点，因此，这不是传统变更流程所造成的拉锯战。双方都拥有更可靠的数据来进行决策。
但是，最重要的是，双方都有很多机会可以基于实际运行的软件来建立信任。
因此，当这一点到来时，当合同双方必须就实现合同目标进行对话时，这是完全不同的对话。当人们有更多选择时，关键时刻就会来临。对话将基于对进步和信任的共同理解。那是完全不同的对话。
