写点什么

用蒙特卡洛计划改进决策

2017 年 5 月 23 日

本文要点

  • 说明蒙特卡洛计划与基于速度的计划方法有怎样的差异
  • 列举两个例子,展示蒙特卡洛计划的好处,并予以探讨
  • 用 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% 的可能无法达成你的目标,你将无法获得回报。”
  • 使用评估的问题不是如何形成结果的,而是如何理解的。无论评估是如何产生的,这都是个非常共性的问题。然而,如果评估方法不是严格定量的,就会演变成政治活动和“管理者的预期值”。
  • 当没有历史数据时,蒙特卡洛是无效的。这一点儿都没错!在这种情况下,我经常建议团队把做计划和评估的时间降到最低,而是开始动手干起来,产出历史绩效数据。

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

证明人类评估不精确

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

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

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

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

如果引入蒙特卡洛计划

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

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

第一步往往会被忽视,但它是引入这种变革的关键组成部分(而且,实际上对于任何其他变革来说都是如此)。所幸,我从未遇到过一家享受它的计划方法或觉得结果高度精确的公司。实际上,在财富 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 电子表格开启蒙特卡洛之旅。

其他资源

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

关于作者

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 指导和投资初创企业。

查看英文原文: Monte Carlo Planning Improves Decision Making

2017 年 5 月 23 日 17:15962

评论

发布
暂无评论
发现更多内容

一个典型的大型互联网应用系统使用了哪些技术方案和手段(作业)

互金从业者X

谈一谈年终奖中的那些坑

张小方

程序员 面试 offer 薪资 年终奖

聊一聊 HashMap

江城子

Java hashmap

计算机操作系统基础(九)---存储管理之段页式存储管理

书旅

php laravel 线程 操作系统 进程

k8s 上运行我们的 springboot 服务之——flume同步数据到到clickHouse

柠檬

k8s log Clickhouse SpringBoot 2

环信荣登36氪WISE2020企服金榜-智能客服榜首

DT极客

区块链系列教程之:比特币中的共识

程序那些事

比特币 区块链 共识与信任 分叉

从0-1学习项目方案设计

赵孔磊

原创 | TDD工具集:JUnit、AssertJ和Mockito (二十四)编写测试-内建扩展

编程道与术

Java 编程 TDD 单元测试 JUnit

一文彻底掌握二叉查找树(多组动图)

淡蓝色

Java 数据结构 算法

ARTS 第 4 周

乌拉里

架构师0期04周命题作业

喵呜的小哥哥

系统架构:学习小结

行下一首歌

极客大学架构师训练营

week 04 作业

Safufu

week 04 总结

Safufu

分布式系统架构学习总结(第四周)

~就这样~

慧点OA转战政企市场,钉钉们羡慕么?

人称T客

【思考】-产品等级与市场定位匹配

superman

定位 产品定位

一个典型的大型互联网应用系统使用了哪些技术方案和手段,主要解决什么问题?请列举描述。

~就这样~

Redis系列(四):天天用着Redis集群,主从同步该知道吧?集群工作原理是否需要了解下?

z小赵

Java redis 高并发 高并发系统设计

点赞功能,你用 MySQL 还是 Redis ?

Java小咖秀

MySQL redis 分布式 分布式系统 经验

揭秘金山云云游戏PaaS服务平台背后的视频编码技术

Geek_116789

中国人口红利将转化成工程师红利,但是这到底是谁的红利?是程序员的悲哀还是无奈?

非著名程序员

程序员 程序员人生 工程师 工程师红利 无代码开发

一文读懂 TypeScript 泛型及应用

阿宝哥

Java typescript 前端

架构师0期04周总结

喵呜的小哥哥

Week4总结

王志祥

极客大学架构师训练营

从 0 到 1 搭建技术中台之推送平台实践:高吞吐、低延迟、多业务隔离的设计与实现

伴鱼技术团队

kafka 缓存 分布式架构 消息推送 push

架构训练营 0 期总结 -- 第四周

互金从业者X

系统结构:作业

行下一首歌

极客大学架构师训练营

架构师训练营第四周感悟

张锐

极客大学

如何构建你自己的 JVM (2) HelloWorld

孤星可

Java JVM 深入理解JVM

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

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