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

Scrum 是时下流行的软件开发方式,连 PMI 也推出了 Scrum 相关的认证科目:PMI-ACP。
大多数观点认为 PMI-ACP 有助于 Scrum 的推广,帮助更多项目走向成功;也有人认为 PMI 在误人子弟,它让 Scrum 项目走向歧途。
本文作者 Stacey Christiansen 的观点倾向于后者。

英文原文:PMI: Please Get Out of Scrum

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

项目管理协会致力于项目(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 的准入门槛。

PMPPMI-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 实践和敏捷宣言的关键差异。如果看到某个公司在招聘“敏捷项目经理”职位,或者某位候选人应聘“敏捷项目经理”职位,我们得当心了。

添加评论

您的电子邮箱地址不会被公开。 必填项已用*标注

Protected with IP Blacklist CloudIP Blacklist Cloud