预计阅读本页时间：-
18.固定的价格就意味着背叛承诺
“对这个 项目，我们必须要有固定的报价，虽然我们还不清楚项目的具体情况，但任要有一个标价，到星期一，我需要整个团队的评估，并且我们必须要再年末交付真个项目。”
固定价格的合同会是敏捷团队的一个难题，我们一直在谈论如何用持续，迭代和增量的方式工作。但是现在却有人跑过来，想提早知道她会花费多少时间及多少成本。
从客户方来看，这完全是理所应当的。客户觉得做软件就好比是盖一栋楼房，或者是铺设一个停车场，等等。为什么软件不能像建筑业等其他传统的行业一样呢？
广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元
也许它真的与建筑有很多相似之处------真正的建筑行业，但不是我们想象中的建筑业。根据英国1998年的一个研究，由于错误而返工的成本大约占整个项目成本的30%。这不是因为客户的需求变化，也不是物理定律的变化，而是一些简单错误。比如，横梁太短，窗户洞太大，等等。这些都是简单并且为人熟悉的错误。
软件项目会遭遇各种各样的小错误，还要加上基础需求的变化（不，我要的不是一个工棚，而是一栋摩天大楼），不同个体和团队的能力差别费城巨大（20倍，甚至更多），当然，还不停地会有新技术出现（从现在开始，钉子就变成圆形的了）。
软件项目天生就是变化无常的，不可重复。如果要提前给出一个该规定的价格，就几乎肯定不能遵守开化上的承诺。那么我们有什么可行的办法呢？
我们能做更精确的评估吗？或者商量出另一中约定。根据自己的处境，选择不同的战略。如果你的客户一定要你预想确定项目的报价（比如政府合约），那么可能你需要研究一些重型的评估技术，比如COCOMO模型或者功能点分析法（Function Point analysis）。但他们不属于敏捷方法的范畴，并且是它们也要付出代价。如果这个项目本质上和另一个项目十分相似，并且是同一个团队开化的，那么你就好办了：为一个用户开化的简单网站，也下一个会非常相似。
但是，很多项目并不像上面所说的那么如意。大部分项目都是业务应用，一个用户和另一个用户都由着巨大的差别。项目的发掘和创造需要很多配合工作，或许你可以提供稍有不同的安排，试试下面的方法。
? 主动提议先构建系统最初的、小的和有用的部分（用建筑来打个比方，就是先做个车库）。挑选一系列小的功能，这样完成第一次交付应该不多于6-8周。向客户解释，这时候还不是要完成所有的功能，而是要足够一次交付，并能让用户真正使用。
? 第一个迭代结束时客户有连个选择：可以选择一系列新的功能，继续进入下一个迭代；或者可以取消合同，仅需支付第一个迭代的几周费用，他们要么吧现在的成果扔掉，要么找其他的团队来完成它。
? 如果他们选择继续前进。那这时候，应该就能很好的预测下一个迭代工作。在下一个迭代结束时候。用户仍然有同样的选择机会；要么现在停止，要么继续下一个迭代。
对客户来说，这种方式的好处是项目不可能会死亡。他们可以很早的看到工作的进度（或者不足之处）。他们总是可以控制项目，可以随时停止项目，不需要缴纳任何的违约金，他们可以控制线完成哪些功能，并能精确地知道需要花费多少资金。总而言之，客户会承担更低的风险。
而你所做的就是在进行迭代和增量开化。
基于真实的评估。让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。
切身感受
你的评估数据会在整个项目中发生变化------他们不固定的。但是，你会觉得自信心在不断增加，你会越来越清楚每个迭代可以完成的工作。随着时间的推移，你的评估能力会不断的提高。
平衡的艺术
? 如果你对答案不满意，那么看看你是否可以改变问题。
? 如果你是在一个基于计划的非敏捷环境中工作，那么要么考虑一个基于计划且非敏捷的开化方法，要么换一个不同的环境。
? 如果你在完成第一个迭代开化之前，拒绝做任何评估，也许你会失去这个合同，让位于哪些提供了评估的人，无论他们做了多么不切实际的承诺。
? 敏捷不是一味着“开始编码，我们最终会知道何时可以完成”。你仍然需要根据当前的知识和猜想，做一个大致的评估，解释如何才能到达这个目标，并给出误差范围。
? 如果你现在别无选择，你不的不提供一个固定的价格，那么你需要学到真正好的评估技巧。
? 也许你会考虑在合同中确定每个迭代的固定价格，但迭代的数量是可以商量的，他可以根据当前的工作状况进行调整 [又名工作条款说明（Statement of Work）]。
