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

Question

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

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

•Y美元可转换为Z小时，因此我们必须确保时间（X）<= Z，可能通过缩小X的范围。

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

凯利沃特斯在评估敏捷方面有一个有趣的看法：http://www.agile-software-development.com/2009/04/agile-estimating.html不幸的是，这些是难度的估计，使用积分系统，而不是转化为小时。

在我看来，我们需要做两件事之一：

•获得具有大量灵活性的合同，以适应敏捷开发过程。

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

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

或者，是否有人通过其他流程变更看到了解决问题的另一种选择？

Answer 1

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

因此，至少有两种记录方法可以做到这一点，Mike Cohn在"Agile Estimating and Planning"一书中描述了这两种方法，我强烈建议大家阅读。

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

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

再次，有关如何执行此操作的更多详细信息，请阅读参考书。

Answer 2

Big Upfront Estimation只是附带$$$附加的Big Upfront Design

你没有，这将完全违背整个敏捷范式。

敏捷可以是固定成本

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

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

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

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

Answer 3

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

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

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

Answer 4

您应该创建一个只运行一两个月的合同，而不是瞄准“整个”项目的合同。

设定一些非常低的目标，可能只有两三个功能。

向客户解释这是项目的发现阶段。如果没有这个阶段，你就不能给他们一个整个范围的估计。给他们一个不准确的估计是没有意义的。

客户受益于以下方式：

• 降低前期成本（仅占总价格的一小部分）。如果出现问题，那么他们的财务风险是有限的（考虑到大多数软件项目都失败了，这是明智的。）
• 在几个月内制作可以立即解决其中一些问题的工作软件
• 有工作软件来激发有关要求的思考/对话
• 客户会发现更多关于他们真正想要的内容
• 客户可以看到你的工作情况。如果他们不喜欢它，他们可以寻找其他地方。

Answer 5

“你没有，这将完全违背整个敏捷范式”：我认为这是非常不正确的。敏捷是基于常识的，没有人会投资项目，如果他们不知道它将大致花费多少：他们知道他们可能不得不缩小范围以满足最后期限或增加预算和/或延长期限以实现整个范围。在我的公司项目中，我们通过比较他们的规模来估计项目，并且还使用扑克规划估计史诗。使用不确定性的锥体，并且在没有质量折衷的情况下，与现实相比，在开始第一次冲刺之前，我们估计最多可享受50％的折扣。随着我们建立敏捷专业知识（准确性和获得初步估算的时间），我们将会改进。 你不能指望营销赞助项目的3个冲刺（最多3个月），以了解它将花费多少。

Answer 6

如果您估计故事点中的积压项目（在您链接到的Kelly Waters文章中讨论过），那么问题就变成了您希望团队在sprint中提供多少故事点。如果您的团队之前一直在一起工作，那么您应该能够对此进行猜测（可能有上限和下限来表示置信区间）。

如果团队以前没有合作过，那么你可以采取一些易于理解的故事并将其分解为详细的任务。这将为您提供一个工时编号，您可以将其与故事点估计值进行比较，以尝试预测您的速度。同样，上限值和下限值的置信区间可能是合适的。

假设您的用户故事总计达到150分，并且您预测您的团队每月可以提供15-20个故事点，那么这项工作将需要7.5到10个月（通过简单划分）。

这种方法的优势在于您可以测量团队的实际速度，并将其与计划进行比较。重新估算时间线也应该非常简单，例如如果你在几次冲刺后发现团队的速度实际上每月只有10个故事点，那么你就可以很容易地预测出你的修订时间表。

请记住，团队速度确实会因多种原因而波动。当团队仍在形成时，通常在项目开始时会降低。此外，该团队最有可能专注于基础设施问题，而不是提供功能。