什么是CSM课程

CSM的课程及证书已经赋予你16个SEU的学分，可以用于后续申请CSP认证。鼓励大家通过申请成为CSP来继续提升你的Scrum经验及技能。

对于PMP，你可以参考下面的指引去申请获得PMI的16个PDU学分。我们本人都没有PMI网站访问的权限， 下面信息不一定最更新，但我相信可以作为参考开始你的学分申请。（听说PMI在12月全面更新了PDU申请的方法，若你能跑通新的流程，请分享细节给我参 考。应该有一个课程内容PDU比例的分配，我建议：Technical 12 / Leadership 2 / Strategy 2）

1. 登入成功后，在首页导航栏选择myPMI
2. 进入myPMI页面后，在页面右侧，会有一块蓝色区域“Report PDUs”
3. 进入“Report PDUs”页面后，选择“Course or Training"
4. 在“Course or Training"完成对应信息，例如provider、activity、description等相关信息（相关信息请看下面培训师信息，若有不全的，请告知我，我要持续完善）
5. 在“PDU Claimed"的三大领域分布16PDU，可以按照12、2、2分布（我的建议）
6. 勾选I agree this claim is accurate，点击Submit即可 完成以上操作，可在Dashboard和Claim History查看~

关于培训Provider的具体信息，在你填写PDU申请时，你可以使用如下信息：

• Provider: Bob Jiang, CST （请留意，你并不需要在PMI供应商列表里匹配到我们的这个信息）
• Activity: Certified Scrum Master (CSM)
• Summary: A 2 fully days training covering fundamental Agile project management and Agile delivery mindsets, principles, process, ceremonies, roles, artifacts and related techniques based on Scrum framework.
• Address: 24-4-301, No.9 Guanzhuang Road, Chaoyang Dist, Beijing, China
• City: Beijing
• State: Bejing
• Country: China
• Zip: 100024
• Phone Number: +86-13910939018
• URL: https://www.bobjiang.com
• Email address: bob@centerforagiletransformation.com

宝宝说敏捷简书专栏开通，欢迎大家关注。 宝宝说已注册域名，现招募一名网站设计的小伙伴，一起搭建宝宝说网站。 对于宝宝说敏捷如果您有任何想法或建议，欢迎我和联系。

内容大纲

• 新闻
• 社区
• 荐书
• 课程

新闻

---

3月我陆续写了9篇文章，具体可以参考我的简书专栏。 主题包含敏捷与成长，如Agile的起源、Scrum和看板的区别、如何快速学习新知识、理想与现实等

社区

---

Agile1001四月份活动预告 - 4月16日 DevOps实战

荐书

---

《在Toyota学到的只要纸1张的整理技术》- 本书的核心内容是思路整理，工具是用的一张纸。简短易用的一本书。具体可以参考链接。

课程 - Certified Scrum Master (CSM) 敏捷认证课程

---

2017年4月16日17日 上海 https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436 2017年5月25日26日 北京 https://yihuode.io/activities/419

关于我

---

姜信宝 （Bob Jiang） 中国北方第一位CST（Certified Scrum Trainer） 资深敏捷教练、创新教练 旨在帮助企业改进工作方法以取得更好的商业价值 Certified LeSS Practitioner，《Scrum精髓》的译者 Agile1001 (敏捷一千零一夜)联合创始人 我的博客 https://www.bobjiang.com

邮件： bob@bobjiang.com 微信： bob_jiang_xinbao 电话： 13910939018

自敏捷宣言以来，随着敏捷软件开发方法的普及，很多企业踏上了敏捷转型的道路。这里宝宝将跟大家一起说一下敏捷当前最流行的两个框架（Scrum和看板方法）——从它们的起源来分析各自的本质。

Scrum

Scrum的起源

Scrum一词来源于英式橄榄球（rugby）中重新开始比赛的争球的术语（是体育术语，不是缩写简写）。详情参考Wikipedia。

Scrum之父Ken Schwaber和Jeff Sutherland为什么选择这个词呢？这是因为他们受到一篇1986年哈佛商业评论上的论文影响——《The New New Product Development Game》。论文中开篇提到了：

许多公司意识到仅仅依靠高质量和低成本，已经无法从今天的市场中脱颖而出，它们还需要速度和灵活性。……而传统的顺序式或“接力赛”方法（比如按阶段的产品规划）可能和追求速度和灵活性的目标相冲突。相反，一种全局的或“英式橄榄球（rugby）”（团队通过前后配合传球的方式，作为一个整体单元推进）可能更好的适应了这种目标。 另外，在Scrum指南中也非常强调团队（开发团队），它们具备如下特点：

• 自组织的，没有人来命令（或告诉）团队如何把产品列表变成潜在可交付的产品增量。
• 跨职能的，团队作为一个整体，拥有开发产品增量所需的全部技能。
• 全职的，团队成员100%在团队内工作。
• 规模较小的，一般5-9人 虽然Scrum指南中还定义了Scrum框架的其他内容，但通过Scrum的起源（那篇论文）和指南中对于团队的描述，我们不难看出Scrum的本质是以团队为核心。

Scrum的本质

Scrum本质是以团队与产品（产品列表Product Backlog，这里就不展开介绍产品列表了）为核心。注意这里指的团队，和我们平时说的团队之间的差异。Scrum中的团队是自组织的、跨职能的特性团队。这样的团队的好处是：

• 特性（客户需求）在一个团队内完成，去除了移交、等待之类的浪费
• 团队的业务知识快速增长
• 团队稳定，从而有助于团队隐性知识的积累

“搭班子、定战略、带队伍” ——柳传志 柳总的管理心法是在做事之前要先有一批志同道合的人，有班子，然后再考虑定战略。这个管理思路和Scrum是一脉的。Scrum的本质也是先打造自组织跨职能的特性团队，然后再遵守Scrum指南的其他规则。

看板方法

看板方法的起源

看板方法的重要来源是Donald G. Reinersten的《The principles of product development flow》。这本书强烈推荐大家读一下。该书中共介绍了175个产品开发的原则，其中不乏一些反常识性的原则，另外还介绍了一些具有实践性的方法：

• 改善决策的经济性
• 管理队列（对比一下肯德基和麦当劳的取餐模式，很有趣）
• 减小批量大小
• 应用WIP限制
• 去中心化

看板方法的本质

由上述Don的书中核心理论可以看出，（产品开发流动的原则）他强调的是流动以及价值流动，这个是看板方法的本质。看板方法通过一系列原则促进实现价值的快速流动，比如：

• 可视化
• 限制WIP
• 减小批量
• 管理度量队列
• 等等

Scrum和看板方法的对比

上面分析完Scrum的起源、本质和看板方法的起源、本质后，我们不难看出这是两个完全不同的解决问题的方法。

• Scrum侧重于团队和产品，先有自组织跨职能的特性团队，然后围绕着产品列表进行交付。

• 看板方法侧重于工作事项，先让价值流动起来。 那么这两种方法孰优孰劣，这个很难衡量。以下仅代表个人观点： Scrum的特点：

• 打造真正的团队

• 多数情况下组织结构需要变动（跨职能团队）

• Scrum转型的切入点是组建团队和梳理产品列表 看板方法的特点：

• 价值快速流动

• 多数情况下组织结构不需变动（保留当前的现状）

• 看板方法转型的切入点是梳理工作的价值流

适合场景

Scrum更加适合产品开发，比如一个全新产品或原有系统的增强等。围绕着先组建特性团队、梳理产品，然后每个Sprint产出产品增量。

看板方法更加适合运营型（或运维性）项目。该项目特点是很难提前做出预测。比如我们无法预知明天会出现几个线上故障。

课后思考题

基于以上的Scrum和看板方法本质和特点，你会怎么选择呢？是否可以结合Scrum和看板方法呢？ 欢迎回复留言进行探讨。

2017年4月1日，是第九届一块的年会，我非常幸运地参加了这次“傻气与勇气”并存的年会。本次年会的主题是“用AI与未知共舞”。其中的AI是爱的谐音，也是Appreciation Inquiry的缩写。即用欣赏式探询与未知共舞。

两天的（4月1日4月2日）时间里，80多名来自全国各地的小伙伴齐聚西安，共同探索未知。在活动的第二天，收集了大家很多有关AI的疑问。其中一个问题的研讨给我非常大的触动。这个问题就是“如何锻炼欣赏的肌肉力？”

带领大家探索未知的是几位一块的伙伴（一折、Julia Zhu、任伟、嘉佑）。一开始一折跟大家分享了几个金句：

The truth is local. 真相都是在地的。

意思是真相是每个人自己的视角观察到的。所有人的真相是并存的（也可能是冲突的）。

Your word creates your world. 语言创造了世界。

先不解释了，有兴趣的小伙伴可以当面交流理解这句话。（书面可能表达不是那么清楚）。

在这个过程中，大家对于真相，视角，以及身体里的恐龙（恐惧）展开了激烈的讨论。在争论快要失去平衡的时候，Julia开始带领大家探索未知。

一开始，Julia先问了大家3个问题：

1. 现在每个人你自己是不是ok的？
2. 你认为场上几个引导师（一块的伙伴）是不是ok的？
3. 当下的气氛和环境是不是ok的？

接着Julia介绍了一个okness模型，如下图

Okness模型

模型的三个角分别对应刚才Julia提问的三个问题，即我、他、环境。

首先是我自己当前是不是ok的？即我是否接纳当下的自己？当下如果我不舒服是因为什么，是否有察觉，是否接受？不能接纳自己的情况下，是无法做到欣赏的。

其次是他人当前是不是ok的？我是否可以接纳他人的状态？是否察觉到自己的情绪随着他人在变化，是否可以接纳这种情绪的变化。不能接纳的话，也很难做到欣赏。

最后是当下的环境是不是ok的？对于当下的环境我的觉察是什么，是否可以接纳这个场景，我的情绪是什么。如果无法接纳的话，欣赏也不是那么容易做到。

通过这三个层面我们发现，其实对于如何做到欣赏，有三个重要的步骤：

1. 觉察
2. 接纳
3. 欣赏

上述3个步骤是层层递进。 最重要的是从觉察开始。我有没有觉察到……不论是自己的状态、情绪，他人的语言、情绪，当下的环境和场景等等，我是不是有这个觉察的能力。

那么如何锻炼自己的觉察能力？在座的小伙伴有不错的方法：

• 练习每日感恩日记
• 每日冥想

接纳。一旦我们觉察的能力提升，往往容易陷入苦恼的情绪中。因为好像突然之间发现了好多不如意的地方。那么这时候就需要开始接纳。接纳我是一个人，一个普通的人，不论什么情绪都是可以接纳的。甚至痛苦都是一个非常棒的礼物。（来自Hide Enomoto）

欣赏。觉察和接纳后，才有可能做到欣赏。当时大家在讨论的时候，有个伙伴分享她每天也会写感恩日记，可是觉得总找不到可以感恩的内容，练习1个月之后就无奈的停止了。我的个人感觉是她还是没有接纳自己，也可能是觉察还不够。而这个时候感恩日记会倾向于流于表面。

最后总结一下：想要做到欣赏，是一个循序渐进的过程。首先是觉察，其次是接纳，最后才是欣赏。而这里面关键的练习方法（或者工具）是每日练习感恩日记，或每日冥想（或者其他可以独立思考的方法）。

让我们一起来锻炼欣赏的能力吧！

一听到学习，很多人就想起来在学校里听老师讲课的场景。这样的学习真的是一个好方法么？还有没有其他更好的学习方法呢？

今天我就要跟大家介绍一个快速学习知识的方法：费曼学习法

费曼学习法的原理

“I learned very early the difference between knowing the name of something and knowing something.” - Richard Feynman “我很早就学会了知道名字和知道某事之间的区别”——理查德 费曼

学习不是要记住某事，而是需要理解并能将其融入到自己的知识体系中。

怎么样

费曼学习法有五步：

1. 选择一个新知识
2. 将这个知识讲给其他人听
3. 查明这之间的知识差距（比如哪些地方讲不好，讲不清楚）
4. 使用类比（最好是生活中的例子，尤其是专业知识，可以假设对方没有该领域的背景）
5. 简化你的讲解（用更精炼的句子）

举例

本文就是一个最好的例子。为了记住费曼学习法则，我自己查找相关资料，并认真记录下来。（记录也是一个讲给其他人听的例子，不过这个是写给其他人看）

回应上面的五步：

1. 选择一个知识（费曼学习法）
2. 用博客记录下这个知识（强化学习）
3. 一边写，一边找出自己哪里还没有搞清楚
4. 费曼学习法，就像中国的古语“授人以鱼不如授人以渔”。要学会方法。
5. 费曼学习法，是一个学习的方法。可以用来学习任何新知识。

总结

本文除了介绍费曼学习法，还有另外一个很重要的介绍新知识的三板斧，即Why, What, How。

• Why - 为什么介绍这个知识，它的原理是什么，有什么作用。
• What - 这个知识是什么
• How - 如何应用

多数介绍的时候，是按照What How Why的顺序，也有可能打乱这个顺序，比如先介绍Why， 然后What How。

今天的关键字：费曼学习法；学习知识三板斧；

开始今天的话题之前，先讲一点题外话。用面向对象的方法和大家介绍一下类的设计。

面向对象类图设计

类图设计

声明：由于手头没有合适的工具，所画的类图并不标准，但表达的意思都在图里了。

简单介绍一下这个类图：如上图所示，一共有两个接口，分别为Animal（动物）和Plant（植物）；动物这个接口有3个实现类，分别为Dog，Cat和Tiger，而植物这个接口有2个实现类，分别为Tree和Grass。这里省略了接口和类的内部定义。

假设现在有一个问题是，我们觉得有点热，想要凉快一点。针对这个问题，Dog类可能不会有什么好办法（假设狗真的无法解决这个问题）。不过有人发现Tree可以很好的解决这个问题。

那么我们能否把Tree（树）叫做动物呢？

显然不可以！动物就是动物，植物就是植物。 狗也可能有办法让我们凉快一点，不过确实不如树提供树荫这个方案更好。但这无法改变狗是动物而树是植物，这两个概念！

隐喻

第一节提到的类图，其实是一个比喻。现在我们换一下类图中的几个概念。比如

• 敏捷替换动物
• Scrum替换狗
• 心理学替换植物
• 催眠替换树

现在假设某个组织内采用Scrum效果甚微（暂且不讨论是如何采用的），而恰巧催眠这种方法较好的激活了个人意愿，从而改变了组织。那么这种情况下，催眠能不能叫做Scrum？或者催眠能不能叫做敏捷？

显然不可以！Scrum就是Scrum，催眠就是催眠！敏捷就是敏捷，心理学就是心理学！这是两个不同的概念。

我们反驳的是什么

上面两节里面讨论的概念，来源于最近敏捷社区里面的热议，从而也给我写这篇文章的灵感。

社区里面热议的焦点，主要集中于敏捷教练不同意“催眠是敏捷”。

那么大家反驳的到底是什么呢？ 是敏捷社区不接纳新事物、新想法么？以我这几年在社区的经验，答案是否定的。

大家真正反驳的是什么？ 如果我们仔细回看一下就会发现，这里面有一个非常明显的概念混淆，即催眠是敏捷。这是大家不能接受的。

敬畏知识

最后引用一位朋友的话，作为最后一节内容：

敬畏知识。

为什么要敬畏知识

知识是不断创造并积累的。我们需要敬畏知识有两大原因：

• 尊重概念的提出者（知识的源头）
• 不会误导他人（传播知识）

很显然，所有的概念都不是完美的，都会有相应的适用场景和改进的空间。那么如果概念有缺陷我该怎么办？我的做法是会找到概念提出者（或者最接近的人）进行讨论，交换彼此的想法。

如果我擅自在原概念上加入其它体系的知识并传播，就是在误导他人。这是作为知识工作者不应该有的态度。

如何敬畏知识

想要做到敬畏知识，有两个小窍门：

• 引用原概念，然后发表自己的观点
• 创建新概念，在原概念启发后可以有自己的知识体系

比如敏捷已经有敏捷宣言，那么我不会去修改敏捷宣言。而有可能创建新的宝宝说。

对于今天的分享，您有不同观点？欢迎回复留言讨论。

题目的由来

这个题目是怎么来的呢？我在3月24日25日参加Bill的CSPO课程，一开始有一个大家讨论的问题是，“你认为产品成功的条件有哪些？（或项目）”

大家讨论的结果并不重要，重要的是在这个过程中大家开始讨论产品与项目的联系和区别。

以前我的理解是产品是长期存在的，而项目是（一个或多个）产品的一部分，即阶段性成果。

课程当中还有一段乔布斯早年的访谈视频片段（遗失的访谈）。其中讲的是乔布斯解释想法与产品实现之间的鸿沟，以及团队是如何一起协作的。

这段视频中给我一个启发，那就是“产品是理想的而项目是现实的”。即我们今天要讨论的标题“理想与现实”。

现状

德国人有一句名言是

生活是具体的。

这反应出在我们的生活中，多数事情是具体存在，即现实的。

而什么是理想呢？ 记得小学的时候老师总是会问，“你长大后的理想是什么？” 还记得很清楚，我的理想是当一名老师。虽然现在已经距离理想很遥远，但理想就是一个目标在前方指引着我。

因此

• 理想是遥远而触不可及的、长期目标；
• 现实是具体存在的、短期利益；

而我们的生活就是在理想和现实之间不断的进行取舍。最终就如图1所示，停留在理想和现实之间的某个地方。

图1 生活工作的现状

理想

既然我们认为理想是遥远而触不可及的、长期目标，那么如果我们一直盯着理想而完全忽视现实的话。如图2所示：

图2 只看理想而忽视现实

会有什么问题呢？ 常见的完美主义者，就属于这个状态。完美主义者并不是不好，而是陷入其中的话，会忽略现实，而错过了市场机会。

现实

现实是具体存在的、短期利益。如图3所示：

图3 注重现实而忽视理想

常见的现实主义者，属于这个状态。现实主义者的问题往往是忽视了我们应该打造完美的产品。

理想与现实

回到主题，我们来看一下在软件开发当中，理想与现实是如何结合的。

传统的瀑布式软件开发

在传统瀑布式软件开发中，认为软件开发就像在流水线生产一样（属于简单工作）。把软件开发当做理想来实现，所以到最后结果往往并不能让客户满意。（理想是丰满的，而现实是骨感的）

Scrum软件开发

在Scrum敏捷软件开发框架中，非常好的平衡了理想与现实。产品（以及产品待办列表）代表了软件开发中的理想，这是团队的美好目标。而每个Sprint结束后潜在可交付的产品增量代表了现实，这是团队的现实情况。

就如图1所示，Scrum是完美地结合了理想与现实。既有理想的产品目标，又有现实的产出。

Scrum转型

Scrum框架本身也是完美的框架。在组织转型的过程中，作为敏捷教练要坚持Scrum框架（以及敏捷的价值观），不能妥协。作为现实的工作，在某些地方或多或少会有一些妥协，但是请谨记，此时的妥协只是临时方案。

最后，送给大家一句话。

Done is better than perfect.

让我们动手尝试一下吧。

Scrum 的定义

Scrum: Scrum 是一个框架,在这个框架中人们可以解决复杂的适应性问题,同时也能高效并有创造性地交付尽可能高价值的产品。 Scrum 是:

• 轻量级的
• 容易理解的
• 难以精通的

自上世纪 90 年代初期以来,Scrum 就已经应用于管理复杂产品的开发。Scrum 不是开发产品的一种流程或一项技术,而是一个框架,在这个框架里可以应用各种流程和技术。 Scrum能使产品管理和开发实践的相对功效(relative efficacy)显现出来,以便进行改进。

Scrum 框架由 Scrum 团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的,对Scrum的成功实施和运用都至关重要。

Scrum 的规则把事件、角色和工件组织在一起,管理着它们之间的关系和交互。Scrum 的规则会贯穿这份文档。

上面是摘自《Scrum指南》中文版的介绍，即Scrum的官方定义。这里面几个点需要格外强调：

Scrum是一个框架

Scrum是一个框架，而不是一个流程，也不是一个方法，更不是一项技术。这里面有什么不同呢？框架指的是这些内容组成一个整体，不可裁剪或修改。一旦裁剪或修改，框架就不稳固，容易出问题。

我们可以看看采用Scrum的组织中，出问题的大多数情况是在我们这里需要裁剪一下Scrum而造成的。比如每日站会太浪费时间，能否一周开两次。团队看起来没什么需要改进的，回顾会是否可以取消？等等

如果把Scrum裁剪了，请不要说在采用Scrum。

解决复杂的适应性问题

Scrum最适合解决复杂问题，比如软件开发这类复杂问题。另外还有适应性问题，即强调灵活性，需要团队可以快速响应变化。这是敏捷的本质，可以参考之前的博文“为什么敏捷是Agile，而不是Cgile或其他词”。

更多的解读，大家可以参加CSM敏捷认证培训了解详情。

参考材料：Scrum指南

很多人都知道敏捷，即Agile，也知道这个词是来自2001年的敏捷宣言。但你们知道为什么是Agile，而不是Cgile或其他的词吗？

我们来看看Craig Larman是怎么说的。（敏捷宣言是17个轻量型软件业的先锋于2001年共同签署完成的。Craig Larman当年也被邀请参加，但由于种种原因未能出席）

你看到“敏捷”这个词，或者你的组织进行敏捷转型，你首先想到的是什么？ 你想到的是提高效率、生产率、降低成本和提高质量、提高可预测性、或完成项目计划吗？ 如果你想到的是上述内容，对不起，你想的不是敏捷。（那一定是假敏捷） 敏捷（Agile）这个词最初的含义就一个，是 Flexibility 灵活性

更多有关敏捷不是快的信息，可以参考我的博文“敏捷不是快”

当年大家是怎么选择敏捷（Agile）这个词呢？据称当时有两个提议：

1. Adaptive 来自Jim Highsmith的提议，和
2. Agile 来自Mike Beedle的提议

为什么Agile会胜出呢？这里我们可以八卦一下。（原因是Adaptive Software Development已经由Jim H采用，如果大家都同意Adaptive，那么Jim就会抢占市场先机。所以……）

Agile一词虽然由Mike提出，但他自己在这之前并没有采用并推广。据Mike自己说他是从一篇1992年的（名为“21世纪制造业企业策略”）文章中受到启发的。

I was at IBM when the formation of the Agile Consortium occurred – IBM was part of that consortium, so I had a copy of the 21st Century Manufacturing Enterprise Strategy, which was published in 1992, and already used the word “agile” to describe development and manufacturing. – From Mike Beedle

《在TOYOTA学到的只要纸1张的整理技术》 作者：浅田卓

本书的核心

一句话，用一张纸整理思路。

适合场景

• 工作清单
• 会议（培训）记录
• 市场分析
• 新商品策划

一张纸文件的共通点

• 目的
• 现状
• 课题
• 对策
• 日程

如何用一张纸进行整理

1. 第一步，将思考用的基础信息整理到文件内
2. 第二步，将自己独有的思绪、归纳到文件内
3. 第三步，文件的内容要传达、沟通的对象

讲概念的三板斧

• Why，这个概念的目的是什么，有什么好处
• What，这个概念是什么，听众想听什么
• How，这个概念如何用到我的工作或生活中

举例子

如何用一张纸进行自我介绍

1. 在一张A4纸上画出8个（或者16个）格子
2. 在左上角的格子内写上自己的名字
3. 30秒内迅速填满剩余格子（填写内容为你想到自己特点的关键词，即你想要介绍的方面。只写关键词即可）
4. 格子之间找关联，相同类型的标识一下
5. 排序，介绍的时候先说哪个部分，再说哪个内容

下图是工作坊中大家介绍的例子，大家自我介绍完后都觉得这样进行介绍太轻松了。

用一张纸进行自我介绍的示例图

为什么一张纸这么有效

最后这里我自己总结了一下为什么一张纸这种方式有效。因为这种方式它有效地帮助我们进行了思考的分类。 比如上述的例子主要分为三大步骤：

• 收集整理数据。这个步骤做的事情是发散，头脑风暴。目的是记录脑子里出现的所有和目的或主题相关的词。
• 思考、归纳、找出联系。这步做的是思考。在上一步的基础上，审视已有的关键词，找出它们的联系，进行深度思考。
• 做出决策。最后基于上面的思考，进行最后的决策。

有关于决策，也叫作选择，是一个很大的话题。下一次我想专门来聊一下选择这个事情。

下一个话题你期待吗？