我的公司刚刚收到了第一个大型开发项目的询盘，我想使用敏捷过程。客户对应用程序有远见，但公开承认要求很少，并承认我们将不得不按小时收费。正因为如此，我几乎把敏捷方法卖给了他。
问题是他想要一个数字来预算。我读过很多文章，它们几乎都主张不要放弃估算，因为客户会为这个数字做预算，即使需求发生变化，他们头脑中和书中的数字也不会改变。
我读过有很多方法可以在合同中考虑定价，但几乎所有方法（除了一个）都包含一个预先编号。这似乎违反了敏捷开发的整套原则。
所以我的问题是，如果您是敏捷开发者，您如何设法规避敏捷开发的 Catch-22？
这是基本问题。
客户什么时候会认为他们已经完成了？
如果他们认为他们会在 6 月份完成，那么你就可以组建一个敏捷团队。那是4-6人6个月。这就是预算。本质上，您为它们进行乘法运算。团队 * 费率 * 6 个月。
如果他们认为他们将在 6 月份完成大部分工作，但在那之后会有更多的工作，那么你可能会看到 9 个月的工作。同样，你只是在做一个他们可以为自己做的乘法。团队 * 费率 * 9 个月。
如果他们认为您将在可预见的未来成为他们的开发团队，请给他们一个价格，以使项目能够持续到年底。团队 * 费率 * 12 个月。
由于每个版本都是重新确定优先级的机会，因此您应该根据您将在该版本中完成的工作将每个版本定价为单独的工作。由于这是他们的优先计划，他们控制着你建造的东西，他们控制着预算，分阶段进行。
通常，您的客户真的想知道特定功能集的成本是多少。他们没有问这个，而是询问总体预算（这很愚蠢）。在第一个版本上花费大量时间来展示他们得到了什么以及第一个版本的成本。
最终，他们会看到根本的真相。
他们购买的功能从最重要到最不重要。如果他们正确地优先考虑，他们可以随时停止花钱并拥有一些有用的东西。
完成是一个相对的术语。有些项目“完成”了，因为没有钱了。其他的已经完成了，因为没有更多的时间了。很少（至少在软件开发中）是一个项目曾经完成，因为我们没有事情可做。
对于这种情况，我们提供了第一块工作的估算，然后让客户根据需要购买更多的 sprint，以将工作完成到所需的水平。
随着您开发更多系统，并将来自客户的反馈纳入 sprint 可交付成果，您将对所涉及的工作量以及所涉及的成本都有更好的感觉。
编辑：酷。太棒了！从您以敏捷方法出售它们的事实来看，顺便说一句，这很好！，您很可能能够从敏捷的角度在要实现的功能方面看到它们。或许可以收听这个“ Intro to Scrum ”播客。您可能可以出售他们，因为他们可能不需要拥有他们认为现在需要的所有花里胡哨。
高温高压
干杯，
抢
看，这里有一个核心事实。您将被要求估算成本、签订特定交付日期的合同，并承诺交付一整套功能。
你不能同时做这三个。
不是“你不应该”或“最好不要”；你（出于所有实际目的）不能。我的意思是成功完成这三个方面的可能性非常小。
最好的答案是承诺成本和进度，以及具有快速迭代和定期反馈的迭代过程，然后编写协议，以便在固定成本和进度下完成的工作就是交付的内容。也就是说，您不断提供新功能（和修改），直到时间和金钱用完为止。
事实是，即使您确实注册了所有三个，您所能做的最好的事情就是三分之二。不妨对此持开放态度。
最近我认识的一位脾气暴躁的老政府承包商是这样说的：“正如妓女所说，首先你得把她们弄上楼。”
这并不能回答你的问题，但值得记住。如果他们不会在前面没有号码的情况下上楼（他们不会），你必须给他们一个号码。
任何赞助软件项目的人都需要了解他们将从投资中获得什么样的回报，以便他们能够评估投资是否值得。如果一个项目花费 100 万美元并需要 12 个月，那么它可能是值得做的。如果它花费 200 万美元并且需要 24 个月，那么它可能不值得做。
真正的问题是：你能否在一个时间框架和预算内完成这个项目，使客户有可能获得适当的投资回报？如果你对这个问题的回答不是“是”，那么他们不应该雇佣你来做这个项目。否则，他们只是在花钱和掷骰子。
如果你目前对该问题的回答是“我们还不知道”，那么他们不应该雇佣你来做这个项目。但这并不意味着他们不应该雇用您来确定该项目是否值得做。一个很好的咨询公司流行语是“初步范围界定练习”。
敏捷开发是关于管理三个维度的曲线：花费的金钱、日历时间和功能集。如果预算和时间表是固定的，那么功能集必须是可变的，这是一个假设。鉴于这些限制，您无法知道最终的功能集是什么。但是您可以知道您能够在这些限制内生成的功能集是否在您的客户认为可以接受的范围内。
你可以知道这一点，你可以找到它。找出这一点是您的公司可以做而您的客户做不到的事情。这是您可以提供给他们的服务，他们应该为您付费。避免免费这样做的诱惑，并将其称为销售成本。项目范围界定与软件开发一样是专业服务的一部分。您这样做不是为了完成销售；您这样做是为了帮助您的客户做出他们还没有足够信息可以做出的商业决策。
但首先你得让他们上楼。
这些答案真的很棒。我没有太多经验可以分享，但我想到了一个比喻：
去年，我和妻子改造了我们的厨房。承包商建议按时间和材料计费，而不是给出估计，因为我们不知道我们会发现与管道、底层地板损坏等有关的情况。我们同意了，因为我在家工作，而且我可以不断地回答问题。承包商和我关系很好，所以当有事情发生时，他可以随意敲我办公室的门，我们会讨论一下。很快就做出了决定，并按照我想要的方式完成了工作。这似乎类似于频繁客户审查的敏捷优先级。
相比之下，我妻子的表弟也在改造他的房子。他是一名急诊室医生，在改造期间他不在现场。所以他描述了承包商在没有咨询他的情况下做出重大决定时经常感到惊讶（“什么？我不希望那扇窗户被挡住！把墙拆掉，把窗户改成原来的样子！”）。这当然是非常昂贵的，并且会破坏时间表。绝对不是敏捷。
因此，让客户相信时间和材料模式会起作用的一种方法可能是向他们保证，您会经常进行进度报告以获取他们的反馈。我相信这已经是大多数敏捷方法的核心建议。首先，这当然需要客户信任顾问。
作为一个单独的资源，我搜索并找到了一本关于这个主题的书：Mike Cohn 的“敏捷估计和规划”。阅读该页面上来自一群令人印象深刻的敏捷专家的赞美语。
首先，我想说我认为你向他推销了一种敏捷方法和按小时定价，这很棒。这很难做到。
关于您的困境，我认为您应该向他提供一个粗略的定价估计及其包含的功能/范围。在开发过程中，如果你看到一些重要的东西会改变范围/成本，你对客户说“停止——这很好，但要理解它改变了我们讨论的原始范围。”
在这一点上，客户有权同意，意识到他将支付比他最初想象的更多的钱，或者暂时停止新的开发。许多敏捷项目是在许多小阶段构建的——您可以为此给出非常准确的价格/时间估计。在任何新的小阶段开始之前，重要的是您和客户要就接下来发生的事情以及将花费多少时间/成本达成一致意见，这一点很重要。
与往常一样，质量、功能和时间（=资源）是您的主要参数。我们不再搞质量问题，所以只剩下功能和资源了。通常，您可以说服一定数量的资源至少会达到某个功能集而侥幸逃脱。因此，只要您能找到大量资源来提供合理的功能集，我相信这对于相当多的客户来说已经足够了。好处是他们可以在移动时控制进度，并且总是可以选择退出。
我这样做的方法是使用我当前的速度并根据对复杂性（故事数量）的粗略估计来估计一个范围。您将在开始规划应用程序时对其进行更新，以便范围估计逐渐变得越来越好。
例如，给出 6mos 到 2 年的估计（如果你确定它需要的时间少于 2 年。当你把它分解成特征，然后为这些特征做计划时，你会提出越来越好的估计，所以6mos 后你可以可靠地说（没有任何其他变化），我们将在另外 2-3 个月内完成（总共 8-9 个月）。最终，你可以说，我们会在下一次迭代后完成（2 周到 1 个月）。
您需要将此与让客户知道添加功能会增加完成时间相结合，然后让他们决定如何继续 - 要么放弃功能，要么增加时间。对于任何给定的项目，范围和时间确实是您可以有效改变的唯一变量。质量和资源几乎是固定的。实际上，您可以添加资源，但通常您最初会看到时间增加而质量下降，因此这仅在您的时间范围很长时才有效。
这是一个非常棘手的问题。看看 Robert Glass 在他的“软件工程的事实和谬误”一书中对这个主题的看法。（请注意，亚马逊的新书价格低于二手书！[截至 2009-01-05 12:20 -08:00]；谷歌图书也有。）
您可以采取的一种方法是给客户一个您认为相对接近的一般估计。也给个百分比。由于需求的变化，该百分比将是预算中的增加或减少分配。
示例：一般估计为 10,000 美元，但由于要求不明确且项目可以轻松改变路线，因此可以选择 +/- 30% 的价格调整选项。
通过这种方式，客户可以大致了解预算内容，并且您可以灵活地为项目收费。
如果您已经成功地向客户推销了敏捷方法，并按小时计费，不要给他们估计完成项目的成本！. 即使他们说他们只想要它用于预算目的，也不要这样做！.
原因是任何成本估算都将被视为明确的承诺；不管你说多少次不明白，客户说多少次他们明白这一点，都将被视为一种承诺。即使客户明白，他们的老板也不会明白，虽然他们不能合法地强迫你按你说的价格交货，但你会被称为一家没有兑现承诺的公司。提供估计首先会放弃敏捷的所有优势。
我的建议是告诉他们，在财政年度结束之前（或客户感兴趣的任何其他计费期），您将花费不超过某某金额。这应该足以让他们进行财务计划，而无需以任何方式说该项目将在那时完成。
当我切换到积分时，我决定只有满足以下两点；1）找到并论证证明转换的合理性并说服团队 2）找到一个简单的方法来使用它。
令人信服
我花了很多时间阅读这个主题，但最终找到了让我和我的团队信服的论点：几乎不可能找到两个程序员会同意一项任务所需的时间，但同样的两个程序员几乎总是会同意当显示两个不同的任务时，哪个任务最大。
这是您“估计”积压工作所需的唯一技能。在这里我使用了“估计”这个词，但在这个早期阶段，它更像是把积压工作从难到容易排序。
在积压工作中加分
这一步是在整个 Scrum 团队的参与下完成的。
开始在新的电子表格中一一删除故事，同时保持以下顺序：顶部最大的故事和底部的最小故事。这样做直到所有故事都在列表中。
现在是时候为这些故事加分了。我个人使用扑克计划量表 (1/2,1,2,3,5,8,13,20,40,100)，所以这就是我将用于此示例的内容。在该列表的底部，您可能会有微任务（需要 4 小时或更短时间完成的事情）。给每个微任务 1/2 的值。然后通过将值 1（在比例中的下一个）赋予故事继续列表，直到很明显故事更大（2 而不是 1，所以大两倍）。现在使用值“2”，继续往上看，直到找到一个显然应该是 3 而不是 2 的故事。继续这个过程直到列表的顶部。
注意：尽量将绝大多数分数保持在 1 到 13 之间。第一次你可能有一堆大故事（20、40 和 100），你必须将它们分解成小于或等于 13 的块.
这就是积分和原始积压。如果您有一个新故事，请将其与该列表进行比较，以查看它适合的位置（更大/更小的过程）并赋予其邻居的价值。
速度与估计（宏观规划）
要估计完成该积压工作需要多长时间，请进行第一个 sprint 计划。将附加到团队选择的故事和VOILA！的总点数相加，这是您的第一个速度度量。然后，您可以将积压中的总点数除以该速度，以了解需要多少 sprint。
该速度将在前 2-3 个 sprint 中发生变化并稳定下来，因此密切关注该值总是好的