我们公司刚收到第一个大型开发项目的询价，我想使用敏捷开发流程。客户对应用程序有一个愿景，但坦承自己缺乏很少的需求，并认识到我们将按小时计费。因此，我已几乎让他接受了敏捷方法。
问题在于他希望有一个固定预算。我读过一些文章，基本上都不建议提供估算，因为客户会根据这个数字制定预算。即使需求发生变化，他们心中和账簿中的数字也不会改变。
我读到有许多方法可以在合同中考虑价格，但几乎所有方法（除了一个）都包含一个前期固定数字。这似乎违背了敏捷开发的全部原则。
因此，我的问题是，如果您是一个敏捷团队，您如何避免敏捷开发的这种进退两难情况？
这是一个基本的问题。
客户何时认为他们完成了？
如果他们认为在六月份完成，那么您需要建立一个敏捷团队。这是4-6人的团队，工作时间为6个月。这就是预算。基本上，您要为他们进行乘法计算。团队*费率*6个月。
如果他们认为在六月份大部分完成，但之后还有更多的工作要做，那么您可能需要9个月的工作时间。同样，您只需进行一次乘法运算，他们也可以自己计算出来。团队*费率*9个月。
如果他们认为您将成为他们可预见未来的开发团队，请给他们一个能够让项目延续到年底的价格。团队*费率*12个月。
由于每个发布都是重新设置优先级的机会，因此您应该根据每个发布中将完成的事项，将每个发布的价格定为单独的工作成果。由于这是他们的优先方案，他们控制您构建的内容，他们控制预算，逐步实施。
通常，您的客户真的想知道特定功能集的成本。但是他们问总预算（这很愚蠢）。在第一个发布中花费大量时间，展示他们能得到什么以及第一个发布将花费多少。
最终，他们会看到一个基本的真理。
他们正在按重要性从高到低购买功能。如果他们正确地设置优先级，他们可以随时停止花钱，并拥有有用的东西。
"完成"是一个相对的术语。有些项目已经“完成”，因为没有更多的资金了。其他项目已完成，因为没有更多的时间了。很少有项目（至少在软件开发中）是因为我们没有事可做而做完的。
针对这种情况，我们提供了第一块工作的估算，并让客户根据需要购买更多的迭代周期来完成所需的工作。
随着系统的开发和客户反馈的融入迭代交付成果中，您会更好地了解涉及的工作量和相关成本。
编辑：太棒了！从你已经成功地说服他们采用敏捷方法的事实来看，机会是，你可以向他们推荐采用敏捷视角来实现要求的功能。也许你可以听一下这个“Scrum介绍”播客节目。你可以向他们推销这样一个观点：他们现在可能不需要所有他们认为需要的高级功能。
希望这能有所帮助。
祝好,
罗布
看，这里有一个核心事实。您将被要求估计成本，为特定的交付日期签订合同，并承诺提供一整套的交付功能。
你不能做到所有三件事。
不是“你不应该”或“最好不要”; 你（在所有实际情况下）是做不到的。我的意思是说成功同时完成所有三个目标的概率极小。
最好的答案是承诺一个成本和进度，采用快速迭代和定期反馈的迭代过程，然后编写协议，使得在固定的成本和进度下完成的内容就是将要交付的内容。也就是说，您会不断提供新功能（和修改），直到时间和资金用尽。
事实上，即使您确实签署了所有三项，您能够达成的最好结果也只有其中的两项。还不如坦诚地说出来。
以下是我知道的一个年代久远的政府承包商的说法：“正如妓女所说，首先你得把他们领到楼上。”
这并没有回答你的问题，但值得记住。如果他们不提前看到数字就不愿意上楼（他们不会的），那么你必须给他们一个数字。
任何赞助软件项目的人都需要知道他们将在投资方面获得什么样的回报，以便评估是否值得进行投资。如果一个项目成本为100万美元，需要12个月的时间，则可能值得做。而如果它的成本为200万美元，需要24个月的时间，则可能不值得做。
真正的问题是：您能否在时间范围和预算内完成该项目，从而使客户能够实现适当的投资回报？如果您对这个问题的回答不是“是”，那么他们不应该聘请您来做这个项目。否则，他们只是在花钱和冒险。
如果您当前对这个问题的答案是“我们还不知道”，那么他们不应该聘请您来做这个项目。但这并不意味着他们不应该聘请您来找出该项目是否值得做。这个过程可以用“初步范围定义”这个好的咨询公司术语来形容。
敏捷开发是管理三个维度曲线：花费、时间和功能集。如果预算和进度已经确定，那么功能集必须是可变的。在这些限制下，您无法知道最终的功能集将是什么样子。但是，您可以知道在这些限制内，您将能够产生的功能集是否在您的客户可接受的范围内。
您可以知道这一点，并找出答案。找到这个答案是您的公司可以做而您的客户不能做到的。这是您可以为他们提供并应该收费的服务。避免诱惑去免费完成并称其为销售成本。项目范围定义与软件开发一样重要。您这样做不是为了完成销售；而是为了帮助您的客户做出他们还没有足够信息做出的商业决策。
但首先你得把他们领到楼上。
像往常一样，质量、功能和时间（=资源）是您的主要参数。我们不再折腾质量，所以只剩下功能和资源。相当多的时候，您可以通过说服某个特定数量的资源至少达到某个功能集来逃避问题。只要您能找到一个提供合理功能集的资源数量，我相信这对于相当多的客户来说已经足够了。好处在于他们可以控制进展，并且总有撤退的选择。
这是一个非常棘手的问题。请看罗伯特·格拉斯在他的书 "软件工程的事实与谬误" 中对此主题的看法。（请注意，亚马逊有新书可用，价格低于二手书！[截至2009-01-05 12:20 -08:00]；也可以在Google图书中找到。）
