预测，不要猜测您的软件项目

“这件事什么时候做？”作为一名软件开发人员，我几乎每周都会被问到这个问题。尽管在过去的15年里以专业的方式构建软件，但令人悲哀的现实是，我不知道什么时候会做一些事情，很可能您也不知道。

你参与过多少个项目，其中最大的挫折是预测构建一个功能实际上需要多长时间？如果您是一名开发人员，我敢肯定，当人们要求您使用斐波那契积分系统来表达复杂性时，您一定会感到沮丧，因为后面经常会有人说您的估计“听起来有点高或低”。如果您是一个产品所有者，我相信您一定会因为开发人员不能为您提供您想要的下一个特性的具体时间表而感到沮丧。

但我有好消息要告诉你！实际上，通过对团队的历史数据使用一些相当简单的统计数据，您可以获得更准确的预测。请听我说，这篇博客文章解释了如何实现这一目标的基础知识。

这里有一个小小的比喻，它突显了回答“什么时候能完成”这个问题的真正问题：想象一下，在辛苦工作了一天后回到家，却发现钥匙丢了。现在想象一下，在那一刻，我会问你需要多长时间才能找到你的钥匙。你知道这不会是一分钟，但也不是一年，事实上你根本不确定你是否能找到他们。这就是被问到什么时候会做某事的感觉。

事实证明，估计一款软件何时可以发布是非常具有挑战性的。多年来，已经引入了许多技术，但没有一种达到预期的效果。更糟糕的是，他们中的许多人需要团队付出令人难以置信的努力。花费大量时间进行估计的问题是，它可能感觉有用，但往往非常不准确，几乎不能为业务带来太多价值。是的，你也许能对很小的工作量做出一个准确的估计，但这真的是我们需要的信息吗？我并不是说一个特性的大小永远不应该是一个话题，它应该是一个话题，但是如果我们能对这些预测有更多的信心，那将是有益的。这是一个残酷的问题：如果估计几乎不符合现实，那又有什么用呢？您本可以将这些时间花在构建软件上。

一般说来，有两种方法可以尝试预测未来。要么你建立一个你认为事情将如何发展的模型，要么你采取一种黑箱方法，试图从历史结果中获得信息。我认为软件开发太复杂了，不能使用前一种方法。然而，事实证明，除非您在异常不稳定的环境中操作，否则大多数团队实际上都有相当一致的结果。

不确定性锥体是基于NASA研究的项目管理原则，它表明项目开始时的估计与现实相差高达400%。所以，当我让你估计一件事，你告诉我需要一周的时间，实际上，它实际上是在两天到一个月后的某个时候完成的。但你不需要研究就能知道这是真的，不是吗？几乎每个参与软件开发的人都从经验中知道这一点。

是什么让评估变得如此困难？一个错误是，软件开发通常被视为制造过程，而它从根本上来说是一种设计活动。事实上，制造软件是完全自动化的：编译器或解释器获取源代码，并根据您的需要制造任意数量的产品化身。不需要人类。所有的努力都集中在程序的实际设计上。设计本质上是不可预测的，因为它是关于创造以前不存在的东西。这意味着有很多未知数，因此有很多不可预测性。

另一个陷阱是没有考虑等待时间。等待时间是工作开始后暂停的时间量。当你考虑估算的时候，你通常会想到一口气完成任务需要多少时间。然而，在现实中，各种各样的事情都会打断处理该任务的流程。几乎可以肯定的是，他们要参加会议，周末要在海滩上度过。想一想对另一个团队的依赖延迟了您的软件的次数。

这方面的一个众所周知的示例是集成：从API获取用户电子邮件之类的数据并将其显示在屏幕上可能并不困难，但实际上，我们发现有时API并不像宣传的那样工作。它们可能需要单独的身份验证，并且可能有自己的错误行为，实现者必须考虑这些错误行为。

一件软件设计花在等待工作上的时间是令人难以置信的不可预测的。当您开始测量活动时间与等待时间的比率时，您很快就会意识到，通常是等待时间占用了大部分时间才能实现增量。然而，在提出估计时，它并没有考虑到这一点。

我在这里告诉你，有一种更准确的方法来预测软件的交付时间，它与直觉相反，涉及到将人为估计的作用降到最低。相反，您可以查看团队的历史数据并应用统计技术。

排队论是对排队等候的数学研究。例如，它用于预测队列的容量或事物流过队列的速度。它可以应用于从主题公园到电话网络的各种领域。我们还可以将排队论的逻辑应用到我们的开发过程中，以便对其结果做出更好的预测。

无论您使用哪种项目管理方法，您都可以将您的流程视为一个将想法作为输入、将软件作为输出的队列。有大量的研究已经分析了这样的系统，我们可以很容易地应用这些发现来创建对交付时刻的预测，以及这样一个过程的能力。

队列具有某些属性，如进行中的工时量(WIP)、工作通过该队列所需的时间(周期时间)以及每单位时间从中产生的工作量(吞吐量)。因此，我们可以使用这些属性作为回答有关交付时间和团队能力的问题的基础。

例如，您的团队的历史吞吐量可用于运行未来吞吐量的模拟。有些结果会比其他的更有可能，你可以用这些数字来得出这样的声明：“41个或更多的项目可以在30天内完成，确定性为85%”。

使用这样的方法的好处是，它可以用最少的努力来完成，并且当有更多的信息可用时，它会随着时间的推移自动更新。不需要与团队坐几个小时，并猜测流经队列的工作项的大小。在分析数字时，工作项大小的差异是给定的，并被考虑在内。

还在听吗？太棒了！让我们把这件事付诸实践吧。如果我们试图确定某项工作将在何时完成，我们可以开始查看工作通常需要多长时间才能流经我们的流程。

要做到这一点，我们要开始测量周期时间。周期时间是一件工作从开始到结束所需的时间。很重要的一点是，您要定义流程中的那些起始点和结束点到底是什么。例如，我们是从想法开始的时间、承诺的时间还是工作开始的时间来衡量？您必须为数据点一致地定义这些边界。

我们将使用周期时间的这些数据点构建散点图，在垂直轴上显示测量的周期时间，在水平轴上显示完成日期。看看这块地，我们是否已经可以断言到目前为止完工的工作的完成日期？

我想我们可以的！查看上面的示例图，我们可以确定到目前为止没有超过43天的完成时间。请注意，我们如何在不知道已完成的每个单独工作的大小的情况下做出此断言。

然而，大多数项目的完成速度要快得多。您可以开始使用百分位线分割绘图。如果你通过点数来划分情节，创造一个天花板，在那里你已经包括了85%的项目，那么我们可以得出结论，85%的工作只花了不超过16天的时间就完成了。您可以上下移动这条百分位线，以获得您的情况所需的确定性。

这是一个很好的方式来回答这个问题：什么时候完成？它考虑到了变化，有一个确定性的百分比，没有人的偏见，可以几乎自动的方式获得。

能够预测单个工作项需要多长时间是很有用的，但是更常被问到的一个问题是：我们在下一段时间内可以做多少？

作为这个预测的基础，我们将以我们的流程的吞吐量为基础。吞吐量是以时间为单位从项目中产出的工作量。您可以自行决定哪些单元对您的上下文有意义。几天、几周、短跑、故事、虫子、史诗--只要你始终如一，什么都行。让我们假设对于这个示例，我们正在测量每天的故事量。您可以计算每天有多少故事到达流程的末尾。

使用每天吞吐量的数据集，我们可以运行蒙特卡罗模拟来帮助我们绘制可能的结果。运行模拟的单个迭代的工作原理如下：

重复这个对可能结果的小模拟很多次，比如说10.000次，我们可以更好地了解哪些结果可能会发生。让我们用结果构建一个直方图。水平轴表示完成的楼层数量，垂直轴表示该数字在10.000个模拟中出现的频率。

由此可见，有些结果比其他结果发生得更频繁。模拟更有可能以80个故事(超过200次)结束，而不是40个故事(大约10次)或120个故事(50次以下)结束。根据这些数据，您认为团队在30天内完成70到90层的可能性有多大？

与我们的第一个示例一样，我们可以使用百分位线在直方图中绘制确定性间隔。我们可以将直方图一分为二，两边的结果数量相等，并得出结论，我们有50%的可能性完成那么多的故事。这是掷硬币！

按照这个逻辑，我们还可以以这样一种方式划分直方图，从而获得不同程度的确定性。在这个例子中，我们断言67个故事将在接下来的30天内完成，确定性为85%。

同样，我们只是通过查看我们的历史数据，很少的努力，没有对每个故事的大小进行任何猜测或意见，就得出了这个数字。想象一下，如果您准备好这些类型的统计数据进入会议，您的下一次冲刺计划将会有怎样的改进。

当将上述方法应用于您团队的数据时，您可能希望得到更精确的预测。提高预测的精确度是一个行为更具预见性的问题。关键是要始终如一。

想象一下，对骑自行车去办公室所需的时间进行预测。你可以测量每天到达那里所需的时间，并将其作为预测的基础。现在想一想，如果你决定随机绕道，而不是选择最快的路线，你的预测会发生怎样的变化。可能结果的集合会大得多，所以你的预测会变得不那么精确，因为它会考虑到这种不确定性。

幸运的是，表现得更有预见性既能提高团队合作能力，也能提高你的预测能力。当您使用遵循看板实践的团队的历史数据来限制允许同时开始的工作量时，您可以在实践中看到这一点。这大大减少了过程中的等待时间。变化量的减少将导致更准确的预测。同时，在制品限制将提供一种共享所有权的感觉。

在一个项目中，当完成一项任务所需的时间有违反我们的预测的危险时，我的团队决定开始结对编程。这降低了我们数据的变化量，同时也为协作提供了巨大的激励。用上面的自行车例子来说，变化较小相当于骑更可预测的自行车去办公室。

就我个人而言，我也发现我们的历史数据在促进团队回顾时很有价值。这些数据能够引导我们找到这个过程中的某些痛点。因此，收集这些数据的应用当然不限于进行预测-它还可以帮助识别瓶颈和需要改进的领域。

这听起来可能有很多工作，但实际上并非如此。即使您没有使用数字项目管理系统，您也可以从记录流程中每一块工作的开始日期和结束日期开始，并将其作为预测的输入。您可以从一个简单的电子表格开始。

你也不需要很多数据。根据我的经验，大约完成十个项目已经足够对目前的情况有一个比较稳定的看法了。更多的数据并不总是更好的。这是关于为您的上下文选择相关数据。如果你的团队发生了巨大的变化，你可能会更好，而不是使用多年的无关数据来污染你的预测。

现在你很高兴可以开始预测了，有几个小问题要提出来。在开始之前，你真正应该问自己的一件事是：你为什么首先要估计？对于许多团队来说，将工作划分为可管理的块并定期确定工作的优先级就足够了。另外，要真正了解您对预测的期望结果-请注意，我在这里介绍的两个过程有一个非常具体的用例。这些预测不应该用来判断人们的生产力或项目所需的预算。

现在我们已经解决了这个问题，如果这听起来很有趣，有两本丹尼尔·瓦坎蒂写的书，我觉得这两本书对这个主题有很大的信息量。可以通过Leanpub获得可操作的敏捷指标以及何时完成。

谢谢你一路陪伴我！关于这个话题，我要说的比我在这篇博客文章中涵盖的要多得多。在Reaktor，我们提供预测培训，我们详细介绍如何应用这种方法。我们还可以帮助您查看您团队的数据，并帮助您将此预测方法应用于实践。为什么不尝试一下呢？如果你想开始对话，欢迎发电子邮件给我：[email protected]。你唯一要失去的，就是你能赢得的时间。

(C)2020个Reaktor。Reaktor是Reaktor Group Oy在欧盟、美国、日本和其他各种司法管辖区的注册商标。隐私政策：英文/索默斯语