对敏捷环境中的大型项目进行估算

我的公司刚刚进行了第一次大规模的开发项目调查,我想使用敏捷过程.客户对应用程序有一个愿景,但公开承认只有很少的要求,并承认我们必须按小时收费.因此,我几乎以敏捷的方式卖掉了他.

问题是他想要一个数字来预算.我已经阅读了一些非常主张放弃估算的文章,因为客户会预算这个数字,即使需求发生变化,他们头脑和书中的数字也没有.

我已经读到有很多方法可以考虑合同中的定价,但几乎所有这些方法(除了一个)都包含一个前期数字.这似乎违反了敏捷开发的整套原则.

所以我的问题是,如果你是一个敏捷商店,你如何设法规避敏捷开发的这个Catch-22？

这是根本问题.

客户什么时候会认为他们已经完成了？

如果他们认为他们将在6月完成,那么你就会建立一个敏捷团队.这是6个月的4-6人.这是预算.基本上,你为它们进行乘法运算.团队*率*6个月.

如果他们认为他们大部分时间都会在6月完成,但之后会有更多的工作,那么你可能会看到9个月的工作.再一次,你只是做了他们可以为自己做的倍增.团队*率*9个月.

如果他们认为您将在可预见的未来成为他们的开发团队,那就给他们一个价格,让项目一直持续到年底.团队*率*12个月.

由于每个版本是重新安排一个机会,你应该每个定价释放,基于自己的,单独的一件作品将在该版本中得到完成.由于这是他们的优先计划,他们控制你建立的,他们逐步控制预算.

通常,您的客户真的想知道特定功能集的成本.他们没有问这个问题,而是询问整体预算(这很愚蠢).在第一个版本上花费大量时间来展示他们获得的内容以及首次发布的成本.

最终,他们会看到基本的事实.

他们购买的功能从最重要到最不重要.如果他们正确地确定优先顺序,他们可以随时停止花钱并获得有用的东西.

完成是一个相对术语.有些项目"完成",因为没有更多的钱.其他人已经完成,因为没有时间了.很少(至少在软件开发中)是一个有史以来完成的项目,因为我们已经没事了.

对于这种情况,我们提供了对第一块工作的估计,然后让客户购买更多的冲刺,以完成工作到所需的水平.

随着您开发的系统越来越多,并将客户的反馈结合到sprint交付项中,您将更好地了解所涉及的工作量,从而降低所涉及的成本.

编辑:很酷.方式很棒!从你用敏捷方法出售它们的事实来看,顺便说一句好的方法!你可以从敏捷的角度来看待它们在要实现的功能方面接近它.也许有人听一下这个" Scrum简介 "播客.你可能能够卖掉它们,因为他们可能不需要拥有他们认为现在需要的所有花里胡哨的东西.

HTH

干杯,

抢

看,这里有一个核心事实.您将被要求估算特定交货日期的成本,合同,并承诺提供一整套交付的功能.

你不能做到这三点.

不是"你不应该"或"不明智"; 你(出于所有实际目的)不能.我的意思是成功完成所有三个的概率非常小.

最好的答案是承诺成本和时间表,以及快速迭代和定期反馈的迭代过程,然后编写协议,以便在未达到固定成本和时间表的情况下完成的工作将交付.也就是说,在时间和金钱耗尽之前,您不断提供新功能(和修改).

事实是,即使你不报名参加全部三个,你永远能够做到最好的就是三分之二的反正.关于它可能也是开放的.

以下是我最近认识的一位陈旧的政府承包商如何说:"正如妓女所说的那样,首先你必须让他们上楼."

这不能回答你的问题,但值得记住.如果他们不会在没有预先编号的情况下上楼(他们不会),你必须给他们一个号码.

赞助软件项目的任何人都需要知道他们将获得什么样的投资回报,以便他们可以评估投资是否值得.如果一个项目耗资100万美元并需要12个月,那么该项目可能值得一试.如果它花费200万美元并且需要24个月,它可能不值得做.

真正的问题是:你能否在一个时间范围和预算内完成这个项目,使客户能够实现适当的投资回报？如果您对该问题的回答不是"是",那么他们就不应该雇用您来完成该项目.否则,他们只是花钱和掷骰子.

如果您当前对该问题的回答是"我们还不知道",那么他们就不应该雇用您来完成该项目.但这并不意味着他们不应该雇用你去了解该项目是否值得做.一个好的咨询公司的流行语就是"初步范围界定".

敏捷开发是关于三维管理曲线:花费的金钱,日历时间和功能集.如果预算和计划是固定的,那么功能集必须是可变的.你可以不知道是什么的最终功能集将给出这些限制.但是,您可以知道在这些约束条件下您能够生成的功能集是否落在客户端可以接受的范围内.

你可以知道这一点,你可以找到它.发现这是你公司可以做的事情而你的客户却做不到的事情.这是您可以提供给他们的服务,他们应该付钱给您.避免免费试图这样做,并将其称为销售成本.项目范围与软件开发一样,都是专业服务的一部分.你不是这样做是为了结束销售; 你这样做是为了帮助你的客户做出一个他们还没有足够信息做出的商业决策.

但首先你必须让他们上楼.

这些答案真的很棒.我没有很多经验可以分享,但我想到了一个类比:

去年,我和妻子改造了我们的厨房.承包商建议按时间和材料计费,而不是给出估计,因为我们不知道我们在管道,底层地板损坏等方面发现了什么.我们同意了,因为我在家工作,我可以不断回答问题.承包商与我有良好的关系,所以当有什么事情发生时,他可以随意敲我的办公室门,我们会讨论它.决定很快就完成了,工作按我想要的方式完成.这似乎与敏捷优先考虑频繁的客户审查.

相比之下,我妻子的表弟也正在改造他的房子.他是急诊医生,在改造期间他不在现场.因此,他描述了经常在没有咨询他的情况下做出重大决定的承包商经常感到惊讶("什么？我不想让那个画面被遮挡掉!撕掉墙壁,重新调整窗口的样子!").这当然是非常昂贵的,并且将时间表从水中吹走.绝对不敏捷.

因此,让客户相信时间和材料模式可行的一种方法可能是向他们保证,您将经常进行进度报告以获得他们的反馈.我相信这已经成为大多数敏捷方法的核心建议.首先,当然这需要客户信任顾问.

作为一个单独的资源,我搜索并找到了一本关于这个主题的书:迈克科恩的 " 敏捷估算与规划 ".从一组令人印象深刻的敏捷专家那里阅读该页面上的表扬.