我的公司刚刚进行了第一次大规模的开发项目调查，我想使用敏捷过程。客户对应用程序有一个愿景，但公开承认只有很少的要求，并承认我们必须按小时收费。因此，我几乎以敏捷方式卖掉了他。
问题在于他想要一个数字来预算。我已经阅读了一些非常主张放弃估算的文章，因为客户会预算这个数字，即使需求发生变化，他们头脑和书中的数字也不会。
我读过有很多方法可以考虑合同中的定价，但几乎所有这些方法（除了一个）都包含一个前期数字。这似乎违反了敏捷开发的整套原则。
所以我的问题是，如果你是一个敏捷商店，你如何设法绕过这个敏捷开发的Catch-22？
答案 0 :(得分：39)
这是根本问题。
客户什么时候会认为他们已经完成了？
如果他们认为他们将在6月完成，那么你就会建立一个敏捷团队。这是6个月的4-6人。这是预算。基本上，你为它们进行乘法运算。团队*率* 6个月。
如果他们认为他们大部分将在六月份完成，但之后会有更多的工作，那么你可能会看到9个月的工作。再一次，你只是做了他们可以为自己做的倍增。团队*率* 9个月。
如果他们认为您将在可预见的未来成为他们的开发团队，请给他们一个价格，让项目一直持续到年底。团队*率* 12个月。
由于每个版本都是重新确定优先级的机会，因此您应该根据将在该版本中完成的内容将每个版本定价为单独的工作。由于这是他们的优先计划，他们控制你建立的，他们逐步控制预算。
通常，您的客户真的想知道特定功能集的成本。他们没有问这个问题，而是询问整体预算（这很愚蠢）。在第一个版本上花费大量时间来展示他们获得的内容以及首次发布的成本。
最终，他们会看到基本的事实。
他们正在购买从最重要到最不重要的功能。如果他们正确地优先考虑，他们可以随时停止花钱并获得有用的东西。
完成是一个相对术语。有些项目“完成”，因为没有更多的钱。其他人已经完成，因为没有时间了。很少（至少在软件开发中）是一个曾经完成的项目，因为我们已经没有事情可做了。
答案 1 :(得分：13)
对于这种情况，我们提供了对第一部分工作的估计，然后让客户购买更多的冲刺，以完成工作到所需的水平。
随着您开发的系统越来越多，并将客户的反馈信息纳入sprint交付项，您将更好地了解所涉及的工作量，从而降低相关成本。
编辑：酷。方式很棒！从你用敏捷方法出售它们的事实来看，顺便说一句好的方法！你可以从灵活的角度来看待它们在要实现的功能方面接近它。也许请听一下这个“Intro to Scrum”播客。您可能会因为他们可能不需要拥有他们认为现在需要的所有铃声和口哨而将它们卖掉。
HTH
欢呼声，
罗布
答案 2 :(得分：10)
看，这里有一个核心事实。您将被要求估算特定交货日期的成本，合同，并承诺提供一整套交付的功能。
你无法做到这三点。
不是“你不应该”或“不明智”;你（出于所有实际目的）不能。我的意思是成功完成所有这三项的可能性非常小。
最好的答案是承诺成本和时间表，以及快速迭代和定期反馈的迭代过程，然后编写协议，以便完成以及固定成本和时间表是什么将被交付。也就是说，在时间和金钱耗尽之前，你不断提供新功能（和修改）。
事实是，即使你做注册所有三个，你最好能做的最好的是三分之二。不妨对此持开放态度。
答案 3 :(得分：9)
以下是我最近认识的一位陈旧的政府承包商如何说：“正如妓女所说，首先你要让他们上楼。”
这不能回答你的问题，但值得记住。如果他们不上楼而没有预先编号（他们不会），你必须给他们一个号码。
赞助软件项目的任何人都需要知道他们将获得什么样的投资回报，以便他们可以评估投资是否值得。如果一个项目耗资100万美元并需要12个月，那么该项目可能值得一试。如果它花费200万美元并且需要24个月，那么它可能不值得做。
真正的问题是：您能否在一个时间框架和预算内完成这个项目，使客户能够实现适当的投资回报？如果您对该问题的回答不是“是”，那么他们就不应该雇用您来完成该项目。否则，他们只是花钱和掷骰子。
如果您目前对该问题的回答是“我们还不知道”，那么他们就不应该雇用您来完成该项目。但这并不意味着他们不应该雇用你去了解该项目是否值得做。一个好的咨询公司的流行语就是“初步范围界定”。
敏捷开发是关于三维管理曲线：花费的金钱，日历时间和功能集。如果预算和计划是固定的，那么功能集必须是可变的。鉴于这些约束，您无法知道 最终功能集将是什么。但是可以知道 功能集是否能够在这些限制范围内生成，并且属于客户端可以接受的范围内。
你可以知道这一点，你可以找到它。发现这是你公司可以做的事情而你的客户却做不到的事情。这是您可以提供给他们的服务，他们应该付钱给您。避免免费试图这样做，并将其称为销售成本。项目范围与软件开发一样，都是专业服务的一部分。你不是这样做是为了结束销售;你这样做是为了帮助你的客户做出一个他们还没有足够信息做出的商业决策。
但首先你必须让他们上楼。
答案 4 :(得分：6)
这些答案真的很棒。我没有很多经验可以分享，但我想到了一个类比：
去年，我和妻子改造了我们的厨房。承包商建议按时计费。材料而不是估计，因为我们不知道我们在管道，底层地板损坏等方面发现了什么。我们同意了，因为我在家工作，我可以不断回答问题。承包商与我有良好的关系，所以当有什么事情发生时，他可以随意敲我的办公室门，我们会讨论它。决定很快就完成了，工作按我想要的方式完成。这似乎与频繁的客户审核上的敏捷优先级类似。
相比之下，我妻子的堂兄也正在改造他的房子。他是急诊医生，在改造期间，他不在现场可用。因此，他描述了经常在没有咨询他的情况下做出重大决定的承包商经常感到惊讶（“什么？我不想让那个画面被遮挡掉！撕掉墙壁，重新调整窗口的样子！”）。这当然是非常昂贵的，并且将时间表从水中吹走。绝对不敏捷。因此，有一种方法可以让客户相信时间和时间。材料模式将起作用可能是为了向他们保证，您将经常进行进度报告以获得他们的反馈。我相信这已经成为大多数敏捷方法的核心建议。首先，当然这需要客户信任顾问。
作为一个单独的资源，我搜索并找到了一本关于这个主题的书：迈克科恩的“Agile Estimating and Planning”。从一组令人印象深刻的敏捷专家那里阅读该页面上的赞誉报价。
答案 5 :(得分：3)
首先，我想说我认为你卖给他一个灵活的方法和每小时的定价是很棒的。这很难做到。
关于您的困境，我认为您应该向他提供粗略的定价估算及其包含的功能/范围。在开发过程中，如果你看到一些重要的东西会改变范围/成本，你会告诉客户“停止 - 这很好，但要明白它会改变我们讨论过的原始范围。”
此时，客户有权同意，意识到他将支付比他原先想象的更多，或暂时停止新的开发。许多敏捷项目都是在许多小型阶段构建的 - 您可以为其提供非常准确的价格/时间估算。在任何新的迷你舞台开始之前，重要的是您和客户应该看到接下来会发生什么，以及花费多少时间/成本。
答案 6 :(得分：2)
一如既往的质量，功能和时间（=资源）是您的主要参数。我们不再贬低质量，因此只剩下功能和资源。通常情况下，您可以说服一定数量的资源至少达到某个功能集。因此，只要您能找到提供合理功能集的大量资源，我相信这对于不少客户来说已经足够了。好处是他们可以在移动中控制进度，并且总是可以选择退出。
答案 7 :(得分：2)
我这样做的方法是使用我当前的速度并根据复杂性的粗略估计（故事数量）估算一个范围。您将在开始规划应用程序时更新此项，以便范围估计逐渐变得更好和更好。
例如，估计从6年到2年（如果您确定它将花费的时间少于2年。当您将其分解为功能，然后计划这些功能时，您会想出更好的更好的估计，以便在6mos之后你可以可靠地说（没有任何其他变化），我们将在另外2-3个月（总共8-9个月）完成。最终，你到达可以说，我们的点将在下一次迭代（2周到1个月）之后完成。
您需要将此配对，让客户知道添加功能会增加完成时间，然后让他们决定如何继续 - 删除功能或增加时间。对于任何给定的项目，范围和时间实际上是您可以有效更改的唯一变量。质量和资源几乎是固定的。实际上，您可以添加资源，但通常您会看到时间的增加和质量的下降，因此只有在您的时间范围很长时才会有效。
答案 8 :(得分：1)
这是一个非常棘手的问题。看看罗伯特·格拉斯在他的书“Facts and Fallacies of Software Engineering”中对这个主题的看法。 （请注意，亚马逊的新书可用量少于二手版！[截至2009-01-05 12:20 - 08:00];也可以在Google图书上使用。）< / p>
答案 9 :(得分：1)
您可以采取的一种方法是向客户提供您认为相对接近的一般估计。还给出一个百分比。由于需求变化，该百分比将是预算中的增加或减少分配。
示例：一般估计为10,000美元，但由于要求模糊且项目可以轻松改变方向，因此有+/- 30％的价格调整选项。
通过这种方式，客户可以大致了解预算内容，并且可以灵活地为项目收费。
答案 10 :(得分：1)
如果您已成功向客户销售敏捷方法，并按小时计费，不会估算完成项目所需的费用！。即使他们说他们只是为了预算目的，不要这样做！。
原因是任何成本估算都会被视为明确的承诺;无论你说它不是多少次，客户说他们理解了多少次，它都将被视为一种承诺。即使客户理解，他们的老板也不会，虽然他们无法合法地强迫您按照您所说的价格交货，但您将成为一家无法兑现承诺的公司。提供一个估计会首先抛弃敏捷的所有优势。
我建议告诉他们，您将在财政年度结束之前（或客户感兴趣的其他任何结算周期）花费不超过这样的金额。这应该足以让他们在财务上进行计划，而不会以任何方式表示该项目将在那时完成。
答案 11 :(得分：0)
这是我的answer到closed question与故事点相关的内容。我一直用它进行宏观估计。
当我切换到积分时，我决定只能满足以下两点; 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。
这就是积分和原始积压。如果您有一个新故事，请将其与该列表进行比较，以查看它适合的位置（更大/更小的过程）并为其提供其邻居的值。
速度＆amp;估算（宏观规划）
要估计完成积压工作需要多长时间，请执行第一个sprint计划。制作团队选择的故事和VOILA！的总分，这是你的第一个速度测量。然后，您可以将积压中的积分除以该速度，以了解将需要多少冲刺。
速度会在前2-3次冲刺中发生变化并保持稳定，因此始终关注该值