做出准确的软件项目评估

作者:

Mike Shoemake已经是一个成功的软件开发人员20年了，建立了高质量的应用程序和高效的开发团队。

简介

估计很难。不幸的是，这也是非常必要的。公司使用评估来计划发布时间表，向客户做出承诺，决定提议的功能是否值得实现，跟踪团队的速度，并有效地优先考虑工作。执行人员通常想知道某个特性或交付物何时可以投入生产。毕竟，软件开发不是一项微不足道的投资。没有评估，项目经理如何进行评估?如果人类能够准确地预测未来，那么人类在赛马中赢的概率就只有2%。估算是一个巨大的难题。公司有必要让员工去做不可能的事:预测未来。

首先，让我们回顾一些流行的评估方法(以防您错过了一些令人兴奋的内容)。然后我们可以看看这对我们和我们的项目意味着什么。

算命先生模式

这个模型几乎不需要任何努力就能产生一个估计。评估人员稍微考虑一下实现和测试一个特性需要做些什么，然后抛出一个数字。听起来很像“……(长时间的停顿)……嗯……6周。”然后大家都点头，我们继续。他们可能会花相当长的时间在前端讨论他们对需求的了解(这可能不是完整的情况)。这种仔细的分析使他们的估计感觉更可靠。在项目结束时，总是会有一个公认的理由来解释为什么评估与现实相差甚远。总有一些无法预见的情况可以作为替罪羊。 It often doesn’t occur to anyone that the model is severely flawed.

那么，我们怎样才能让这个过程变得更好呢?我知道!我们可以使用分解技术。分而治之。这种方法假设您知道前端功能或项目的完整范围。每个特征都被分解成小块。每个部分都是估计的(算命的风格)，然后我们把它们加起来，得到一个整体的功能/项目估计。这当然是一种更复杂的方法，但它似乎更好，有两个原因:

较小的工作块往往更容易进行可靠的估计。
虽然仍有可能出现误差(+/-某个量)，但有一个假设是，当您将所有误差相加时，误差将相互抵消，您将得到一个更可靠的总体估计。

这种方法的根本缺陷是个体贡献者(实际工作的人)普遍低估了。他们仍然明显优于他们之上和周围的人，但这并不是一个高的标准。但事实并非如此，因为我们都见过开发者提前完成某些任务的情况。但这只是一个数据点，而不是一个趋势。人们确实偶尔会在赌场中获胜;每天在赌场花钱，坚持一年，你的钱会比你开始的时候少。如果你用一两年的时间来跟踪估算和实际情况，你会发现估算与实际情况确实存在差距。尽管许多商业人士绝对确信，开发商在懒惰地夸大他们的估算，并利用额外的时间“镀金”或检查他们的库存，但数据显示并非如此。“抵消”策略是行不通的。

所以,现在什么?让我们抛弃算命的模式，转而采用基于规模的方法。事实证明，虽然人类在估计完成时间方面相当糟糕，但我们实际上很擅长预测事物的大小。我们特别擅长比较大小(“它比那个大，但比那边的小”)。如果我们从大小或复杂性而不是时间的角度来思考，我们的大脑处理它会更可靠。然后，我们可以采用大小值，并基于一个漂亮的魔术公式计算项目的实际小时数!这时流行的功能点模型就出现了(舞台左)。

功能点分析(FPA)

对于功能点分析，我们需要在应用程序中确定五种类型的东西:外部输入、外部输出、外部查询、外部接口文件和内部逻辑文件(不要太担心定义;你可以稍后再研究)。这些(函数)的每个示例都有相应的复杂性(低、平均或高)。我们使用下表来计算每个函数被分配了多少点。

estimating-software-projects-effectively

现在，如果我们把所有函数的积分加起来，我们的项目可能会得到457个函数点。然后我们只需要一个公式来计算小时数……根据我们上一个项目，我们的“交付率”是每人每月15个功能点。这大约相当于30个人一个月的工作量，对于我的12人团队来说，这需要两个半月多一点的时间。哈!

这当然比我们之前的模型要复杂得多。事实上，有四个关键的复杂领域需要认识。

这五种组件类型并不一定是直观的，而且很容易忘记在列表中放入某些内容或将其分配到错误的bucket。
用于实际生成功能点的表包含需要大量工作来验证的神奇数字。这些数字是否经过适当校准，以为我的团队生成可靠的估计?
交付率(拼图的关键部分)是根据团队的生产力计算的。我们需要多长时间计算一次新数字?实际上关于这方面的指导很少。
什么构成低复杂度、平均复杂度或高复杂度?我们如何定义它，让每个人都能理解它?这对我们计算的准确性不是很重要吗?

在这个非常简单的示例中有几个活动的部分，我们甚至还没有讨论更复杂的复杂性模型和其他可以发挥作用的数据(例如，成本率、支持率、缺陷密度等)。运动部件越多，出错的机会就越多。我们现在做的估计是不是太复杂了?我们不会花钱请开发人员投入大量时间进行评估。我不能把估价卖给我的客户。我需要工作软件。外面还有别的吗?

要敏捷

现在让我们简单地看看敏捷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”等的构成有一个很好的概念。 They’re not estimating. Time doesn’t matter. They’re sizing stories, relative to other stories that already have a number. You can then put example stories for each number in the sequence in a document called a ruler. They can use that as a reference if they aren’t sure what a “5” is.

这是关键。实现这一目标的魔法酱是“速度”(一个团队在3-4个sprint中平均完成的点数)。假设你的sprint是两周，你的8人团队的平均速度是35点。你在640小时(8 x 80小时)的工作中得到35分。如果我们知道一个功能从开始到完成需要投入100分的工作，那么我便知道这需要6周的工作时间和1900个小时左右。团队非常擅长对故事进行一致的评估，您可以利用这一点来进行项目计划。这种计算是可行的，因为每个sprint的持续时间是一致的。

要做长期的高层规划，你可以要求你的领导将高层功能分解成临时的一行故事，并在它们上面加上点值。虽然会失去一定程度的准确性，但您正在利用他们已经理解的模型。更准确的方法是在特征级别上进行相对大小调整。“这个特征比那个40分的特征大，比那个120分的特征小，比我们刚刚做的65分的特征略大。”故事被归类为“史诗”。如果每个功能都是史诗，那么最后你就会知道完成该功能需要多少分。保持历史记录，你可以将其用于你的发行计划中。

结论

现在有很多方法在使用。每种方法都有利有弊。我们需要找出如何最大化估算的准确性，这样我们才能做出正确的决定。这并不意味着我们的估计必须是准确的。它们只需要足够准确，就能发挥作用。如果您不理解评估，您可能会认为评估不准确，因为团队没有做好工作。他们没有正确地估计，或者他们没有正确地执行项目。打击将继续下去，直到预期有所改善。但是，估算永远不应该被用作承诺。这是基于我们目前掌握的有限信息做出的最佳猜测。当出现新的信息时，我们必须重新评估。 Anything else is expecting the impossible, which is a problem with leadership (not with the team).

Scrum的方法比我们在功能点分析中看到的要简单得多。我认为它比有神奇数字的神奇表格更值得信赖。它获得了最大的效果(最小的努力和相当高的精确度)。从工作量的角度来看，它不会为团队创建一个需要理解和使用的重量级过程。一旦每个人都理解了评估工作的细节，敏捷的评估部分实际上可以非常迅速地进行。这当然比凭空捏造数字要好。利用速度可以做一些非常重要的事情:它将历史数据引入到计算中。每次冲刺，你都要重新计算速度。这是至关重要的，因为随着时间的推移吞吐量会发生变化。使用FPA的团队可能从之前的项目中获得交付率，在某些情况下是几个月前的项目。 A lot has probably changed since then. My suggestion is for you to explore Agile and really put effort into understanding story points and velocity. Don’t fall back on estimating in hours just because that’s what you understand. I believe you will thank yourself later.