引言 敏捷火热，随之出现很多敏捷热词，比如敏捷组织、敏捷营销、敏捷管理、敏捷blah blah。在这么多敏捷词汇背后，映射出敏捷已经受到越来越多的行业与人群的关注。然而就在我们日常工作的组织中，有很多与敏捷相悖的陷阱（或常识）。这里和大家分享如下几个： 跨地域团队 狂热的敏捷 外包客户服务 大规模敏捷的困扰 SAFe or safe 跨地域团队 软件开发工作，没什么比得上大家坐在一起更高效了。 “通讯基本靠吼，交通基本靠走”，虽然这只是一句顺口溜，然而放在软件开发工作中是非常贴切的。 我想要寻求某个问题的答案时，只要站起来走到同事身边，吼一下就可以了。 现代移动互联网时代，越来越多的工具尝试代替人与人之间的沟通，比如Skype, Slack, Trello, Teambition, Leangoo,等等。发个消息过去之后，就如石沉大海没有了回应。这是一种什么心情呀。 因此，对于软件开发工作不要跨地域团队。（注：这里的地域可以大到国家，小到楼层） 狂热的敏捷 组织敏捷转型催生了对于敏捷培训师、引导者以及咨询师的大量需求。很自然地出现了求大于供。这种情况下就会出现一些浑水摸鱼的人，来满足企业和组织的需求。如果雇佣了一名知识与经验不足的敏捷咨询师，组织很快就会对于敏捷失望透顶，失去兴趣。那么以后再想重整旗鼓就很难了。 因此选择靠谱的敏捷培训师、咨询师是很重要的第一步。 外包客户服务 如果你和客户之间没有直接的链接，那么你将失去创新的机会。你也就不会得知客户真正想要什么。很不幸的是，很多组织在缩减成本，往往会把与客户直接对话的客服部门进行外包。 停止外包你的客户服务工作吧！ 大规模敏捷的困扰 我不相信有一个完美的框架，可以帮助组织很好的实现大规模敏捷。以前没有，以后也不会有。盲目地相信有这种解决方案的人，是懒惰的，是想逃避责任的。 在选择或实施大规模敏捷之前，需要问以下问题： 为什么要采用大规模敏捷 想要解决的组织问题是什么 SAFe还是safe SAFe是一种以价值流为核心的大规模敏捷方法。组织因此可能变得更高效或以客户为中心。但很多企业选择SAFe的时候并不理解敏捷宣言，不理解敏捷的价值观。寄希望于一套完整的框架方法可以帮助组织进行整体一次性的转型。SAFe方法提供了一套完美的完整的框架（包含原则、方法、实践），给高层领导者一种很安全（safe）的感觉。然后组织根据自己的情况进行裁剪与适应。 在转型的初期，这是奏效的。然而随着时间的推移，转型的深入，这种方法很可能无法完全适应组织的需求。因为SAFe并不提及组织结构的改变。 而企业或组织的核心是盈利，是需要完成产品开发。另外一种大规模敏捷方法LeSS，是以产品为核心，特性团队（组织结构的变化）为基础，以系统思考、精益思想等为原则的框架。 想要大规模敏捷，除了问下上述的两个问题，更多要全局思考。 有关LeSS更新信息请参考

什么是CSM课程 CSM的课程及证书已经赋予你16个SEU的学分，可以用于后续申请CSP认证。鼓励大家通过申请成为CSP来继续提升你的Scrum经验及技能。 对于PMP，你可以参考下面的指引去申请获得PMI的16个PDU学分。我们本人都没有PMI网站访问的权限， 下面信息不一定最更新，但我相信可以作为参考开始你的学分申请。（听说PMI在12月全面更新了PDU申请的方法，若你能跑通新的流程，请分享细节给我参 考。应该有一个课程内容PDU比例的分配，我建议：Technical 12 / Leadership 2 / Strategy 2） 登入成功后，在首页导航栏选择myPMI 进入myPMI页面后，在页面右侧，会有一块蓝色区域“Report PDUs” 进入“Report PDUs”页面后，选择“Course or Training” 在“Course or Training”完成对应信息，例如provider、activity、description等相关信息（相关信息请看下面培训师信息，若有不全的，请告知我，我要持续完善） 在“PDU Claimed”的三大领域分布16PDU，可以按照12、2、2分布（我的建议） 勾选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.

宝宝说敏捷简书专栏开通，欢迎大家关注。 宝宝说已注册域名，现招募一名网站设计的小伙伴，一起搭建宝宝说网站。 对于宝宝说敏捷如果您有任何想法或建议，欢迎我和联系。 内容大纲 新闻 社区 荐书 课程 新闻 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的特点： 打造真正的团队

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个问题： 现在每个人你自己是不是ok的？ 你认为场上几个引导师（一块的伙伴）是不是ok的？ 当下的气氛和环境是不是ok的？ 接着Julia介绍了一个okness模型，如下图 Okness模型 模型的三个角分别对应刚才Julia提问的三个问题，即我、他、环境。 首先是我自己当前是不是ok的？即我是否接纳当下的自己？当下如果我不舒服是因为什么，是否有察觉，是否接受？不能接纳自己的情况下，是无法做到欣赏的。 其次是他人当前是不是ok的？我是否可以接纳他人的状态？是否察觉到自己的情绪随着他人在变化，是否可以接纳这种情绪的变化。不能接纳的话，也很难做到欣赏。 最后是当下的环境是不是ok的？对于当下的环境我的觉察是什么，是否可以接纳这个场景，我的情绪是什么。如果无法接纳的话，欣赏也不是那么容易做到。 通过这三个层面我们发现，其实对于如何做到欣赏，有三个重要的步骤： 觉察 接纳 欣赏 上述3个步骤是层层递进。 最重要的是从觉察开始。我有没有觉察到……不论是自己的状态、情绪，他人的语言、情绪，当下的环境和场景等等，我是不是有这个觉察的能力。 那么如何锻炼自己的觉察能力？在座的小伙伴有不错的方法： 练习每日感恩日记 每日冥想 接纳。一旦我们觉察的能力提升，往往容易陷入苦恼的情绪中。因为好像突然之间发现了好多不如意的地方。那么这时候就需要开始接纳。接纳我是一个人，一个普通的人，不论什么情绪都是可以接纳的。甚至痛苦都是一个非常棒的礼物。（来自Hide Enomoto） 欣赏。觉察和接纳后，才有可能做到欣赏。当时大家在讨论的时候，有个伙伴分享她每天也会写感恩日记，可是觉得总找不到可以感恩的内容，练习1个月之后就无奈的停止了。我的个人感觉是她还是没有接纳自己，也可能是觉察还不够。而这个时候感恩日记会倾向于流于表面。 最后总结一下：想要做到欣赏，是一个循序渐进的过程。首先是觉察，其次是接纳，最后才是欣赏。而这里面关键的练习方法（或者工具）是每日练习感恩日记，或每日冥想（或者其他可以独立思考的方法）。 让我们一起来锻炼欣赏的能力吧！

一听到学习，很多人就想起来在学校里听老师讲课的场景。这样的学习真的是一个好方法么？还有没有其他更好的学习方法呢？ 今天我就要跟大家介绍一个快速学习知识的方法：费曼学习法 费曼学习法的原理 “I learned very early the difference between knowing the name of something and knowing something.” - Richard Feynman “我很早就学会了知道名字和知道某事之间的区别”——理查德 费曼 学习不是要记住某事，而是需要理解并能将其融入到自己的知识体系中。 怎么样 费曼学习法有五步： 选择一个新知识 将这个知识讲给其他人听 查明这之间的知识差距（比如哪些地方讲不好，讲不清楚） 使用类比（最好是生活中的例子，尤其是专业知识，可以假设对方没有该领域的背景） 简化你的讲解（用更精炼的句子） 举例 本文就是一个最好的例子。为了记住费曼学习法则，我自己查找相关资料，并认真记录下来。（记录也是一个讲给其他人听的例子，不过这个是写给其他人看） 回应上面的五步： 选择一个知识（费曼学习法） 用博客记录下这个知识（强化学习） 一边写，一边找出自己哪里还没有搞清楚 费曼学习法，就像中国的古语“授人以鱼不如授人以渔”。要学会方法。 费曼学习法，是一个学习的方法。可以用来学习任何新知识。 总结 本文除了介绍费曼学习法，还有另外一个很重要的介绍新知识的三板斧，即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. 让我们动手尝试一下吧。