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