如何估算软件开发时间（1）

如何管理软件项目是一个复杂的问题，有很多需要理解的地方，对于软件估算中什么是合理的和可能的，也存在很多误解。

想象一下，下面的这个场景：

“我这有一个项目，这个项目很简单，硬件基本上已经到位了。我们想让你写一个软件，当用户拨打某个电话号码时，它会把信息传送到有这个号码的信箱里，来代替打电话。” 

"这不是很容易吗？" 

"那么你需要多长时间才能准备好呢？" 

“下周三，可以么？”

“需要多长时间”这个问题总是很难回答。我们应该回答它吗？如果应该，那我们该如何回答？我们应该如何进行软件估算？

我想探讨一下软件开发人员面临的困扰。

事实上，「估算」一直发生在我们的生活中，随时随地。我赞同这样一种观点，即在可能的情况下，最好避免估算，而是在小步骤中尽可能高效地工作。我们的软件在每次小的更改后都可以发布，这是一个被称为「无估算」的版本。

虽然，我认为这对一个优秀的团队来说是最有效的方法，但它确实依赖于为软件买单的人。他们要信任那些依赖其专注、勤奋和尽可能高效地工作在真正重要的事情上的人，它依赖于工作人员将注意力专注在真正需要做的事情上，这真的很重要。

比如，你是一个软件工程师，自己刚刚开始独自创业，希望通过自己正在开发的一款软件，实现某种自由。此时，你是否需要估算自己多长时间能完成？此时，你绝对相信你自己，相信你在做最重要的事情。此时，你就不需要估算。

然而，「不做估算」基本是做不到的，尤其是在大型组织中。大多数组织要求的出发点显然是可预期性（准确性）。

如果你让我做什么，我可以告诉你我需要做什么，需要多长时间，这不是很好吗？这会让计划变得更容易。

假如是像煮咖啡这样简单的事情，我可以根据沸水的物理原理，重要的是我煮很多咖啡的实际经验，重复很多次了，所以，可以给你一个相当准确的估算。

但即使是像这样简单的事情，我们也必须首先达成一致，当你问我要一杯咖啡时，你的真正意思是它是即时过滤的，还是需要我从头开始磨咖啡豆，这样即使是看起来很简单的东西，它也会非常新鲜。

重要的是，我们要清楚我们对目标的假设是什么。而且「把目标清楚地建立起来」并不总是一件容易的事情，系统越复杂，我们就越不可能在早期确定明确的目标范围是什么。不幸的是，一旦我们跳出像煮咖啡这样简单的事情，预测未来就变得更加困难。

事实也确实如此。

完美计划意味着什么呢？

首先，我们需要理解目标，就像煮咖啡一样，需要准确地说明我们的期望是什么，对于任何非常复杂的系统来说，这可能都是不现实的。

接下来，我们需要了解实现这一目标所需的所有步骤，在开始行动之前，将问题的解决方案分解为可能再次发生的所有活动。

然后，我们必须知道每一步需要多长时间。

然而，要想知道确切时间，我们面临很多问题，例如：

1、  我们以前做过这种事情吗？

2、  我们以前使用过这些技术吗？

3、  这个团队以前合作过吗？

4、  我们是否依赖其他团队提供帮助？

以上所有这些事情都会影响我们做出预测的能力，如果我们的计划想要准确无误，那么我们也需要预测所有沿途可能影响我们的中断和阻碍。

问题是，如果我们正在构建一个软件系统，那么我们可能事先对这些事情一无所知，而且还有很多事情，我们尚不知道由谁来做，如果我们在尝试一些新东西，技术会如何发展等等。

事实是，软件开发中的「估算」，可能使用「猜测未来」更为准确。我们每个人写出来的软件代码，其所要达成的目的都是不重复的。如果是重复的，那它已经被封装成「库」，并被重用了。

关于估算的数据很有趣，在20世纪90年代出版的一本很棒的书《快速开发》中，作者是史蒂夫·麦康奈尔，他当时在微软工作。估算数据表明，无论你是在进行详细的函数点分析，还是在对你的函数点进行猜测，估算的误差范围都大致相同。平均而言，你在这一点上做出的猜测的估算，几乎总是被低估，所以它在完成时几乎是原来估算的四倍多。

那么显而易见的解决方案是，为什么我们不把所有的猜测都乘以四呢？问题在于，当你给出这个估算时，就没有客户会购买你的服务，甚至开始这个项目了。因此，许多组织接下来要做的是混淆准确性和精确性。

举个例子，我可以说π是3比说它是17更准确，说π是3.14比说它是3更准确，而如果说π是17.630231好像看起来更精确，但它是不准确的。

许多组织在面临估算问题时所做的是，他们专注于试图提高估算的精度，而忽视了准确性。

你检查问题的细节越多，你试图估算的细节就越多，问题看起来就越大。

准确度与精准度的另一个方面是理解有意义的准确程度。在我们估算的情况下，误差范围很重要，这在很大程度上取决于估算的原因。如果你试图估算一个大项目，也许是为了把它卖给客户，或者是为了在一个大组织内提高预算，这与为下一个迭代周期估算一些用户故事是完全不同的。

我现在认为，在较小的时间范围内，预测未来最可靠的方法是回顾过去，然后进行推断，并在较小的时间范围内进行推断。

因此，对于需要很长时间的工作，更喜欢对小事情进行大量估算，而不是做一个大的估算，减少工作的批量可以提高预测的准确性。

我们可以从过去的经验中推断出的一种方法是：看看我们在以前项目中的的类似任务，它们真正花了多长时间，这比根据对一些想象设计的详细分析进行猜测要好。因为根据详细分析可能会给我们带来一种精确的错觉，但准确性很低。

我们不会在估算时对预期设计进行详细的探索，而是会对其进行足够详细的讨论，以发现与以前项目的相似之处，并使用我们以前经验中的数字作为估算的依据。这个功能有点像我们上周做的那个，花了三天时间，所以我们认为这个新功能需要花费三天。

一般来说，我们不善于猜测一项特定任务中有多少工作量，我们更善于猜测两项工作任务中存在多少类似的复杂度，这给了我们一个可以用来估算的工具。

当开始进行估算时，将一些即将参与或可能参与到这个工作中的人聚集在一起，三四个人可能正好。

我们要限制精确的错觉，经常使用的一种技术是根据T恤大小的S、M、L进行估算，如果你达到了L，那么问题就太大了。我们要回到需求上来，把它分解成更小的步骤，越小你的团队做得越好。理想情况下，以S、M、L的值为指导，将工作分解为可以在几天内完成的功能（features），最多可以在一两周内完成一个大型功能（features）。

在估算时使用的一条经验法则是：现在不是选择完美设计的时候。我们的目标是设想一种可能的设计，我们只假设这就是我们要采用的设计。在这一点上，我们不会为什么是正确的设计而苦恼。如果估算的范围很接近，那么我们只会在平均值上达成一致，并且在计算平均值时，我们倾向于选择较高的值而不是较低的值。

如果其中一个估算值是一个很大的异常值，我们让提出异常值的人解释一下他的理由。他可能看到了其他人都忽略了的重要事情，或者他们只是对一些比其他人看到的更复杂的解决方案感到恐慌。

进行对话并把它说出来是很好的，谈论得足够多，能够理解他们为什么做出这样的估算，并作为一个团队就工作的T恤尺寸达成一致。

T恤方法有两个优点：

1、它限制了精度，我不会浪费时间去估算比小的更小或比大的更大的东西；

2、它也迫使我们把工作分解成更小的部分，这是一件好事。

理想情况下，你的工作方式是不断发现新的任务，并在执行过程中对其进行优先级排序，而不是在项目一开始时发现所有的任务。

当我们在更大的范围内进行估算时，更准确的方法是随着项目的进行跟踪我们最近的实际表现，并从中进行数学推断。

下一篇，我们将给出一个估算软件开发时间的方法。

乔梁老师开课啦~视频课程《持续部署训练营（Python版）》， 限时特价！

你的软件开发效率够高吗？质量够好吗？你的团队多长时间才能向用户实时推送一个生产变更？你的软件在发布时，你是否因担心软件交付质量而感到压力倍增？你是否遇到过部署失败，甚至导致停机的情况？持续部署可以帮助你消除软件交付的痛苦，让你能专注于为客户高价值的需求，而不会因为这些交付执行类问题而花太多精力。本课程通过学练结合，理论结合实战，让你体验如何使用构建-测试-部署管道，进行持续部署。并练习如何在有效监控部署的同时，逐步发布功能特性，并作数据库结构变化。

（扫码订阅）