PMI，请不要再用Scrum误人子弟了

Posted 2021-04-23 码农的人生

    Scrum 是时下流行的软件开发方式，连 PMI 也推出了 Scrum 相关的认证科目：PMI-ACP。

    大多数观点认为 PMI-ACP 有助于 Scrum 的推广，帮助更多项目走向成功；也有人认为 PMI 在误人子弟，它让 Scrum 项目走向歧途。

    本文作者 Stacey Christiansen 的观点倾向于后者。

PMI，请不要再用Scrum误人子弟了 From 码农的人生 00:00 10:15

项目管理协会致力于项目（project）管理、项目集（program）管理 和 项目组合（portfolio）管理，迄今为止已有 50 年了。它的 使命 如官网上所描述的：“站在客户的角度，致力于提升全球项目管理的专业水准。”

项目管理协会撰写的PMBOK（项目管理知识体系），被奉为项目管理的圣经。这本书非常厚，共有 756 页。

作为项目管理的权威组织，它提供了 8 种认证，而 PMI-ACP （PMI 敏捷认专业人士）是其中之一。下面我即将批驳的，就是这门认证课程。

在批驳它之前，我先声明一下，我有 PMI 多门认证证书。除了 CSM、CSPO 和 CSP 之外，我还获得了 PMP 和 PMI-ACP 认证。我自认为有足够的资格评判它。

PMBOK与《敏捷宣言》的基本原则相冲突

PMI 因为错误的目的而进入敏捷领域

PMI-ACP 是一个赚钱的游戏，简单、粗暴。敏捷框架（尤其是Scrum）在项目管理中的使用越来越广，PMI看到其中的商机，也想分一杯羹。于是，PMI-ACP 诞生了。更多的认证、更多的培训、更多的会员，这都意味着更多的收入。是的，即便非盈利组织也需要赚钱。

Scrum 中没有项目经理的角色，这引起了 PMI 的担忧。随着传统瀑布模型逐渐被 Scrum 框架替代，项目经理也会逐渐淡出，而 Scrum 中的角色将取而代之。如果这成为现实，那么 PMI会面临什么状况呢？Scrum 越流行，项目经理就越少，那就意味着 PMP 会越少，PMI 的现金流就会面临巨大的风险。

根据 2018年 PMI 年度报告，全球的会员费、证书和书籍销售共计收入 2.39 亿美元，其中包括 600 万本 PMBOK 的发行量。PMP 是 PMI 的旗舰产品，如果旗舰产品遭遇滑铁卢，后果不堪设想。

PMI-ACP — 怪胎的诞生

在讨论这个问题之前，我们先确保大家处在同一频道：Scrum 中没有项目经理角色。而 PMI-ACP 中引入的“敏捷项目经理”不过是个怪胎。

当一个组织在运行 Scrum 时，原来瀑布模式中 PM 的 功能被分散到 Scrum教练、产品负责人 和 开发团队这 3 个角色中，并且某些传统的 PM 功能已不复存在。

而“敏捷项目经理”这个角色使得团队在过渡到 Scrum 框架的过程中，让组织变得紊乱，甚至冲突，没有人能完全搞清楚各角色的职责。

我并非危言耸听，以下内容（PMBOK中的原话）便是明证：

看，就是这个认证

这段话翻译过来如下：

PMI-ACP横跨敏捷的多个领域，如 Scrum、Kanban、Lean、极限编程（extreme programming，简作XP）和测试驱动开发（test-driven development，简作TDD）。所以，无论你当前从事何种项目，这门课程都会增加你的知识广度。

仅仅通过一次考试，一个刚获得证书的人就能对5个不同的敏捷领域有深刻的理解，可能吗？

如果你仍没觉察到问题的话，我们再来比较一下 PMP 和 PMI-ACP 的准入门槛。

PMP	PMI-ACP
考试内容包含200个题目	考试内容包含120个题目
4年制本科	高中毕业
3年经验	1年经验
35小时培训	21小时培训

两门认证的门槛

我取得了三门 Scrum 认证。为此，我参加过正式的课堂培训，参加了为期多天的Scrum（或 敏捷）会议，花费了大量的时间学习 Scrum 知识。我是领导团队成员，负责把项目开发从瀑布模式成功地过渡到敏捷框架。我有 20 多年的软件开发经验，超过 10 年的 Scrum 经验，即便如此，我仍然认为自己不过是个 Scrum 新手，还有很多要学习的。

Scrum 需要经验丰富的专业人士，无论是 Scrum 教练，还是产品负责人，都不是入门级的角色，经验不足的高中生根本无法胜任。

获取 PMI-ACP 的准入门槛也说明，PMI 没有认真看待 Scrum，它不过是市场需求突变时，为了应对它而采取的一种错误的应急措施。

PMI 与 Scrum 存在基本理念的冲突

项目管理原则与 Scrum 存在基本理念的冲突，而不仅仅是流程、角色和语义上的区别。PMI 所宣扬的某些原则和观点与某些让 Scrum 变得高效的原则明显相悖，它们本就分属两个不同的世界，强行糅合在一起只会导致 Scrum 在组织中实施失败。

PMI项目管理阶段

PMI 项目管理中有 5 个阶段。我们先拿前 2 个阶段，举例说明存在哪些冲突吧。

1. 概念与启动阶段

在 PMI 项目管理中，第一步是创建项目章程。通常，项目的执行发起人会签署（纸质或电子）文档。这是可执行的合同，在项目的第一天就锁定了项目目标。

冲突：它违反了敏捷选四大价值中的两个。

1. 在合同谈判的基础上进行客户协作。

在签署项目章程之后，项目干系人和项目执行团队之间就已经形成了隔阂，他们不是一个团队，彼此在目标上有冲突。

2. 在遵循计划的基础上响应改变。

要知道，很多项目会持续几个月，甚至数年。想象一下，在这么长的时间内，项目目标不发生改变，是几乎不可能的。尤其在软件开发领域，对竞争对手的行为及时作出响应，或某些新技术的使用，在时间要求上也是刻不容缓的。

2. 定义与计划阶段

或者，正如我说的“怎样创建一个从开始就注定失败的项目”。要知道，在“软件开发”领域，开发指的是创建新事物，本质上是探索性的行为。

冲突：“预先要求完整的项目定义“与“持续不断地交付有价值的软件”相悖。它无视对变化快速响应的价值，很有可能无法实现“共同维持其步调稳定延续”。团队进度不可避免地落后原计划，不得不在项目的最后一个月没日没夜地“赶工”。

让开发团队估算他们从未开发过的项目显然是没有意义的。可能某项工作才刚开始，甚至只写了一两行代码，此时就希望他们理解项目中的每个细节并精准地估算工作量，这显然是不现实的。而迭代开发的好处在于逐步完善，倘若带着脚镣跳舞，Scrum 的优点根本就无法展现出来。

除了前 2 个阶段，其实第 3、4、5个阶段都有冲突的地方。截至目前为止，相信你已经理解了，我也没必要再一一列举。传统的项目管理方法从第一步开始就与 Scrum 框架的理念相悖，又怎能在传统项目开发的基础上运行 Scrum，并期望它成功呢？

PMO 对应敏捷组织中什么角色？

对于这个问题，我希望有个完美的答案，很遗憾，没有。我曾想，是SMO（Scrum 管理组织）吧。我不大喜欢这个名称（它也称为服务管理组织，Service Management Organization），我倾向于在公司内部成立一个单独的组织，通过这个组织传播敏捷宣言中提到的Scrum的价值和原则，为大家提供合适的培训，帮助大家逐步提升和完善Scrum实践。

理想情况下，PMI 和 Scrum 权威组织可以坐在一起，共同探讨二者如何取长补短，避免冲突，我认为还是有很大改善空间的。

无论如何，当前的 PMI-ACP认证和“敏捷项目经理”把 Scrum 团队推向了一条可怕的道路。现在，我们所能做的就是不断地向公司领导人宣讲，让他们理解 PMBOK、Scrum 实践和敏捷宣言的关键差异。如果看到某个公司在招聘“敏捷项目经理”职位，或者某位候选人应聘“敏捷项目经理”职位，我们得当心了。

---

相关文章