用蒙特卡洛计划改进决策-InfoQ

本文要点

说明蒙特卡洛计划与基于速度的计划方法有怎样的差异

列举两个例子，展示蒙特卡洛计划的好处，并予以探讨

用 Excel 电子表格实现一个简单的蒙特卡洛示例

看一个很酷、很快速判定人类评估的精确度的方法

了解如何在组织中推广蒙特卡洛计划

在 2010 年，我通过用 C#创建了一个定制的蒙特卡洛计划工具，帮助了一个初创企业 IPO，这个工具可评估新的小型业务产品按期交付的可能性。这个工具的输出，是分布于可能的发布日期上的可能性，帮助软件交付团队及其领导做出决策权衡。当产品按期发布时，恰恰比 IPO 提前了几周，公司的首席技术官和创始人说，这是史上本公司按期交付的首款产品。在用蒙特卡洛做计划之前，这个公司用的是标准项目管理和敏捷计划法。

除了改进评估之外，蒙特卡洛计划还有助于改变制定计划相关的文化和思维方式。当 C 层管理者向工程副总裁询问一个数据时，能够就此数据的可信程度进行充满智慧的交流。该工程副总裁开始说，“发布是不确定日期的，它具有或然率。”这反过来带来重大变革，包括要跟进的指标（从速率到端到端的精细化管理），以及产品管理组是如何思考风险的。

这是蒙特卡洛带来更好的结果和决策的众多示例中的一例。蒙特卡洛计划基于历史数据形成完整的可能性分布。与此相反，标准敏捷计划法形成平均情况分析的直线。

蒙特卡洛计划的简单示例

让我们看一个蒙特卡洛计划的简单示例，来了解一下它的好处。

假设一支 Scrum 团队，它的速率范围从 80 到 120 呈均匀分布。这支 Scrum 团队想要知道在六个迭代版本中将完成多少个点。如果团队简单计算平均速率将得出 6 个迭代能完成 600 个点（6*100）。与此相反，蒙特卡洛会用 20 个样本来进行模拟：

结果显示，6 个迭代有 10% 的可能速率为平均 92，比平均分析显示的整整少了 8%。这个数据马上引起产品负责人的兴趣，发起了一次有意义的讨论：“如果在发布日期到来时，待办事项中 8% 的内容还未完成会发生什么？如果这是不可接受的，我们有哪些选择可以拿出来探讨？”

这个可能性是如何计算出来的？蒙特卡洛采样了历史分布，在本例中是 80 到 120 的均匀分布。为绘制以上图表，我对此分布采样了 20 次。以下为其中一个样本：

这个样本由 6 个迭代构成，因为团队想要评估 6 个迭代的发布。在这个具体样本中，速率范围最低为 91，最高为 120。其平均值为 108.5。在上个图片中，这个样本反映为 X 轴上的那个“108”块状条。

以下为另一个样本：

在这个样本中，速率范围最低为 87，最高为 113，平均值为 95。

假设每个样本都是一种“未来的可能性”。蒙特卡洛从历史信息和恰当的权重创建这些未来的可能性。

蒙特卡洛最大的其中一个好处是，它适用于任何分布，甚至每个都是未知的也可以。在本样本示例中，分布是已知的，问题也足够简单，在 6 个迭代末期可能的分布有一个闭合解。然而，通常实际上没那么简单。

更复杂的蒙特卡洛计划示例

对于那些在真实世界中遇到的问题，不可能或很难快速用蒙特卡洛法得出封闭解。我在客户端遇到过这么一种现实情况，它极为常见，如下：

这个模型的关键部分：

有两个产品开发团队在并行开发。每个团队的速率为 100 上下浮动 20（均匀分布）。
每支团队必须完成 575 个点。
业务验收有 95% 的可能性在一周之内完成，有 100% 的可能性在两周内完成。
这个目标是在 13 周里完成工作：6 个迭代（12 周）开发，一周为业务验收。

该项目按期完成的几率是多少？蒙特卡洛给出的结果是大约 45%。

蒙特卡洛计划与任何直线评估都不近似

由于平均情况分析（比如由许多 Scrum 团队使用的基于计划的标准速率）比蒙特卡洛要更容易，那么很自然就会去想，是否有些平均情况直线评估和蒙特卡洛的结果近似呢？为验证这个可能性，我们将看针对这个更复杂的问题，在三种速率假定下会发生什么情况。

最好的情况假定：项目速率＝120 个点
平均的情况假定：项目速率＝100 个点
最差的情况假定：项目速率＝95 个点

在这三种情况下，业务验收都花一周。很明显，在一开始时这三种评估的工作量相差就很远。最好的情况和平均情况假定下表示有 100% 的可能按期完成，然而最差情况下表示没可能按期完成。

既然最初评估相差很远，那么针对这些假定，多少迭代后得出的结果能与蒙特卡洛一开始得出的 45% 的或然率相接近呢？这里有 20 个样本运行的结果：

该图表显示：

最佳情况分析（蓝线），直到迭代 6，成功可能性都是过于乐观的
平均情况分析（红线），直到迭代 3，成功可能性也都是过于乐观的
最差情况分析（绿线），直到迭代 4，成功可能性都是过于悲观的

总之，没有直线与蒙特卡洛的结果近似。为什么会这样？置信区间的变化与时间平方根成正比，所以任何直线在较长时间周期上都会越来越远。此外，平均情况分析总形成一个单一的结果，要么如期完成，要么不能如期完成，这显然是不对的。

有没有一种方法，可以调整直线分析得出更好的结果吗？一些敏捷专家建议，创建直线近似数去形成置信区间。例如，取近五个迭代的最低的三个速率得出“悲观”评估，而取近五个迭代的最高的三个速率得出“乐观”评估。问题是，这些直线法的实际结果将处于低直线评估和高直线评估之间，而它们会随着时间的变化而变化，它不是恒定的。所以这些直线“低”和“高”的边界是不确切的。正如之前所述，置信区间的变化与时间平方根成正比，所以没有直线接近实际，除非是非常短的时段。

蒙特卡洛的优势

以下是我为什么喜欢蒙特卡洛模拟的原因：

它们是向端到端模拟迈进的一步，是对公司运营和绩效特征的理解。最后，蒙特卡洛有助于回答这样的问题：加一倍的团队数量，或者加一倍的时间，哪个选择更好？
蒙特卡洛针对成本、时间和范围（或其他别的东西）生成完整的可能性分布，它能改进决策制定。
蒙特卡洛克服了标准敏捷计划法的重大缺陷：
对于多支团队或有依赖的团队来说，基于速率的计划实践通常是无效的，因为速率根本就未涉及待办事项中的一个条目到底要花多长时间。而且，在单团队的情况下，基于速率的计划就是直线平均情况分析，它未提供对信心或变数的度量。
SAFe 建议，投票决定对 PI（程序增量）计划的信心：“一旦程序风险已被处理了，团队就对实现计划目标的信心投票。”虽然这种人文主义的计划方法值得赞赏，但它是不完备的，值得用定量的方法予以补充。
未以严谨的方法处理依赖关系。
像所有人类评估一样，在敏捷计划中采用的评估往往有严重的个人和组织偏见。

对蒙特卡洛的担忧

以下是我听说的几个常见的对蒙特卡洛法计划的担忧：

未来与过去不同，由于样本取自历史数据，所以会形成不佳的结果。这可能是个非常技术性的问题，但我更愿意去简化它：系统要么是稳定的，要么是不稳定的。如果它是稳定的，那么历史样本就充分有效。如果系统是不稳定的，那么没有什么预测方法能使管理者足够满意。
创建一个蒙特卡洛模拟很困难。它比做平均情况直线分析要难一些。但使用 Troy Magennis 提供的 Excel 电子表格可以容易一些。在下面的段落中，我将说明如何使用 Excel 去创建一个简单的蒙特卡洛模拟。
高管不理解可能性分布。我同样有这样的体验。所以与其向高管们展示可能性分布，还不如找出关键决策点的可能性，然后这么去交流：“有 15% 的可能无法达成你的目标，你将无法获得回报。”
使用评估的问题不是如何形成结果的，而是如何理解的。无论评估是如何产生的，这都是个非常共性的问题。然而，如果评估方法不是严格定量的，就会演变成政治活动和“管理者的预期值”。
当没有历史数据时，蒙特卡洛是无效的。这一点儿都没错！在这种情况下，我经常建议团队把做计划和评估的时间降到最低，而是开始动手干起来，产出历史绩效数据。

对蒙特卡洛的终极反对意见是，在考虑计划和检查评估时，组织经常缺乏信心和共识，它并不能处理这种情况。缺乏信心和共识就邀请管理者在不考虑历史绩效的前提下设定目标。这种担心可以理解，我建议分别来处理。有许多达成共识的举措，比如分发“价值美元”，邀请干系人去购买特性或截止日期，这将揭示不同的假定和权衡倾向。一旦参与的每个人对当前现实和目标有了共同的理解，蒙特卡洛计划可能就适合了。

证明人类评估不精确

阻碍蒙特卡洛计划的一大障碍是，对人类评估的精确性的盲目自信。

这里有个简单的技巧，我拿来证明一个人类评估是精确的还是不精确的：

选择一个要予以评估的工作事项。在团队层面，通常会是个用户故事。在程序层面，通常会是个方案或工程。
选择一组将要进行评估的专家。在团队层面，几乎总是做这项工作的人。在程序层面，经常是一组高级工程师。
把专家分为两组，请他们分别对该工作事项予以评估。
定义度量的误差。举个简单的例子：设 m 为两个估值的平均值，x2 为两个估值中较大的一个。该指标为 x2/m - 1。例如，如果两个估值为 80 和 120，那么指标为 20%（120/100 - 1）
在形成评估的成本超过其估值之前询问参与者，这个指标会有多差。针对在之前步骤中定义的指标，范围通常为 10% 到 25%。
计算指标并汇报结果。

多半，结果会显示高于需要创建的有用的评估。这为讨论蒙特卡洛的估值，以及应对其太难操作的关注点提供了一个契机。在近期对 400 人的公司的培训活动中，我在大约 30 分钟里执行了这些步骤，一个故事的偏差为 33%（也就是说，乐观估值是悲观估值的两倍）。

如果引入蒙特卡洛计划

蒙特卡洛计划可能不适用于所有的情况。如果条件具备，我喜欢这样去引入它：

理解现有做计划的实践。
说明现有方法和标准敏捷方法的缺陷。
使用公司的实例说明蒙特卡洛法的好处和不同。
量化商业收益。
推广蒙特卡洛计划的应用范围。

第一步往往会被忽视，但它是引入这种变革的关键组成部分（而且，实际上对于任何其他变革来说都是如此）。所幸，我从未遇到过一家享受它的计划方法或觉得结果高度精确的公司。实际上，在财富 500 强企业中，我为一些年度计划负责人提供过咨询，他们告诉我，“计划和实际就没什么关系！”在这种情况下，主要问题是获取历史计划数据，为工作体系建模。

用一个简单的电子表格体验一下蒙特卡洛计划

在 Excel 中可以使用 randbetween 和 hlookup 函数创建一个简单的蒙特卡洛计划电子表格。

公式看起来是这样的：

单元格 A1、B1 和 C1 包含数字 1、2 和 3。把它们假设为最近的三个迭代。单元格 A2、B2 和 B3 是团队在每个迭代达成的速率。

第四行包含以下公式：

=HLOOKUP(RANDBETWEEN(1,3),$A$1:$C$2,2)RANDBETWEEN 生成一个 1 和 3 之间的随机数（因为这里有三个迭代）。调用这个随机数 N，HLOOKUP 返回第 N 个迭代的速率。所以第四行采样历史分布去创建另一个三个迭代序列。

你可以重复第四行许多次，作为你想要创建的直方图（可能性分布），然后做其他类型的分析。在本文开始我给出的这两个例子中，我把第四行重复了 20 次，创建了 20 个样本。大多数蒙特卡洛案例都使用超过 1000 个样本。

总结

蒙特卡洛计划采样历史分布以给出未来可能出现的严谨的、定量的结果。

相比标准平均情况直线敏捷方法，它具有巨大的优势，你可以使用一个简单的 Excel 电子表格开启蒙特卡洛之旅。

其他资源

如果你想要更深入地研究蒙特卡洛计划，可以查阅一下这些其他资源：

InfoQ 文章：#利用蒙特卡洛模拟为未评估的项目制定计划
视频：蒙特卡洛计划
演讲：蒙特卡洛计划（10 页幻灯片）
演讲：蒙特卡洛计划（20 多页幻灯片）
书籍：《预测和模拟软件开发项目》
网站：专注的目标 (Troy Magennis) .
网站：可付诸行动的敏捷 (Daniel Vacanti) .

关于作者

Michael de la Maza 是一名 Scrum 联盟认证的企业教练（CEC）。作为一名敏捷咨询师，他主要为 Paypal、State Street、edX、Carbonite、Unum 和 Symantec 提供服务。以前，他是 Softricity（2006 年被微软收购）的公司战略副总裁和 Inquira（2011 年被甲骨文收购）的共同创始人。它是《Professional Scrum with TFS 2010》和《 Why Agile Works: The Values Behind The Results 》的合著者。他持有麻省理工学院的计算机科学博学位。Michael 是一名活跃的教练，还是 BayALN 的协办方，这是一个在旧金山的敏捷用户群。他热爱参与、创建和分享游戏，共同组织了 2010 年敏捷游戏大会、2011 年敏捷游戏大会和 2016 年敏捷游戏西部大会。他就职于 Scrum 联盟的认证团队教练复核委员会和虚拟教练委员会。他热衷于指导 Scrum Master 和想要深入理解敏捷的敏捷教练。他还通过 Techstars Boston 指导和投资初创企业。