敏捷 承诺 勇气_敏捷估计，预测和承诺

敏捷 承诺 勇气

你的老板想要一个承诺。 您想提供一个预测。 您说的敏捷仅允许您估计和预测-不能承诺。 “曲棍球！” 您的老板大声说道：“我要one咽，如果您不履行承诺，就去做。” 有一种方法可以使用敏捷原则来避免陷入公司绞刑台–进行估计，预测和承诺。

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

变化和不确定性

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

这说得通。

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 buck的优先级创建的一款。 立即在线播放（免费！）。 多么酷啊？

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

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

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

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

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

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

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

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

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

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

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

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

结论

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

别忘了分享！

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

翻译自: https://www.javacodegeeks.com/2012/09/agile-estimation-prediction-and.html

敏捷 承诺 勇气