23

在从事固定价格的软件开发项目时，我经常发现自己不得不估计项目在价格确定之后但在工作开始之前（或在开发的早期阶段）将花费的总小时数。不幸的是，这些类型的项目最好使用迭代/敏捷方法开发，这意味着我们不（而且真的不能）进行完整的前期设计。

在一个典型的场景中，我们将有一个具有 X 功能和 Y 美元的合同。签订合同后，工程部门需要估算完成 X 功能所需的小时数。有几个可能的原因需要预先提供此信息，包括：

• Y 美元转换为可用的 Z 小时，因此我们必须确保 time(X)<=Z，或许可以通过缩小 X 的范围。

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

Kelly Waters 在这里对敏捷的估计有一个有趣的看法：http ://www.agile-software-development.com/2009/04/agile-estimating.html不幸的是，这些是使用积分系统的难度估计，而不是翻译成小时。

在我看来，我们需要能够做以下两件事之一：

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

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

在大多数情况下，第一个选项当然不是一个选项。是否有人对如何在敏捷开发场景中生成预先估计有任何建议/指导？

或者，是否有人看到通过其他一些流程更改来解决我们的问题的另一种选择？

4

6 回答 6

11

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

因此，至少有两种记录在案的方法可以做到这一点，并且两者都在 Mike Cohn 的“敏捷估计和规划”一书中进行了描述，我强烈建议大家阅读。

  • 在您的项目开始之前，请先将您的故事分解为任务，并以小时为单位估算每个家庭。用这些估计做预算数学。请记住，这些估算将仅用于达到估算的时间/预算。当项目开始时，团队应该像往常一样负责估计和创建任务。

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

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

于 2009-11-24T09:28:07.920 回答
9

Big Upfront Estimation 只是大的前期设计，附有 $$$

你不知道，那将完全违背敏捷的整个范式。

敏捷可能与固定成本有关

你可以做的是设置一个日期，然后在迭代/冲刺中朝着它工作，让产品负责人决定在那个日期之前完成什么是重要的。通过这种方式，1 或 2 周的 Sprint 是固定成本，就像在大前期设计中一样，它只是一个较小的固定成本。

敏捷方法背后的整个前提是消除任意的截止日期和它们所变成的死亡行军，因为合同和截止日期没有考虑到变化。SCRUM 有效，是建立方法论的一个很好的起点，阅读它并做它所说的至少作为一个起点。

带有客户反馈和批准的短 Sprint

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

于 2009-11-23T22:09:54.233 回答
5

敏捷中的固定价格为您提供了许多迭代，您可以针对给定的团队规模运行。敏捷的重点是最大化您在这些迭代中可以获得的价值。敏捷是关于范围管理的。

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

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

于 2009-11-23T22:26:37.780 回答
4

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

设定一些非常低的目标，也许只有两三个特征。

向客户解释这是项目的发现阶段。如果没有这个阶段，您就无法为他们提供整个范围的估计。给他们一个不准确的估计不符合任何人的利益。

客户通过以下方式受益：

  • 降低前期成本（仅占总价格的一小部分）。如果事情进展顺利，那么他们的财务风险就会受到限制（考虑到大多数软件项目都失败了，这是明智的）。
  • 在几个月内拥有可以立即解决他们的一些问题的工作软件
  • 有工作软件来激发关于需求的思考/对话
  • 客户会发现更多关于他们真正想要的东西
  • 客户可以看到您的工作情况。如果他们不喜欢它，他们可以寻找其他地方。
于 2009-12-11T02:25:43.637 回答
3

“你不这样做，那将完全违背整个敏捷范式”：我认为这是非常不正确的。敏捷是基于常识的，如果他们不知道项目的大致成本是多少，没有人会投资于项目：他们知道他们可能必须缩小范围以满足截止日期或增加预算和/或延长截止日期以交付整个范围。在我公司的项目中，我们通过比较它们的大小来估计项目，并且还使用扑克计划来估计史诗。使用不确定性锥体，并且在不权衡质量的情况下，与现实相比，我们在开始第一个 sprint 之前的估计值最多可降低 50%。随着我们建立敏捷专业知识（准确性和获得初步估计的时间），我们将不断改进。你可以'

于 2011-07-30T21:01:34.603 回答
1

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

如果团队以前没有一起工作过，那么你可以拿几个很好理解的故事，把它们分解成详细的任务。这将为您提供工时数，您可以将其与您的故事点估计值进行比较，以尝试预测您的速度。同样，上限和下限的置信范围可能是合适的。

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

这种方法的优点是您可以测量团队的实际速度，并将其与计划进行比较。重新估计你的时间线也应该很容易，例如，如果你在几个 sprint 之后发现团队的速度实际上每个月只有 10 个故事点，那么你可以很容易地预测你修改的时间线将是什么。

请记住，团队速度确实会因多种原因而波动。当团队仍在组建时，它通常在项目开始时较低。此外，团队此时最有可能专注于基础架构问题，而不是交付功能。

于 2009-12-03T01:16:31.840 回答