目录:
软件项目估算
Pixabay
介绍
估计很困难。不幸的是，这也是非常必要的。公司使用估算来计划发布计划，对客户作出承诺，确定所建议的功能是否值得实施，跟踪团队的工作速度并有效地确定工作的优先级。高管们常常想知道某个功能或交付项何时可以投入生产。毕竟，软件开发并不是一笔微不足道的投资。没有估算，项目经理将如何进行评估？如果人类能够准确地预测未来，那么人们将不会有2％的时间在赛马比赛中获胜。估计是一个巨大的难题。公司要求员工去做不可能的事情：预测未来是必不可少的。
首先，让我们回顾一些流行的估算方法（以防万一您错过了一些兴奋的地方）。然后，我们可以看看这对我们和我们的项目意味着什么。
算命模型
该模型几乎不需要任何努力即可得出估算值。估算人员考虑了实现和测试功能所需要做的事情，然后抛出了一个数字。听起来很像是“……（长时间停顿）……嗯……六个星期。”然后大家点头，我们继续前进。他们可能在前端花费相当长的时间来讨论他们对需求的了解（这可能不是完整的情况）。仔细的分析使他们的估计更可靠。在项目结束时，总是存在一个公认的理由，即为什么估算值与实际情况相差甚远。总是有无法预料的情况可以作为替罪羊。任何人通常都不会想到该模型存在严重缺陷。
那么我们如何才能使这个过程更好呢？我知道！我们可以使用分解技术（即分而治之）。该方法假定您知道前端功能或项目的完整范围。每个功能都细分为一口大小的块。每个块都是估计的（算命先生样式），然后我们将它们加起来以获得总体功能/项目估计。当然，这是一种更复杂的方法，但是似乎有两个更好的理由：
- 较小的工作量往往更容易可靠地估计。
- 尽管仍然存在错误的机会（+/-一定数量），但有一个假设，当您将所有错误加在一起时，错误会相互抵消，并且您将获得更可靠的总体估计。
这种方法的根本缺陷是，各个贡献者（实际从事这项工作的人）普遍低估了。它们仍然比上面和周围的那些要好得多，但这并不是一个很高的标准。情况似乎并非如此，因为我们都看到过开发人员通过提前完成某些事情而感到惊讶的情况。但这只是一个数据点，而不是趋势。人们实际上确实偶尔在赌场赢了；每天在赌场花钱一年，您的钱就会比开始时少。如果跟踪一两年的估算值与实际值，您会发现估算值确实不符合实际。尽管许多商人绝对确信开发人员会懒惰地填充其估算，并利用额外的时间来“镀金”或检查其库存，数据以其他方式显示。 “淘汰”策略不起作用。
那么现在怎么办？让我们放弃算命先生模型，切换到基于大小的方法。事实证明，尽管人类在估算完成时间方面非常糟糕，但实际上我们很擅长说出事物的规模。我们在比较大小方面特别擅长（“大于该大小，但小于那边的大小”）。如果我们以大小或复杂性而不是时间来考虑，我们的大脑将更可靠地处理它。然后，我们可以根据一个漂亮的魔术公式，获取大小值并计算项目的实际小时数！到那时，流行的功能点模型进入场景（左阶段）。
功能点分析（FPA）
对于功能点分析，我们需要在应用程序中识别五种类型的事物：外部输入，外部输出，外部查询，外部接口文件和内部逻辑文件（不必太担心定义；您可以稍后进行研究） 。这些（函数）的每个示例都具有与之相关的复杂性（低，平均或高）。我们使用下表来找出每个功能分配了多少点。
现在，如果我们将所有功能的点加起来，我们的项目可能会得到一个数字，例如457功能点。然后，我们只需要一个公式来计算小时数…根据我们的上一个项目，我们的“交付率”是每人每月15个功能点。这大约需要30个人一个月的工作时间，对于我的12人团队来说，这需要花费两个半月的时间。
这肯定比我们以前的模型复杂。实际上，有四个关键领域需要识别。
- 这五种组件类型不一定是直观的，很容易忘记将某些内容放入列表或将其分配给错误的存储桶。
- 用于实际生成功能点的表包含魔术数字，需要大量的努力才能进行验证。这些数字是否经过适当校准以为我的团队提供可靠的估计？
- 交付率（难题的关键部分）是根据您团队的生产率计算得出的。我们需要多久计算一次新数字？实际上，对此的指导很少。
- 低，平均或高复杂度是什么构成的？我们如何定义它，以便每个人都能理解？这对我们的计算精度不是很关键吗？
在这个非常简单的示例中，有几个移动的部分，我们甚至没有讨论更复杂的复杂性模型以及可以发挥作用的其他数据（例如，成本率，支持率，缺陷密度等）。更多的运动部件意味着发生错误的机会更多。我们现在使估算过于复杂吗？我们不会付钱给开发人员很多时间进行估算。我无法将估算值卖给客户。我需要工作软件。那里还有其他东西吗？
敏捷
现在，让我们简要地看一下敏捷Scrum（足以进行比较）。如前所述，人类在估计时间时很糟糕，并且在比较大小方面也很擅长。以下是一些需要理解的术语：
- 冲刺-有时间限制的时间段（通常为两周）。
- 用户故事-一项离散的工作，最好小到可以由一个人在sprint中完成。这就是我们要估计的东西。
最受欢迎的策略是使用斐波那契数列（0、1、2、3、5、8、13）进行估算。它不是线性的-随着比例的增加，间隙的大小也会增加。关键在于，差距应足够大，以至于没有理由就微不足道的分歧进行争论。一旦达到3以上，则4与5或7与8之间的差异就可以忽略不计，以至于花时间散列哪个是毫无意义的。以2为基的序列也可以工作（0、1、2、4、8、16等）。
“但是等等，这只是一个数字。这是什么意思？多少小时？”积分不打算直接与小时相关，因为如果这样做，团队将倾向于回到以小时为单位进行估算，然后以某种方式将其转换为积分。如前所述，我们估算的准确性来自比较规模估算，而不是估算所需的工作时间。如果您让团队可以根据小时数进行思考，那么您在进行准确估算的能力就会受到损害。
假设您从校准练习开始。将您的团队拉进一个房间，并引导他们浏览10-12个用户故事的列表。选择一个很小但不是最小的，然后先做一个。对其进行回顾，并宣布该故事为“ 3”。你不是在问你在说然后继续下一个故事。 “如果那是3，那是什么？”现在，团队正在相对于其他故事调整故事大小。最终，他们将对如何构成“ 1”，“ 2”等有一个很好的认识。他们没有进行估算。时间无所谓。相对于已经有编号的其他故事，他们正在调整故事的大小。然后，您可以将序列中每个数字的示例故事放在称为标尺的文档中。如果不确定“ 5”是什么，他们可以以此为参考。
现在这是关键。这项工作的魔力在于“速度”（团队可以在3-4个冲刺中平均完成一个冲刺中可以完成的点数）。假设您的冲刺是两个星期，而您的8人团队的平均速度为35分。在640个小时的工作中（8 x 80个小时），您获得了35分。如果我们发现某个功能将需要完成大约100点的工作，那么我知道这大约需要6周的工作和大约1900个小时的时间。团队擅长不断调整故事大小，您可以利用它来进行项目规划。该计算之所以有效，是因为从sprint到sprint的持续时间是一致的。
要进行长期的高级计划，您可以要求潜在客户将高级功能分解为临时的一线故事，并在其中添加点值。将会损失一定程度的准确性，但是您正在利用他们已经了解的模型。更准确的路径是在要素级别进行相对调整。“此功能大于该40点功能，小于该处的120点功能，并且比我们刚刚做的65点功能稍大。” 故事分为“史诗”。如果每个功能都是史诗级的，最后您将知道完成该功能需要花费多少点。保留历史记录，就可以将其用于发布计划。
结论
今天有很多方法在使用。每个都有优点和缺点。我们需要以某种方式找出如何最大程度地提高估计的准确性，以便我们做出正确的决策。这并不意味着我们的估算必须准确。他们只需要足够准确就可以使用。如果您不了解估算，您可能会认为估算不准确，因为团队做得不好。他们没有正确估计，或者他们没有在项目上正确执行。打人将继续，直到估计提高。但是，永远不要将估算用作承诺。根据我们今天拥有的有限信息，这是最好的猜测。当出现新信息时，我们必须允许重新评估。其他任何人都期待着不可能的事情，这是领导能力（而不是团队）的问题。
Scrum的方法比我们在功能点分析中看到的要简单得多。我想说的是，它比带有魔术数字的魔术桌子更值得信赖。它最大程度地降低了成本（以合理的高度准确度实现了最小的工作量）。从努力的角度来看，它不会为团队理解和使用创建繁重的过程。一旦每个人都了解要估算的工作的细节，敏捷估算工作实际上就可以非常迅速地进行。这肯定比凭空抽出数字更好。利用速度非常重要：将历史数据带入计算中。每次冲刺，您都要重新计算速度。这很关键，因为随着时间的推移，吞吐量会发生变化。使用FPA的团队可能会从以前的项目中得出其交付率，在某些情况下是几个月前。从那以后，可能发生了很多变化。我的建议是让您探索敏捷并真正投入精力来理解故事的要点和速度。不要仅仅因为这就是您的理解而花费数小时进行估算。我相信您稍后会感谢您。