功能点估算案例_支持和反对估算的案例，第二部分

功能点估算案例

在本系列的第一部分中，我说过我喜欢数量级估计。 我也喜欢目标代替估算。 我将在第3部分中进一步介绍估算值如何有用。

在这一部分中，我将讨论我何时不喜欢估算。

我发现在以下情况下估算无效：

• 当人们估计不是工作时。
• 经理使用旧的估算值评估项目组合中的工作时。
• 管理层希望使用单个日期而不是日期范围或置信度。

以不太热门的方式使用估计值的可能性更大。 这些是我最喜欢的例子。

让我依次介绍其中的每一个，并解释敏捷如何特别地帮助它们。 那不是因为我认为敏捷是唯一答案。 不，是由于#noestimates讨论。 我在分阶段交付项目和敏捷项目中使用了#noestimates。 我无法在迭代或串行（瀑布/相位闸）项目中执行此操作。 当然，根据我的“卵石”哲学，我几乎总是将迭代或串行项目转换为某种增量项目。

人们估计代表项目团队

我们每个人都有某种形式的估计偏差。 我对完成工作需要什么有一个很好的想法。 当我与人结对时，有时会花更长的时间，因为我们学习如何彼此合作。 有时，它花费的时间比我们预期的要少得多。 我希望配对时能获得优质的产品，但我并不总是知道我们交付该产品需要多长时间。 （在这一年中，我与任何人配对写作。）即使缺乏知识，我们也可以在很短的时间内配对，并做出合理的估算。 （做一些工作，然后重新估算。）

当不属于项目团队的人代表他人进行评估时，他们至少不知道这些事情：真正的项目团队需要交付什么，人们将如何合作以及如何/是否/需求何时会改变。 我有估计偏差。 你有你的。 如果我们一起工作，我们可能会学会同意。 但是，如果我们是某种“专家”，我们将不知道团队会遇到什么以及他们将如何处理它。

我经常看到专家忽略需求风险和需求变更的可能性。 我不相信这类软件估算。

现在，当您与我讨论建筑时，我可能会回答我们对建筑的了解更多。 我们每平方英尺的房屋有美元。 我们有每英里公路的美元。 而且，我住在大挖掘的故乡波士顿。 每次我们改建/改建房屋时，房屋数量仅比原始房屋数量增加10％。 我们与建筑商一起努力管理该成本。

那些项目，包括大挖掘，是值得的。

我们如何使软件项目值得？ 通过尽可能频繁地提供价值并提出以下问题：

• 还有管理风险吗？
• 积压中还有更多价值吗？
• 我们还想投资多少？

软件不是硬性产品。 它是无限延展的。 我们在星期一交付的商品可以更改对我们在星期二，星期三和星期四交付的商品的估算。 我们不能用硬产品做到这一点。

当其他人估计时，我们将无法利用通过共同努力而学到的知识以及我们已经学到的关于该领域的知识。 敏捷专门为这一工作提供了帮助，因为我们经常交付，并且可以根据需要重新估算积压订单。 因为我们能够交付，所以我们对剩余风险有更多了解。

经理对项目组合使用（旧）估算

我已经看到经理们使用估计来评估项目组合中的项目。 我在那年前写了一篇文章： 为什么成本是评估项目组合中项目的错误问题 。

这是旧估算的问题。 估计过期 。 估计在一段时间内是好的。 不是永远的，而是几个星期。 根据您的工作方式，估计可能会持续几个月。 估计值因发生变化而过期：团队可能会发生变化。 代码库和要求当然已经改变。

但是，项目成本只是方程式的一部分。 考虑项目组合时，价值必须是另一部分。 否则，您会沦为沉没成本谬误的牺牲品。

您可能会说：“我们使用ROI （投资回报率 ）作为评估项目组合中项目的一种方法。” 现在，您取决于两个猜测：完成项目所需的时间以及发布的销售/采用率。

投资回报率是价值的替代指标。 当我衡量了实际情况（在完成项目三个月，六个月，九个和十二个月时，我们完成项目所需的实际时间和实际收入时，我们几乎始终无法达到预期的投资回报率。而且，因为我们选择了该项目时ROI，我们为其他项目带来了延误成本： “如果因为做其他事情而没有发布该项目，对我们的收入/采用率等产生什么影响？”（请参阅​​“ 将隐藏的珍宝潜水到了解不同的延迟成本。）

人们经常说：“这两个项目在项目成本方面是平等的。 如果我不使用ROI，我该如何在这些项目之间做出决定？”

我从未见过这样的情况，因此很难预测哪个项目会更短。 以下是一些选项：

• 使用延迟成本作为评估项目组合中项目的一种方法。 有关查看延迟成本的方法，请参阅“ 隐藏宝藏潜水” 。 有关项目组合的其他许多排名建议，请参阅管理项目组合。
• 确定每个项目的第一个可释放的价值交付物。 多久才能做到？ 如果您执行一个项目，发布一些东西，是否能为您提供足够的收入，以便您可以转到另一个项目并在那里发布一些东西？
• 将所有可交付成果缩小，因此，如有必要，您可以将两个项目中的工作分配给一个团队。 团队可以完成一项功能/交付项，然后移至下一项。 我建议使用看板和蜂拥各功能通过让您得到最大的吞吐量。 一旦团队完成“足够”的功能，就决定在哪个项目上花费更多的时间。

敏捷解决了整个项目组合的问题，因为我们都可以看到敏捷项目的进度：演示， 产品积压工作量表和回顾性结果。 我们对完成的事情和前进的方向了解得更多。 我们可以停止一个项目，因为我们不会将工作置于未完成的状态。

管理层希望获得一个单一的估计日期

我为我的项目提供了一系列日期：可能的，可能的，悲观的。 我有时会提供一个置信范围 。 我遇到了许多不想要估算现实的经理。 他们想要一个约会：9月1日下午2点。

问题在于估计只是一个猜测。 完成项目后，我只能知道确切的工期或费用。 当我们完成工作时，我可以离得更近一些，但是我不能肯定提前几个月知道。 对于一个为期一年的项目，我可以猜测是哪个季度/三个月。 当我们完成项目时，我可以约会。 到最后一个季度，我可能会在几周内知道。

经理们可以根据我们向他们解释的假设，风险和未知因素领取巨额资金来管理组织。 当我们从事项目时，管理风险和创造价值是我们的工作。 我们提供的价值越多，我们的经理所拥有的未知数就越少。

敏捷（和增量方法）帮助我们管理这些未知数。 没有什么是完美的，但是它们比其他方法更好。

我曾与几位想要约会的经理一起工作。 我给他们定了悲观的约会。 有时，我提供了90％的置信度日期。 即使那样，有时候我们遇到的问题比我们预期的还要多。 达到那个日期变得不可能。

单点估计是我们喜欢的东西。 不幸的是，单点日期通常是错误的。 管理层出于多种原因想要它。

如果这些原因之一是确保团队可以交付，那么敏捷为我们提供了多种方法来获得此结果而无需单点估计：设置目标，查看演示，查看产品待办事项燃尽图。

如果使用得当，我没有任何反对的估计。 这些只是估计使用不当的三个例子。 估计是猜测。 在第3部分中，我将讨论估计值何时有用。

（对不起，本文太长了。我将停止写作，因为否则我会继续添加。

翻译自: https://www.javacodegeeks.com/2016/06/case-estimates-part-2.html

功能点估算案例