敏捷估计，预测和承诺

这是一篇有关敏捷产品管理和发布计划的文章。

变化和不确定性

在团队变得敏捷之前的黑暗时代，您将做出估计和做出承诺。 您从未完全实现您的承诺，也没有人真正注意到。 那就是游戏的玩法。 您做出了承诺，每个人都知道这是错误的，但是无论如何他们都希望这样做。 也许您的老板阻碍了您的承诺，取消了工作范围，降低了期望，为计划安排了时间。 哎呀，自从他们计划了金字塔以来，这就是成功的秘诀。

这说得通。

1. 您的早期估计是错误的。 当您将它们加起来时，总数将是错误的。 如果您进行PERT估算 ，那么大数定律将为您提供总体帮助 。 但是你仍然会错的。
2. 外部对您的人员的需求和可用性将发生变化。 计划外的病假时间，人员流失，长期的承诺水平以及许多“人事”确实是未知的。
3. 您客户的需求将会改变。 市场随着时间而发展 。 您变得更聪明，竞争对手变得更好，客户的期望也随之改变。

敏捷流程旨在帮助您交付客户实际需要的内容，而不是最初要求的内容。 对比两个世界。

在旧世界中，您将致力于交付几个金字塔。 在花费两倍的预算，两倍的项目工期后，您将交付一个金字塔。 交付时，您发现狮身人面像风靡一时 。 哎呀。

您的团队变为敏捷，因此您可以交付狮身人面像。 但是您的法老王仍然希望做出承诺以建造一对金字塔（聪明的金字塔将只得到其中的一个）。 如果您利用敏捷估算工作原理的第一原理，那么您可以忠于敏捷，并且仍然可以减轻老板的承诺感。

估算值

承诺是对未来的事实预测。 “这将需要两个星期。” 没有人先见之明。

事实预测必须细微入微。 “我预计*这将不超过两个星期。”

*实际上，这是数学预测的简写，例如“我希望在95％的置信度下，这不会超过两周。”

很少有非科学家，非工程师，非数学家理解95％的置信度具有确切的含义。 人们通常将其解释为“将有超过5％的几率超过两个星期的时间。” 真正的意思是，如果这项完全相同的任务执行了2万次（当然，在假设的世界中），然后完成了1.9万次，那么它将在两周内完成–您感到幸运吗？

要做出这样的陈述，您实际上必须创建一个PERT估计 -确定任务需要花费多长时间的最佳情况，最坏情况以及最可能的情况。

不幸的是，很少有人要求我们对单个任务做出承诺，而要对大量任务进行明确定义，定义错误和未定义。

您可以合并单个任务的PERT估计，从而得出任务集合的整体估计。

这种方法的优点在于， 中心极限定理和大量定律可帮助您估算一组任务–实际上，与单个任务相比，您可以对一组任务提供更好的估算。 显然，这有助于您在项目开始时就知道的定义明确的任务。 这甚至对定义不明确的任务也有帮助。 理性主义者会认为，关键是要进行更多的前期研究以发现未定义的任务，然后我们就开始了。 正如弗雷德里克·布鲁克斯（Frederick Brooks）（《 神话人月》 ）在“设计设计”中指出的那样，自笛卡尔和洛克以来，这种争论一直在进行。 这不是一个新主意。

到目前为止，大型前期设计和要求（BUFD＆BUFR）的效果不是特别好。

但是，不要将婴儿洗澡水扔掉。 估计的数学仍然很重要和有用。 即使经验主义不是万灵丹。

预测

估计是一种预测形式。 甚至敏捷团队也能做到。 在Scrum中，您可以估算用户故事的集合-代表复杂性的故事点，并预测团队可以在此sprint中完成多少点。 注意时间因素。 如果您要进行为期两周的冲刺，则在两周的时间内人员变动的风险很小。 还有风险非常小，你的市场将在两周显著改变-如果确实如此，什么的几率是你会发现和发生重大变化在两周内你的要求？

在视觉上，让我们将PERT估算值转为横向–这样我们就可以介绍时间的维度。 想象一下，您估算了所有任务（定义明确，定义不明确以及对未定义的猜测 ）， 就好像它们都是在第一次冲刺中发生的一样 。 忽略任务间的依赖关系，并假装您拥有无限的资源，并且能够并行执行所有任务。

上图显示了总估算值-圆圈是您的最佳预测 ，误差线代表您对估算值的置信区间。 如果您使用的是PERT估算值，则这些值可能代表5％和95％的置信度线。 根据您团队在该领域的经验和您对猜测的信心（关于未定义的任务），主观地选择一些东西。

我们需要对“最佳瀑布”方法进行评估，以窃取和转化一个好主意。

不确定圆锥

Construx的人们发表了一个很好的解释，说明了不确定性的根源 -改编自Steven McConnell的软件估算：Demystifying The Black Art （2006）。 该文章经许可使用了他的图像-因此，请在此处查看。 想法是，随着对项目的更好定义（例如，在项目期间 ），不确定性的数量会减少。

研究结果表明，初始估计值降低了400％（低4倍或高4倍）！ 即使在“细化”要求之后，估算值仍然下降了30％到50％！

听起来很糟，但实际上更糟。 这是对原始项目 （交付金字塔）的预测。 您的估计不仅是错误的，而且对于交付错误的产品来说也是错误的估计 。

但是-核心思想是合理的-您必须执行得越远，估计中的错误就越大。

采纳该概念并将其应用于我们的图表，我们得到以下信息：

您尝试预测的越远， 预测的准确性就越低。 准确性的降低反映为您估计值的置信度范围扩大。

• 几个Sprint的工作价值与一个Sprint的区别不大-因此您的估算范围没有太大变化。
• 完整的冲刺（例如6到10个冲刺）释放给未知者复活的机会更多。

现在，您的预测（可能）含糊不清且不准确。 “这组任务将需要X加上或减去两个因数。”

那是现实。

注意：这一直是现实。 从历史上看，人们通过隐藏“变更风险”方面来减少这种“计时风险” –瀑布式流程鼓励您尽可能快地按时交付错误的信息。

但是，这不是我们想要做的。

我们仍然希望尽可能高效地交付（尚未定义） 正确的产品。 这就是敏捷的目标。 （对于已经在泰纳·布兰（Tyner Blain）待了很长时间的人来说–“正确”既包括价值，也包括质量。 细化

因为我们敏捷，并且愿意随着时间的流逝“变得更聪明”，所以我们有机会进行改进。 由于复合估计的性质和不确定性的锥度，我们的不确定性会随着时间而变小。

让我们消除人为简化的想法，即我们可以“立即”进行所有操作，并查看一下我们认为在发行即将结束时所掌握的知识。

我们在发布结束时预测工作量（针对今天的产品定义）的能力不是很好。

我们预测（今天对产品的定义）未来冲刺的能力要好得多。

完成第一个冲刺后，我们会更聪明 -定义不明确的任务会更好。 也许某些未定义的任务现在定义不正确。 现在，同一锥度的不确定性变小了–我们变得更聪明，发布日期的时间范围也更近了。

趋势仍在继续-每个冲刺使我们更接近发布日期，并且随着每个冲刺（假设我们从客户那里得到反馈，并继续研究我们的市场），我们会变得更加聪明。 我们还可以更好地预测团队的速度（他们在每次冲刺期间可以交付多少“产品”）。

承诺

但是，您的老板仍然想要一个承诺。 这就是我们（再次）改变看待这个问题的方式的地方。

上面的图都显示了我们如何收敛于稳定工作量的估计。 但是，我们知道工作的主体在不断变化。

积压！ [你说]

是! 积压。 待办事项列表是按顺序排列的用户故事和错误的优先列表。 上个月，我与Innovation Games的 Luke Hohmann进行了交谈，现在最受欢迎的在线Innovation Game之一是他们根据bang的优先次序创建的一款。 立即在线播放（免费！）。 多么酷啊？

积压订单代表团队将要完成的工作-按照团队执行的顺序。 随着时间的推移，随着我们变得越来越聪明，我们将在积压工作中添加和删除项目–因为我们发现了重要的新功能，并且因为我们了解到有些事情不值得做。 当我们认识到市场（或我们不断变化的战略）中不断变化的优先事项时，我们甚至将重新排序积压的订单。

发生这种情况时，事实证明，列表顶部的项目最不可能被替换，因此，在我们发布产品时，很可能仍然是产品的一部分。

与其考虑花费的时间不确定性，不如考虑在固定时间内完成多少不确定性。 通常，在敏捷中，我们采用时间盒方法来确定要构建的内容。

现在，不确定性，而不是表现为“我们什么时候完成？” 变成“ 我们将完成什么？”

你的老板很理性。 她很欣赏这些限制，她只想知道您可以做什么 。 与我合作过的每个老板都愿意（有时只是经过大量讨论）才可以用什么而不是何时来处理这种不确定性。 他们承认他们需要将（通常是给老板使用）转变为“固定的”承诺。

解决方案： 承诺您可以完成的预测的子集。

在发行开始时，您可能拥有价值500点的故事。 根据团队的预期速度和发行版中的冲刺数量，您预测可以完成价值320点的故事（团队中5人，团队速度为每个冲刺40点，发行版中有8个冲刺） 。 从待办事项的顶部开始，然后向下进行，在您可以完成的最后一个故事（达到320点）上画一条分界线。 这是你的预测 。

现在承诺部分。 您必须弄清楚自己的适应能力。 也许要进行8次冲刺（例如，在未来的16周内），您可能会很乐意投入一半的数量-160分。 返回待办事项列表的顶部，递减计数，直到达到160分。 生产线上的一切都是您承诺交付的。

也许您很愿意提交240分，也许只有80分。这就像玩黑桃。 您可以承诺而不遗漏的东西越多，您的生活就越好。 您对风险的承受能力与我的不同。

您也可以与老板协商 。 现在提交160点，并在每隔一个冲刺后提供更新。 很有可能，每次更新都会扩大您的承诺范围。

在项目中更新“我们可以做更多”总是比“我们可以做更少”更好。 两者都比项目结束时的惊喜好。 这也使您可以拥有如下所示的更新：

我们在发布之初并不知道这一点，但是X对我们的客户而言确实很重要- 除了我们已经承诺的内容之外 ，我们还可以提供X。 不拖延发布日期。

结论

用敏捷的过程做出承诺并非不可能。 只是需要采取不同的方法（如果您想保持敏捷敏捷）。 最终结果是：更好的预测，更切合实际的承诺以及每次更新将成为好消息而不是坏消息的可能性。

别忘了分享！

参考： 业务分析| JCG合作伙伴 Scott Sehlhorst提供的敏捷估计，预测和承诺 | 产品管理| 软件需求博客。