未来十年的敏捷预测技术
《老农民年鉴》是北美最古老的连续出版的期刊。1792年，罗伯特·b·托马斯(Robert B. Thomas)首次出版了这本年历，他希望年历“既实用又幽默”。许多长期关注《黄历》的人声称，它的预测准确率为80%至85%。
这一说法在1816年受到了严峻的考验，当时托马斯在他的历书中犯了一个错误。他的7月和8月天气预报说有雪!他犯了一个错误，把1月和2月的预测改成了7月和8月。虽然他销毁了大部分的雪本，并重印了正确的版本，但仍有一些副本在分发中。但随后，在世界的另一端发生了一些不同寻常的事情。
坦博拉火山于1815年4月10日在荷属东印度群岛(今印度尼西亚)爆发。它“产生了过去一万年中地球上已知的最大喷发。”全球气温下降了3摄氏度，使1816年成为欧洲“没有夏天的一年”。火山灰在地球上盘旋了几个月，降低了温度，猜猜怎么着，1816年7月和8月，新英格兰和加拿大下雪了。托马斯的错误可能会让他破产，但坦博拉火山却不然。相反，这让他的《年鉴》声名狼藉了几十年。
在所有这些不可能发生的事件之后，我非常确定Thomas在未来的版本中实现了一种机制来再次检查这类错误。自然灾害在未来不会总是掩盖他的踪迹。
今天的天气预报比坦博拉火山预报先进得多。卫星、雷达、超级计算机(在不久的将来可能还有量子计算机)每天都在为这些预测提供动力。即使有了这些技术，我们仍然会嘲笑今天有太阳和乌云的概率为40%的预报。谁能预料到呢!
更重要的是，天气预报帮助我们缩小了决策过程。天气预报帮助我们决定是否要带雨伞和雨衣。当我们上班路上路况不好时，他们会建议我们注意驾驶习惯。他们帮我们决定这个周末是否全家去露营。在处理不确定性时，天气有很多不确定性，预测对于缩小我们的决策过程很有价值。
我相信敏捷软件开发已经准备好使用新的预测技术来表达不确定性，从而缩小决策过程。这些新的预测技术不是基于估计，而是基于历史数据，因此节省了开发人员的时间，使他们能够专注于自己最擅长的事情。
预测的定义
为了在接下来的文章中澄清我对预测的定义，我参考了第14章丹尼尔·文森提书可操作的敏捷——可预测性的度量．它说:
预测是对一个或多个项目未来完成情况的计算，包括日期范围和概率。
换句话说，根据Vacanti的预测由以下内容组成:
- 得出日期范围的计算
- 以及达到这个日期范围的概率
由于未来是不确定的，我们不可能对未来事件百分之百正确，因此预测的概率部分。
回到天气预报，我们可以截取当前天气预报的快照，看看这是如何实现的。下面这张来自加拿大环境部的图片显示了温哥华2月份的7天天气预报。请注意，在某些情况下，天气条件附带一个概率:
2月25日(周日)晚上，温哥华有60%的概率有阵雨。
我相信我们可以在敏捷软件开发中使用这个定义。我相信我们的预测不是天气条件，而是完成的PBIs的日期或数量。在这篇文章的其余部分，当我谈论预测时，请记住我是在考虑一个具有概率的计算值。
敏捷软件开发中的预测
当我在工作中进行敏捷计划/预测的对话时，我不止一次地回到了敏捷计划洋葱由迈克·科恩在2009年提出。在他的文章中，我非常喜欢使用这个图表来进行计划/预测对话。
在上图中，每一层规划都将使用一组不同的敏捷实践。例如，在迭代层，我使用用户故事实践来跟踪工作一天层，我们可以使用带有估算时间的任务作为跟踪工作的另一种实践。在这两个层面上，我曾多次看到“冲刺”作为追踪进度和预测工作完成情况的最受欢迎的图表。
在释放或产品层，我已经使用影响映射实践作为活动来为我们的下一个版本生成pbi，并使用史诗来跟踪几个迭代范围内的工作块。我曾看到过版本燃烧上升/下降或日落图作为预测版本的手段。
根据您所处的敏捷计划层的不同，我们使用不同的实践和工具来跟踪和预测工作。我相信上面提到的最流行的敏捷预测工具集限制了我们的决策过程，因为它是在确定的日期上运行的。它们都指向未来的某个日期，但不太可能表达某种程度的信心。正如我们上面所看到的，未来是不确定的，为了表达未来，概率对于缩小我们的决策过程非常有价值。
当我使用上面提到的图表之一进行敏捷计划/预测对话时，它主要落在一天而且产品洋葱层。在过去的十年里，我的经验是，我们使用了估计技术(故事点、速度、以小时计算的任务)来预测这些层次。我认为他们做得不够好，原因如下:
- 它们是基于估计而不是历史数据。
- 它们是确定的，即它们指向一个确切的日期或确切的小时数。
- 当使用预测时，它们是基于平均的。
- 估计(有时)会与实际数据进行比较，以验证它们。
我认为，我们目前的预测技术存在两个问题:
- 这些数据是根据估计得出的
- 他们预测未来没有任何可能性
在下一节中，我将介绍一组与评估方向不同的工具。它们基于您的团队生成的历史数据。
SLE -预报在一天而且迭代层
来谈谈预测一天而且迭代层中，我使用定义的服务水平期望(SLE)Scrum团队的看板指南．
服务水平期望(SLE)预测给定项目在Scrum团队的工作流中从开始到结束所需的时间
例如，假设从历史上看，您的开发团队在8天或更短的时间内完成了85%的PBIs。这是我们对一个项目的预测。它的计算日期范围为8天或更短，概率为85%。
当PBI在Scrum团队的工作流程中移动时，我在工作流程中使用它当前的年龄，并将其与相应的SLE进行比较，以确保它符合其预测。
在我们每天的Scrum中，我们可以使用这个预测来跟踪我们当前的工作。如果我的PBI已经在工作流中工作了3天，与另一个PBI现在已经在工作流中工作了7天相比，我可能不会那么关注它。
我们使用PBI年龄+ SLE的组合来监控我们是否会达到我们的预测，而不是使用带有估计时间的任务来跟踪它的剩余工作。我认为这是跟踪工作的两个有价值的数据点。我也认为他们比估计的时间更有价值。我使用硬数据(年龄和SLE)来跟踪工作。
我相信这可以解决上面提到的两个问题。我的团队不会花时间评估每个任务。如果需要，它仍然可以分解PBIs。但是我们将PBI的年龄与团队的SLE进行了比较。我的团队在其预测中使用了概率，从而为一些不确定性留出了大门，这些不确定性可以防止它遇到SLE。
吞吐量和蒙特卡洛-预测在释放而且产品水平
随着我们在洋葱的更高层次，我们将对话从一个PBI转移到多个PBI。在释放而且产品在洋葱层中，产品负责人现在谈论的是多个PBIs。例如，一个产品负责人可能剩下54个pbi来发布一个版本。或者她可能有一个截止日期，想知道在那个日期能完成多少PBIs。在这两种情况下，预测未来可以帮助她缩小决策过程。正如我们上面所看到的，预测未来需要一个具有概率的计算值。
我的经验是，蒙特卡洛模拟使用吞吐量作为输入，可以生成洋葱这些层的预测。基本上，蒙特卡罗模拟将使用您的历史吞吐量并多次模拟未来(即10,000次)。
让我们以上面的例子为例，看看蒙特卡罗模拟的结果如何帮助产品负责人。我在前面提到过，产品负责人还有54个剩余的pbi来完成她的发布。用她的历史吞吐量运行蒙特卡罗模拟，她得到了以下结果:
她的第一个预测是25天，有90%的信心，她的团队有90%的机会在接下来的25天内交付剩余的54个pbi。在最右边，他们有30%的几率在16天内交货。现在她可以回过头来讨论25天是否是一个可接受的数字。如果他们更愿意在14天内拥有它，她可以回复这种情况发生的可能性小于30%。
为了更详细地阅读蒙特卡洛模拟和帮助您快速完成它们的工具，我推荐这篇文章使用概率创建更快更准确的预测来自我的PST同事朱莉娅·韦伯斯特
我们面前的十年
由于敏捷现在是新的传统软件开发方法，我只希望上面描述的预测技术也能成为新的传统预测技术。在过去的十年里，故事点和时间的估算帮助我们采用了敏捷。尽管不完美，但当该公司询问日期时，他们还是打消了疑虑。
我相信我们现在已经准备好使用历史数据对未来十年进行敏捷预测了。我们的团队已经有了数据。工具集已经存在并且可以访问。人们唯一缺少的是学习、理解和掌握这些新技术。我祈祷在2030年，关于我们的预测的对话将是概率。即使在两者之间，我预测它将发生90%的信心水平。
如果您有兴趣从其他方面了解更多看板知识，请访问KanbanGuide.org．