远离敏捷状态的 Scrum 框架

本文来自作者 王宇 在 GitChat 上分享 「远离敏捷状态的 Scrum 框架」， 「 阅读原文 」 查看交流实录。

「 文末高能 」

编辑 | 哈比

尽信书不如无书 ——《孟子·尽心下》

敏捷入门，很多人一般都会选择 Scrum 框架进行学习和导入。但笔者在国内导入敏捷的时候，发现 Scrum 框架有很多缺陷，而且这些缺陷甚至让团队远离 “敏捷” 的状态（Being Agile）。

商业上的成功让这一框架家喻户晓，但认证也让这一框架拥有无数的原教旨主义者。有些时候当我想表达一些观点的时候，好像很多人的潜台词就是 Scrum 是不可撼动的，那好……今天咱们就掰一掰。

那什么是敏捷呢？

很多人会说敏捷就是一种心态（Mindset），老太太 Linda Rising 说有两种心态：

• 固定心态认为

• 能力：恒定的，如身高；

• 目标：有面子；

• 挑战：避免；

• 失败：影响身份；

• 努力：没有天赋的人；

• 对挑战的响应：无助的；

• 敏捷心态认为

• 能力：能成长，如肌肉；

• 目标：去学习；

• 挑战：拥抱；

• 失败：提供信息；

• 努力：成为高手的路径；

• 对挑战的响应：执着、韧劲。

她又说到：

• 敏捷心态相信所有的一切都是在过程之中；

• 敏捷软件开发过程不是固定的。当我们越了解软件开发过程就会越变化和成长。因为这个过程永远没有完美的一天，所以变化和成长会不停的延续下去；

如果说用一句话来形容什么是敏捷：

Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. ——Samuel Beckett, Irish poet(1906-1989)

观点： 敏捷是一种不停尝试、不停调整、不停优化的状态。（Being Agile）

参考：

敏捷软件开发宣言：描述了敏捷软件开发的价值观
The Power of an Agile Mindset - Linda Rising：敏捷心态的幻灯片
消失的仪式感：Doing 与 Being 的文章
Mindset：描述固定心态和增长性心态书籍的豆瓣链接。

但你会说，这太难了

是，这太难了。读到这里你肯定有一种被命运抛弃的感觉。你会说看上面的东西好像啥都没说啊，那我怎么做呢？是的，一般人都必须从 “守” 开始。

什么是 “守”？守就是告诉你什么你做什么。

那告诉什么呢？那就是：

• 需求如何一步一步变成软件；

• 有几个会议，如何开会；

• 有几个角色，到底干些啥；

但如果你止步于 “守” 的阶段，不好意思，你不要说你和敏捷有什么关系。尽管你可能 2 周产出一个能上线的软件，尽管需求可以实现增量型的交付，尽管设定了几个角色。

敏捷其实更强调 “破” 和 “离” 的状态，而不是 “守” 的状态。尽管 “守” 的过程是重要的。“守” 你可以理解就是 Doing，“破” 或 “离” 就是 Being。（Being 就是上一段所说的内容）

用两张图来表达这两种区别（绿色的是你做 “敏捷” 的事情）：

这两种时间分配比例达到 9 比 80，这也就是说 Doing 重要，因为如果不是 Doing 我们不知道如何走向 Being。

但真正的敏捷是融合在日常工作之中，而不是所谓的几个会议、角色、工件之中。

如何让大家用 Doing 来关注到 Being 的状态，是所谓 “框架” 应该关注的东西。也就是说，框架说让你躺下，闭着眼睛。自然就会达到休息的目的。

一般人可能对如何休息不知道该如何去做，但一个框架性的东西可以让人关注具体从而实现一个较为模糊的目标。

观点：

• 一个撇开实践的敏捷理论就是扯淡，必须让人们先做起来（Doing），然后通过练习慢慢提高到（Being）状态。

参考：

《让看板成为团队的镜子：看板演进》：如何通过不停的做事情而达到某种状态。

Scrum 框架与我对框架的期望

前几天我的这个文章的创意发出的时候，很多人在群里讨论。看到大家的讨论很有意思，我在这里非常明确的说出我的观点：

（1） Scrum 就是 3355 的组合

• 3 个角色（Product Owner 产品负责人、Development Team 开发团队、Scrum Master 斯格拉姆马斯塔）

• 3 个工件（Product Backlog - 产品待办列表、Sprint Backlog - Sprint 待办列表、产品增量）

• 5 个事件（Sprint、Sprint 计划会议、Daily Scrum 每日站会、Sprint 评审会议、Sprint 回顾会议）（注意哈，如果叫 Stand-up、Daily Stand-up、Daily Stand、Stand-up Meeting 这不是 Scrum 中的词汇哦）

• 5 个价值观（开放、尊重、勇气、专注、承诺）

（2）同时强调了 “完成” 的定义（DoD）

• 也就是什么叫 “完成” 的标准需要慢慢增加和扩大；

（3）在 3355 的背后是

• 透明、检视、适应（这也是 3355 的目标）

Scrum 就这么多东西。如果任何一个 Scrum 的培训，没讲到以上的内容。我建议你去向培训机构要求退钱。;)

在开拍 Scrum 之前，先说说我喜欢它的地方吧：

（1）对错（爱憎）分明

在导入敏捷过程的时候没有什么比告诉别人对或错更为有效；

（2）结构简单

简单可以在很多方面获得好处，比如教学方面、让别人更快理解方面，当然理论本身的硬伤也会因为简单而更难显现；

（3）花钱考证

你没看错，确实这是优点。良好的商业运作使得有持续的资金注入，让受众更广泛、也让讲师有意愿提高授课水平。

在开始描述我对一个框架的期望之前，我要强调一下 Scrum 的另一个可能大部分人会忽略的关键点：

在 《Scrum 指南》 中第 20 页的 “ 结束语 “ 部分：

看到了没有，不能改变。整体应用叫 Scrum，部分应用叫 ScrumBut。那太好了，我喜欢这个爱憎分明的家伙。我后面的文字，部分瞄准的也是它这句话。

我对一个 “敏捷” 框架的期望：

1. 简单（一个高中毕业的人就能够明白）且关注关键点；

2. 100% 能落地（能够实施）且能够灵活的应对现实中的不同情况（覆盖广）；

3. 关注实践（Doing）并通过实践自然达到敏捷的状态（Being）；

观点：

• Scrum 是一个爱憎（对错）分明，多一分不多少一分则少的过程实施框架；（它本身是硬的，不能调整）

• 人们通过具体的行为或做法来理解事物，一个好的 “框架” 会让大家从具体的事情着手并逐步走向更深层次的理解与实践（Doing -> Being）；

参考：

Scrum 指南：权威定义 Scrum 的文字；
Scrum 简章：一般我的培训课上都发这个资料；

关于纯真信仰的 “自组织”

• 我曾经问过我所带领的团队成员：“你觉得自由是一件好事吗？” 当时有些人点头有些人摇头。我非常明确的对他们说：自由不一定是个好东西，对于那些无法独立思考的人，自由对他们就是负担。
  刚才那句话我一般会说两遍，当说完的时候我也看到很多赞同的点头。

• 中国从来就是精英社会，而不是民粹体系。你可能真诚的说：来看看你想干点什么活？他估计会回答你：领导，您说干哪块咱们就干哪块吧。这种状态根深蒂固，并且估计 80% 的团队成员是这样的。自组织个毛啊（这句话真心看着不像专业教练说的）。

• 真正重要的是

  
  

• 让团队中少量的核心分子真正的积极起来，拥抱协作的敏捷文化；

• 给剩下大部分跟着跑的团队成员成长空间，让他们知道如何提出请求，如何反馈意见，了解成为核心成员的成长路线。

Scrum 指南 第七页

Scrum 指南 第八页

观点：

• 在中国自组织就是一个神话，现实之道是团结精英推行任何改进；

参考：

Scrum 与 Kanban，激进与保守：路宁对于 Scrum 和看板的评价

Scrum 框架的反敏捷之处

（1）关注角色而不是要达到的效果

• 伟大而又神奇的 Scrum Master（斯格拉姆·马斯塔）

• 好消息是：经过 2 天或 3 天的培训、考试之后，你会获得 Scrum 联盟发出的 Scrum Master 证书。恭喜你你被联盟认证了！

• 坏消息是：在我经历过的国内团队之中，我认为靠谱的斯格拉姆·马斯塔人数在 20 人以下。

• 也恰恰是因为不靠谱人员数量庞大，对团队造成了很坏的影响。这也使得我在国内导入的敏捷过程完全不引入这一概念。

• 斯格拉姆·马斯塔的终极目标是消灭自己（形成真正的自组织团队之后），但在 《Scrum 指南》 8-9 页之中没有任何文字描述。而这一角色又堂而皇之的成为框架永恒的一部分。

• 缥缈的 Product Owner（产品负责人）

• 拜李国彪（Bill Li）所赐 ;P，基本所有 Product Owner 都被翻译成产品负责人了。但这是负责人吗？这不是 产品业主 嘛？（关于这点他也经常开玩笑）

• 在中国的团队之中到底有多少能做得了主的 “产品负责人”，增加了无数新的 ScrumBut 词汇。比如：PPO(Proxy Product Owner), POA(Product Owner Assistant)；

• 不好意思，你这玩的不是 Scrum 是 ScrumBut。但纠结角色的时候是不是可以看看他 / 她管的事是否大家都可以分担了呢？

• 在导入敏捷过程的时候，恰恰有很多个角色或个人能够满足这些要求。那太过于强调这个角色是否又是一个合理的坚持呢？

（2）关注会议而非会议之前的准备

• Scrum 有对会议的精细安排，比如建议多长时间，比如结构分成几个部分。但恰恰是这种划分使得使用者的注意力关注到会议本身。会议的时间越来越长，效率越来越低。但只要有特定的会议并且关注 Scrum 所要求的方向就达标啊。

（3）冗余的概念

• Product Backlog 和 Sprint Backlog

• Scrum 框架告诉我们说 Product Backlog 是 PO 的资产，Sprint Backlog 是团队的资产。但本身作为需求的表现形式来说，就应该是平衡业务与技术。一方面如果推迟进行技术角度的拆分其实就是放大项目后期的风险；另一方面团队需要尽早考虑后面的交付目标。所以对于需求不应该区分这两个概念，应该用一个概念所代替。这里建议就用 User Story（用户故事）代替 Product Backlog 和 Sprint Backlog。

（4）框架的缺失

• 需求 DEEP 中的 D 就是扯淡

• 这里的 D 就是 Detailed Appropriately（细节合适的）：越临近开发越精细，离开发越远越粗略。多精细？多粗略？框架中这部分内容的缺失是遗憾的。初学者根本无法掌握精细和粗略的火候；

• 这点在我实施敏捷导入的是否非常关键，也就是如何能够实现 “渐进式需求分析”；

• 建议使用：SBDEEP（详细的解释请参见 《Product Backlog 的细节合适就是扯谈》 ）

（5）不精确的词汇

• Backlog：这个词是啥意思？就是要干的事，但咱们了解 Scrum 中 Product Backlog 概念的人知道。Backlog 放在下面的不一定要做啊，随着时间的推移，新的需求加入，优先级低的 Backlog 可能永远都不会做。

• 我个人也倾向不使用 Requirement 这个词，Item、Story 可能会更为合适。

• 这里给 Kanban 方法点个赞，在那个世界这种东西叫 Idea。就是个想法，想法做不做不一定。

• Scrum Master：啥叫 Master？大师？两天培训考试之后就大师了？所以我更倾向叫这些人斯格拉姆·马斯塔。这种不是基于能力的认证实在让我痛心，记得我之前朋友圈发过一条信息：认证认证了什么？认证的边界是什么？

• Sprint：冲刺？这词汇我每次培训都花了不少言语进行解释。这里不是说的猛，不是拼命，而是短。但越了解 Scrum 其实感觉，框架就是让团队成员抱起团来往前冲。很多实施敏捷的团队说敏捷就是加班，可能也有几分源于此吧（YY 一下）。

（6）框架补充的堆砌（非 Scrum 框架本身）

• 正因为 Scrum 只是一个框架，所以很多培训讲师为了使 Scrum 更为落地填充了很多内容。但一些内容确实有些过时了，有点时候感觉是知识的堆砌，甚至某些部分过于关注感受的冲击，比如：

• 1、2、3、5【8、20、40、60、100】括号中的数字卡片都可以扔掉了，估算能拆成这么大的东西，风险无法控制。

• 打扑克、伸手指头太慢了。悲催的是有些 Scrum 培训还在教这种方式，比较靠谱的解释是他们扑克印多了。建议使用 《批量用户故事快速估算方法》

• 过时：估算扑克

• 堆砌：在课程中一堆需求分析的方法，一堆创新思维的工具，一堆估算的方法，一堆模型。真正用到的又有几个？

总结一下

1. 关注角色而不是要达到的效果：反敏捷评级【四颗星】

2. 关注会议而非会议之前的准备：反敏捷评级【五颗星】

3. 冗余的概念：反敏捷评级【三颗星】

4. 框架的缺失：反敏捷评级【一颗星】

5. 不精确的词汇：反敏捷评级【一颗星】

6. 框架补充的堆砌（非 Scrum 框架本身）：反敏捷评级【一颗星】

回到我对一个敏捷框架的期望，并综合上面所表达的观点进行 Scrum 满足程度评估：

（1）简单（一个高中毕业的人就能够明白）且关注关键点；

• 足够简单，但有些关键点它错过了。比如 Detailed Appropriately 的 Product Backlog。

（2）100% 能落地（能够实施）且能够灵活的应对现实中的不同情况（覆盖广）；

• 虽然能在小型团队 100% 落地，但其僵化的框架本身无法在其他场景进行应用。所以在任何培训之前，建议明确把其限制进行非常明确的标注；

• 其本身的僵化无法应对现实中的许多情况，比如不靠谱的 Scrum Master，模糊的 PO；

（3）关注实践（Doing）并通过实践自然达到敏捷的状态（Being）；

• 远远没有达到我的期望。

观点：

• 对于一个框架你可以任性，但这也显示出了对细节的不负责任；

• Scrum 商业化的成功，使得学员不是在学习，而是在消费。这种消费与讲师形成的共生进化关系，产生了更多的包装。包装产生业界大牛，大牛导致更多人的膜拜。这恰恰说明为啥 CST 这么火，CEC 无人问津的现状（国内 8 个 CST，1 个 CEC，1 个 CTC）。

我所坚持的导入框架

好，干货时间到哈。基于 Scrum 的框架吧，说说我的调整：

• 2 个角色

• 20 人以下的交付单元，包括改进委员会所有成员；

• 职责：

• 完成迭代目标，完成债务任务；

• 实现工分增量需求，制造出可上线的产品增量；

• 3-9 人组成的领导力团队；

• 职责：

• 定义迭代目标；

• 识别债务任务；

• 改进团队：缩短 LeadTime（前置时间）、降低版本缺陷数、提高团队节奏指数、起床指数、纪律指数；

• 改进委员会

• 团队

• 2 个工件

  迭代理解地图：

• 迭代计划会议：每个人都没问题；

• 非框架会议：需求梳理会议（理解校准）

• 演示会议：证明你做完了；

• 这种任务不进行估算，但计算完成时间。包括：

• 5 个事件

• 迭代

• 迭代计划会议

• 进入迭代的仪式

• 要求：

• 每日站会

• 每天早上进入工作状态的仪式

• 要求：

• 演示会议

• 改进委员会成员引导的，确认工分的仪式；

• 要求：

• 改进委员会回顾会议

• 特征：改进委员会小组思考债务提高测量指标的会议

• 要求：

• 5 个测量

• LeadTime 前置时间：从需求提出到上线的时间；

• 版本缺陷数：每个上线版本所发现的缺陷；

• 节奏指数：主观指数

• 5 分：团队非常有节奏感，有条不紊

• 1 分：杂乱无序

• 起床指数：主观指数，我早起床之后，想到上班

• 5 分：就安奈不住心中激动的心情。

• 1 分：就让我死在床上吧

• 纪律指数：主观指数，团队的任务执行

• 5 分：如钢铁般的纪律，特种兵一般

• 1 分：毫无纪律可言，乌合之众，土匪一般

• 缺陷（Bug）功能债务

• 技术债务（Tech Debt）

• 团队债务（影响 LeadTime 前置时间、版本缺陷、节奏感、起床指数、纪律指数的任何任务）

• 同 Scrum 的迭代概念，增加一个要求：迭代内只能实现 “钻石” 级别的需求；