您如何预先评估敏捷项目?

car*_*ter 23 iteration agile schedule

在处理固定价格软件开发项目时,我经常发现自己必须估算项目在设定价格之后但在工作开始之前(或者在开发过程中很早)的总小时数.不幸的是,这些类型的项目最好使用迭代/敏捷方法开发,这意味着我们不会(并且实际上不能)进行完整的前期设计.

在典型情况下,我们将签订具有X特征和Y美元的合同.签订合同后,工程部门需要估算完成X功能所需的小时数.预先需要此信息有几个可能的原因,包括:

•Y美元转换为可用的Z小时,因此我们必须确保时间(X)<= Z,可能通过缩小X的范围.

•已设置交货日期,因此我们必须分配适当的资源以满足该日期.

Kelly Waters对估算敏捷有一个有趣的看法:http://www.agile-software-development.com/2009/04/agile-estimating.html不幸的是,这些都是难度的估计,使用积分系统,而不是转换为小时.

在我看来,我们需要能够做两件事之一:

•获得具有大量灵活性的合同,以适应敏捷开发流程.

•弄清楚如何为尚未设计的功能提供合理准确的前期估算.

在大多数情况下,第一种选择当然不是一种选择.有没有人对如何在敏捷开发场景中生成前期估计有任何建议/指导?

或者,有没有人看到通过其他一些流程变化解决我们问题的另一种选择?

Hug*_*lma 11

我认为每个客户都希望至少估计一定数量的功能的实现将花费多少.我不同意那些说如果你使用敏捷而不能做到这一点的人.敏捷可以适应现实世界,客户想知道他们将在项目上花多少钱,或者至少有一个粗略的想法.

因此,至少有两种记录方法可以做到这一点,Mike Cohn 在"敏捷评估与规划"一书中对此进行了描述,我强烈建议大家阅读.

  • 在你的项目开始之前,你可以在任务中分解你的故事,并在几小时内估算每个家.使用这些估算进行预算数学计算.请注意,这些估算值仅用于达到估算时间/预算.项目启动时,团队应负责评估和创建正常的任务.

  • 使用历史数据.如果同一团队之前曾使用过类似技术的项目,那么您可以使用过去的团队速度来估算项目成本.

同样,有关如何执行此操作的更多详细信息,请阅读参考书.


小智 9

Big Upfront Estimation只是Big Upfront Design,附有$$$

你没有,这将完全违背整个敏捷范式.

敏捷可以是固定成本

您可以做的是设置一个日期,然后在迭代/冲刺中使用它,并让产品所有者决定在该日期之前完成的重要事项.通过这种方式,1周或2周的Sprint是固定成本,与Big Up Front Design相同,它只是一个较小的固定成本.

敏捷方法背后的整个前提是废除任意期限和他们成为的死亡游行,因为合同和期限内没有考虑到变化.SCRUM的工作原理,是一个很好的起点,可以建立一个方法论,阅读它,并做至少作为起点.

短期冲刺与客户反馈和批准

为您提供一个优化未来估算的起点,并帮助您快速获得产品所有者和客户的信任,因为他们会在很短的时间内看到他们最重要的问题.

  • @John Rayner:敏捷允许估计发布计划.换句话说,一个猜测.这不是你应该在合同中提出的...... +1模糊的棒棒糖. (2认同)

Pas*_*ent 5

Agile中的固定价格为您提供了一系列可以针对给定团队规模运行的迭代.然后,敏捷的观点是最大化在这些迭代期间可以获得的值.敏捷是关于范围管理.

所以,你实际上不应该做前期估计.如果您愿意,这将意味着固定范围,这与敏捷或反敏捷正好相反.

敏捷不会像这样工作,你需要一种新的合同,正如另一个答案所指出的那样.例如,参见10 Agile Contracts和/或google.