阅读《技术人创业攻略》一书中，作者对Dave Thomas的访谈有如下一段话： 真相是，“敏捷并不存在”。它不是一种东西，不是一个名词。人们是把它当做一个名词开始用起来的，但是他们并不理解背后的含义。 “敏捷”不是一种东西，敏捷是一个形容词——它描述了一种东西。你可能有一个敏捷的团队或者一种敏捷的过程，但你却从来不是“敏捷”。 对于Dave的这个定义我并不认同。 首先敏捷是一个名词。作为名词的敏捷，它不是一个状态，而是一个完美目标。 敏捷不是一个状态，不是一个状态，不是一个状态！有不少公司在敏捷转型的时候认为，只要我们做到xyz，我们就是敏捷了！对不起，你们并没有敏捷，你们只是达到了一个新的状态。 而敏捷是一个完美目标。何为完美目标？完美目标，是一个永远无法达到的目标。是的，敏捷就是一个永远无法达到的目标。 敏捷是一个持续学习的过程。持续学习也是没有终点的，是一路上不断地持续地学习。因此前几天微信群有朋友问，有没有敏捷成熟度模型？我内心想说的是，不要用模型限制束缚了持续学习。 其次敏捷是一个动词。作为动词，敏捷的含义让我们感觉是快。这里往往有误解，认为敏捷就是效率高、速度快！ 敏捷不是速度快！！！请参考我之前的博文《敏捷不是快》 另外我对敏捷的定义是“一个持续学习的过程”。在这个定义中，也没有任何一个字眼说敏捷就是速度快、效率高！ 最后广告时间 – CSM敏捷认证课程 2017年4月16日-17日 上海 2017年4月24日-25日 深圳 2017年5月25日-26日 北京

Keywords: “double loop learning”, “retrospective”, “Scrum” What inspires me to think about double loop learning Scrum is double loop learning (1977 HBR) 1. Before going to Boston, I read a wonderful article from HBR (https://hbr.org/1977/09/double-loop-learning-in-organizations), which illustrates learning in organizations, aka named double loop learning. To explain it in a short sentence, e.g during our discussion (Boston SA F2F sprint2), we came up an item from product backlog, which is about ensuring core Scrum accurate in SA web content.

在上一篇文章中，我提到以下几点： 绩效管理（度量）的主要目的 度量指标的分类 在这篇文章中，将会展开描述度量指标，详述在软件开发中都有哪些度量指标。 注意：这只是一个度量指标清单，不要照本宣科全部采用（会累死的）。一般建议对于一个组织（或者团队）选用7个以内的指标就足够了。 为了评估公司对产品交付的支持 客户净推荐值（NPV）——推荐产品的客户数/客户样本数 系统稳定性——比如通讯系统的99.99999% 预测进度 燃尽图（故事点或工作小时数） 团队速率（每个迭代交付的故事点数） 提高质量，减少技术债务 生产系统的缺陷数量——发生在客户一侧、生产系统上的缺陷数量（很重要的统计数据） 内部测试发现的缺陷数量（或者说迭代内缺陷） 单元测试的代码覆盖率 违规代码数量（Sonar等静态代码检查） 评估过程的有效性和改进 迭代是否完成目标 是否有回顾会议（反思改进） 需求的周期时间（cycle time） 价值流图 商业效率 产品的整体周期时间 达到收支平衡的时间点（tipping point） 获利的时间 投资回报率（ROI） 现金流（组织内的任何需求都可以折现成$$） 收入增长 评估用户（c端） 每日新用户数 每日留存用户数 每日付费用户转化率 每日净推荐值 企业文化指标 容忍失败，并从中学习 创新意愿 特性团队的比例 下一篇，我将列举一个现实中的团队绩效评估例子，并进行解读。 以下为广告。近期BoB的CSM敏捷认证课程安排如下： 2017年3月16日17日 成都 https://yihuode.io/activities/404 2017年3月23日24日 北京 https://yihuode.io/activities/419 2017年4月16日17日 上海https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436

最近的课程： 2017年3月23日24日 北京 https://yihuode.io/activities/419 2017年4月16日17日 上海https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436 价格：早鸟价：6300元（早鸟已满）；三人同行每人可享6000元；普通7000元 说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师（邮件或微信） 课程简介 从2001年提出敏捷宣言至今已有十余年，敏捷不仅仅在国外发展势头很强劲，在中国也有越来越多的企业开始敏捷转型。一开始是外企把敏捷带入中国，目前国有企业、民营企业、私营企业以及初创企业都在或多或少的应用敏捷实践。越来越多的企业和公司认识到敏捷转型的重要性。敏捷不仅仅是一些方法或实践，更是一种心态的变化，也是一个新的旅程。 在本次课程中，学员不仅从实际操作的层面上掌握Scrum的运用技巧，学员还将学会如何避免Scrum实施过程中的一些常见问题。Scrum很简单，但要掌握其精髓却并非容易，讲师结合自己在企业内实施敏捷转型的实践经验和Scrum框架，通过案例与游戏介绍解释什么是Scrum以及为什么Scrum可以如此高效。课程中通过多个游戏，和穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。 课程特色 来自于大型外资企业和互联网行业的一线敏捷实践 内容全面深入，重在实践操作与应用，囊括了大量项目经验 通过游戏化的方式，让学员在课后可以立即启动自己的Scrum 学习目标 帮助学员学习理解Scrum的原则、方法、与实践经验 提升学员对Scrum，以及敏捷最新实践的理解 通过游戏化的方式，学会如何在组织内进行Scrum转型 主要收益 Certified ScrumMaster证书 Scrum联盟两年会员资格 Scrum实战培训手册1本 对Scrum转型有帮助的、有启发性的1G+视频 团队敏捷备忘录1份 PMI上可以申请的16PDU 适合人群 作为一名Scrum初学者，我可以系统地学习Scrum，了解Scrum背后的原理以及相关知识，以便为组织的Scrum转型打下基础。 作为一名管理者，我可以了解Scrum框架的工作方式，还可以从Bob那里学习组织转型的经验，以便引导我的组织开展Scrum转型，收获更大的价值。 作为一名传统项目经理，我可以看到Scrum是如何工作并生效的，以便更好得把Scrum应用到项目中。 课程大纲 模块1：敏捷与Scrum概述 模块2：Scrum角色 模块3：Scrum工件之产品列表及条目 模块4：敏捷估算与规划 模块5：Scrum会议 模块1：敏捷与Scrum概述 敏捷软件开发逐步地深入人心，但在敏捷转型的企业中，只有很少一部分可以做到持续不断地交付商业价值，使客户满意。相当数量的企业敏捷转型后，效果并不理想，然而问题在哪儿呢？本次工作坊将会从“道、法、术”的层面来解读敏捷，学员将不仅仅知道什么是敏捷，还会了解为什么需要敏捷，敏捷的核心是什么，敏捷会给企业带来什么好处。 Scrum作为敏捷软件开发的一种框架，很简单，但实现起来并不容易。本模块将会分析Scrum价值观，Scrum的基础以及Scrum的概述。 模块2：Scrum角色 Scrum中包含3个角色：ScrumMaster，产品负责人和开发团队。为什么是这3个角色，为什么没有项目经理，一线经理负责什么。这些问题将会在本模块进行解读。 2.1 开发团队 Scrum中的开发团队是自组织的、跨职能的团队，是小的团队，是蜂拥式的工作方式。如何组建这样的开发团队，如何能够激发开发团队的自主性，这个子模块会重点探讨开发团队相关的问题。 2.2 ScrumMaster ScrumMaster是一个全新的角色，他不是项目经理。在Scrum团队中ScrumMaster常常看起来很“闲”，没什么事情做。这是一种错觉，也是一种误解。ScrumMaster可以作为教练，辅导团队Scrum转型；ScrumMaster也可以作为牧羊犬，保护团队不受外界干扰，可以在Sprint内专注于完成Sprint目标；ScrumMaster还可以作为引导师，使团队的会议变得更聚焦、更简单；ScrumMaster还是变革大师，不仅帮助自己团队Scrum转型，还要帮助组织进行转型。 2.3 产品负责人 产品负责人负责最大化产品以及开发团队工作的价值。在Scrum中，通过什么工具，以什么方式，产品负责人可以完成上述的工作，以及产品负责人的职责是什么，将会在这个子模块进行探讨。 模块3：Scrum工件之产品列表和条目 产品列表是团队工作的输入，是至关重要的一环。好的产品列表是ODDE的。如何创建一个好的产品列表，如何拆分产品列表中的条目，都有哪些内容可以放在产品列表中，产品列表的一些常见臭味。以上这些话题将在这个模块中进行深入的探讨。 模块4：敏捷估算与规划 敏捷中的估算怎么做，需要细化到什么程度。敏捷宣言中提到“响应变化 高于 遵循计划”，那么在敏捷中是否还需要计划。敏捷中的规划都有哪些，分别是什么用处，在什么阶段使用。本模块主要讨论这样的一些主题。

作者：安宝平 微信ID: abp0616 Scrum 点滴 一直想把自己使用和学习Scrum的一点心得体会写出来，因为各种原因一直没有动手，（主要原因是懒）。这次参加完“敏捷之旅2016-北京”之后正好碰见个4天的圣诞假期，再不动手就说不过去了。 在现在项目中折腾了将近4年，经历了很多很多，也和其他公司一些人讨论过Scrum，在此期间自己产生过很多疑问，也了解到别人的一些疑问，发现曾经搞清楚的问题有了答案没有记录下来，过了阵子完全忘记了，或者说那些问题的答案逐渐在自己的意识中边缘化甚至消失。自己的“组织过程资产”正在缩水，这是件恐怖的事 。趁着还没大幅缩水的时候做个文字版的记录吧。（如下内容是“现在”这个时刻的记录，半年之后会变化很多，至少现在对于Scrum的理解相比半年之前已经变化很多了。现在先记着，等研究半年后再做个记录。） 先定几个基调，嘿嘿：） 工程师如果知道这么写代码会出bug他肯定不会这么写，基本没哪个工程师故意写出有bug的代码。 工作性质决定了工程师写的代码哪怕一个单词拼写错误都可能出现bug，不是说开发工程师比其他行业的工作人员更容易犯错，而是由工作本身决定。（一个职员写一封英文邮件，有点拼写错误一般不会出现问题）。 个人或者团队的表现好与不好更多的原因在于事业环境因素。如果只抓着个人或者团队的错误不放，很有可能是在舍本逐末\缘木求鱼。 关于工程师文化：大家所谈的工程师文化都是积极的、正面的、向上的。。。我觉得吧，这有点不客观。脱离客观一般会出问题。 Scrum反对教条主义，同时反对生搬硬套Scrum的要求。不要“只是因为Scrum没有明确地提到就假定某个实践是不准许或禁止的。” 想不出来以什么形式记录这些内容，就用了模拟问答的形式，自己感觉良好。哈哈。 Q（1）: 我对于 “敏捷”粗浅的理解？ A: a) 对于比较庞大的需求，相对于瀑布模式，在敏捷中每个迭代都交付庞大功能的小部分功能，而不是等到所有功能都开发完成之后再交付，这种更早、更快的持续交付就是敏捷，是交付层面的敏捷。 b) 为了保证每个迭代所交付的产出具有该有的质量，要对本迭代和之前迭代的所有交付做充分的测试，这些测试要在短时间内完成，人工测试难以完成，所以施行自动化测试（含单元测试、集成测试和页面交互的自动化测试）辅以人工测试。自动化测试速度比人工测试快，这是QC层面的敏捷。 引用某大咖的话“敏捷是一种心态：一种拥抱变化，拥抱学习的心态，敢于尝试，强调实战，快速反馈，适应环境和市场的变化。需要每个成员的紧密合作，需要积极融洽的团队氛围。” Q（2）：Scrum是什么？ A: 在我看来Scrum讲的是工作流程，职责分工，如何与他人合作。是爱德华•戴明博士的管理理论在软件开发这个行业中的具体体现。是适合于软件开发这种工作的项目管理工具。 Scrum的流程是框架，文化理念才是核心。 Q（3）: 为什么要实行敏捷（Scrum）和实行时要注意什么？ A: 每个公司（团队）情况不一样，这个要看出发点或者目的是什么。就怕没有太清晰的目标，同时对于敏捷（Scrum）不甚了解的情况下引入。这种情况下引入Scrum比较容易制造出一个变形的Scrum团队：稍微问一下就会发现，其实是挂着Scrum的“羊头”卖着自己的“狗肉”，各层面问题仍然存在同时还给Scrum安了一个“徒有其名”的罪名。 想实行Scrum之前自己不妨多花些时间想想为什么要改变原来的开发模式，再找个Scrum专家（比如我，哈哈~）交流下，自己对Scrum做个深入了解，看看自己能否接受Scrum及Scrum是否适合自己。 Q（4）: Scrum Master工作的意义（产出），如何衡量？看起来Scrum Master没有做看得见的工作，凭什么要给你开薪水？ A: 这个么。。要是开发团队没有什么问题， Scrum Master确实没太大的意义，我也这么认为。但…是……，如果开发团队有很多问题，比如产出bug量很多，每个开发工程师一周之内用于修bug的时间大于等于1天。这样的情况下Scrum Master如果能把工程师每周用于修bug的时间降到1小时之内，整个团队的效率至少是20%的提升吧。一个团队年度预算如果是500W。嗯，这个产出就比较容易计算了。同时引用某大咖的话“敏捷不仅是对工作的改变，更是精神面貌的改变。” Q（5）: 实行Scrum不需要对远期的需求做讨论（规划），只把当前几个迭代的需求讨论清楚就可以了？ A: 这个是对Scrum的误解！Scrum说的是不对远期需求做过细的讨论，但不是不讨论。比如: l 开发的是一个全新的大项目：在开始第一个迭代之前还是要做高层次的开发规划，比如项目有12个功能模块，要在1年之内完成开发，此时要做一个年度的planning meeting。先把12个模块的流程图做出来，有了逻辑关系就有了开发顺序，再评估每个模块需要的人力。对比现有人员，就会知道是否需要补充新的人员或者评估出年度内会不会需要加班。 l 在已有项目上做新功能开发：在年度之初做planning meeting也是有必要的。只是此时可能不需要画流程图而是根据业务、市场的需求排列需求的开发优先级。 个人认为应该加入到Scrum Master培训中的内容：对于大型项目、多个Scrum团队并行开发的情形要做高层次的年度、季度planning meeting和retrospective meeting。 Scrum强调对于远期的需求不做详细的分析，只对近期要开发的内容做具体的定义，需求的细化是渐进明细的。这里要注意，低层次的、细枝末节的需求可以渐进明细，但是中高层次的需求就不能渐进明细了。反而要像瀑布开发模式那样，在最初就把中高层次的需求定义清楚。即,除了迭代的planning meeting要做，还要做季度和年度的planning meeting，要注意的是，这个年度的planning meeting比迭代中的planning meeting粒度要大的多，绝不是瀑布模型中细致入微的开发计划。对于怎么做如果加个限定词，那就是“必须”、“不遗余力”，否则容易形成需求层面的技术债务。如果在设计系统阶段没有对扩展性，耦合性，系统性能等等这些方面做充分的考虑，等问题出现时再补救会很头疼。张小龙很得意的一件事就是微信从一个小程序到现在的庞然大物没有经历过重构。 Q（6）: 实行Scrum之后不需要写文档了？ A: 这也是对Scrum的一个误解。Scrum强调面对面的沟通，避免撰写详细规格说明书，但不等于完全不写任何文档。有些文档仍然要写，并且要求还不低。我们项目组对于核心功能、重要功能和复杂功能，要求开发工程师一定要写detail design。写完的detail design通过了tech lead的审阅才能开始写代码。在此之前有时还需要工程师写出functional design（功能设计文档），所写的functional design由product owner审阅，审阅通过说明工程师对于功能需求理解到位，detail design审阅通过说明工程师在技术实现上基本没有偏差，再之后进行的开发才不会出现大的偏差。这样的QA工作做的到位再交付给QC时才不会出现过多的问题。我们这里在没有单元测试、集成测试等自动化测试的加持下做到平均每个工程师每个月产生2个bug，很大的原因在于上述QA工作。（不是说自动化测试不需要，不是我们不想做自动化测试，这些由项目组之外的管理层决定。这么大的项目目前由于缺失自动化测试导致的一些问题已经暴漏出来了。）

敏捷度量以及绩效管理，敏捷团队的考核和敏捷团队度量一直是个难题。本文会从度量的目标开始，然后进一步阐述度量的指标有哪些。

2017年第一篇BoB Jiang敏捷新闻稿。 马上要春节啦，再次BoB提前预祝各位敏捷小伙伴，阖家欢乐，身体健康！ 2017年开始，BoB Jiang敏捷新闻开始对外开放，征集敏捷相关新闻、观点、案例分析等稿子（包含但不限于以上类别）。如果您想成为BoB Jiang敏捷新闻编辑的一员，欢迎加我微信私聊。（有心人肯定可以找到我的微信哦） 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— 2017年6月3日在越南岘港举办敏捷之旅全球大会，本次大会将会聚集全球各地2016敏捷之旅最佳话题。详情参考：https://conference.agile-world.com/ 社区 -————————————— 2017年Agile1001（敏捷一千零一夜）有更多的玩法。想要加入我们，可以点击链接查看2017的课程内容。www.hdb.com/party/fcopb.html 2月份Agile1001的活动如下： 2017年2月12日 北京 人脉构建 by 王泽一 2017年2月18日 上海 敏捷团队右脑训练工作坊 by 王伟 2017年2月18日 深圳 精益看板工作坊 by 李国柱 2017年2月25日 北京 精益创业（或待定） by 龚正 2017年2月25日 成都 一起来读书 by 张莹 荐书 -————————————— 《精要主义》这是我读过的最有共鸣的一本书。先说一下整本书的结构： Explore 探索 - 区分出最重要的少数和不重要的多数 Eliminate 排除 - 敢于说“不”，排除不重要的事情 Execute 执行 - 让做重要的事情变成习惯，很容易的执行。 把书中一些共鸣点列举一下： 1. 抽离 - 为思考和探索留出时间。在现在移动互联网时间，每个人每天都非常忙，一点点闲暇时间也被碎片信息所充斥。在这个现状下，尤其需要注意留出时间进行独立思考。作者举出了几个例子（请参考书），我也说一下我个人的感受。冥想（坐享） - 每天有15分钟什么都不想什么都不做，静静的放空自己，注意感受自己的思绪变化。在李笑来老师的得到专栏也有很好的讨论。在最近一个月的练习后，明显我可以更好的认识到自己的情绪变化。 2. 勇气 - 优雅的说不的艺术。一直以来我认为自己是个烂好人，别人求助的事情90%都会答应。读到这一段之后给我巨大的冲击。原来说不有这么多方式，而且即使说不，也不会破坏关系。建议老好人仔细阅读这一章节。（优雅说不的六大原则）

我的2016是成长的一年，飞跃的一年，自己还是非常满意的。获得的证书如下： CST (Certified Scrum Trainer) - 我是中国北方第一位CST 北京邮电大学软件学院工程硕士 - 终于在截止日期之前完成了 既然2016是成长的一年，我想从四个角度来进行总结，即 听 说 读 写 听 今年听了大大小小10来个培训或大会，但其中只有如下几个很有收获： 自费听的2个工作坊（培训）：Leading Agile Organization by Pete Benhrens, Problem Solving Leadership by Jerry Weinberg and Esther Derby 公司组织的培训：水平思考 by Sally老师 在线课程：敏捷教练修炼之道 by Lyssa Adkins 大会：AHA小会，Global ScrumGathering Bengluru, Regional ScrumGathering Hangzhou 说 线下分享10+。分享话题有《回顾工具箱》《设计思维体验工作坊》《提升团队研发效率1倍不是神话》《影响地图体验》。分享的大会有ToP100，TiD，PMI Congress2016，厦门技术峰会，怒马线下活动，Agile1001线下活动，Global ScrumGathering Bengluru等。 线上分享10+。分享话题有《Scrum精髓》《精益看板》《敏捷领导力》《精益创业》《设计思维介绍》等 值得一提的是，今年第一次用英语进行分享。还是颇有一些挑战。 读 书籍：2016完整读过5本书，（有读书笔记）分别为《开放空间技术》《人人都能用英语》《重新定义工作》《把时间当做朋友》《即兴的智慧》另外还有一些零零散散的阅读记录，如《如何构建敏捷项目管理团队》《Scrum敏捷软件开发》《管理的未来》《给经理人的第一课》等 APP：最大的惊喜，发现了得到app，并订阅了《通往财富自由之路》专栏，借着这个平台发现李笑来老师很多的文字，如公众号，如免费书等等。 写 写博客50+。欢迎访问BoBJiang博客（https://bobjiang.com） BoBJiang敏捷新闻（月度）5篇 每日反思，2016年4月21日至今每天记录

本篇是2016年最后一篇BoB Jiang敏捷新闻稿。2016年8月份开始，每月我都会发布一篇新闻稿，里面包含新闻、社区、荐书以及课程四个部分。如果您对敏捷新闻稿有什么建议、想法或意见，都欢迎回复邮件联系我。 2017年开始，BoB Jiang敏捷新闻开始对外开放，征集敏捷相关新闻、观点、案例分析等稿子（包含但不限于以上类别）。如果您想成为BoB Jiang敏捷新闻编辑的一员，欢迎加我微信私聊。（有心人肯定可以找到我的微信哦） 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— 敏捷学习指南-带你从入门到深入。11月我发表于CSDN极客头条的一篇文章，敏捷从入门到深入一条可能的路。 社区 -————————————— 敏捷之旅陆续在国内多个城市举办，大部分都已经举行过了。 敏捷之旅北京也在12月18日完美收官，2017年Agile1001（敏捷一千零一夜）有更多的玩法。想要加入我们，可以点击链接查看2017的课程内容。www.hdb.com/party/fcopb.html 2017年1月15日 在北京，一起体验视觉记录吧。https://www.hdb.com/party/pze3b.html 2017年1月8日 在上海，设计思维体验工作坊。 https://www.hdb.com/party/xor3b.html 荐书 -————————————— 《Scrum敏捷软件开发》作者Mike Cohn。本书是Scrum敏捷转型的宝典，值得反复阅读。每次阅读都能再次从中受到一些启发。最近又翻开了这本书，两个点很有感受： 1. ADAPT模型，即改变需要如何发生（不仅限于Scrum转型） 1.1 Awareness 意识。意识到需要改变，可以通过度量数据，沟通达到目的 1.2 Desire 渴望。告诉团队有更好的方法，创造紧迫感或者造势等方法可以帮助实现目的 1.3 Ability 能力。提供辅导、培训（可以参考下面的课程）或共享信息等工具 1.4 Promote 推广。讲述成功的故事，吸引注意力，勾引兴趣。让更多的团队愿意接受改变 1.5 Transfer 传递。Scrum这个框架如何传递给公司其他部门，而不仅仅是IT部门自己玩 2. 自组织团队的CDE 2.1 Container 容器。自组织团队的边界在哪里，找到合适的范围（即容器） 2.2 Differentiator 差异。团队的差异是什么，扩大或减小差异对团队的影响是什么 2.3 Exchange 交换。信息在团队内是如何流动的，怎么样最大化信息流动，知识传递 课程 - Certified Scrum Master (CSM) 敏捷认证课程 -————————————— 2017年1月12日13日 成都 https://yihuode.io/activities/404 2017年3月23日24日 北京 https://yihuode.io/activities/419

这是我11月发表在CSDN极客头条的文章。 什么是敏捷 敏捷（Agile）是一个全球性的运动，它正在改变我们的工作环境。敏捷这个词是2001年17位软件行业的大牛在一起讨论得出的（参见敏捷宣言），目前敏捷正在扩展到各行各业，而不是仅仅限于软件行。 敏捷到底是什么？我们看看下图（感谢Lynne Cazaly总结的40多种敏捷方法和框架）： 图1 40种敏捷方法和框架 上图所示，敏捷中有40多种方法和框架，超过70多种的具体实践，那么如何把这个概念介绍给他人呢？Cockburn博士（Alistair Cockburn）曾经是这么定义敏捷的： 敏捷是尽早频繁的交付商业价值。（Agile is to deliver business value early and frequently） 下面我们一起来看看，为什么我们要敏捷。 为什么要敏捷 了解敏捷之前，我们可以一起来看一下为什么我们要进行敏捷。敏捷可以帮助组织或公司来应对持续不断的变化，来应对这个VUCA（Volatile, Uncertain, Complex, Ambiguous）的世界。解决快速变化的唯一方法就是拥抱敏捷。由于软件变得越来越重要，敏捷也逐步变成企业转型的关键。 在敏捷的组织内， 自组织团队通过短期迭代（通常为1-3周）的方式快速交付客户价值。小团队都采用相同的节奏进行交付，因此大型的复杂产品开发也可以由多个小的自组织且端到端的特性团队来完成。敏捷是更聪明得工作，而不是更苦逼得工作。敏捷不是用更少的时间完成更多的工作，而是用更少的工作产生更多的客户价值。 敏捷入门 在我的培训课中，通常有学员问“ 一个人可不可以敏捷？” 我的回答是“必须可以”。下一个紧接着的问题就是“怎么做”？ 回答这个问题之前，我们一起回顾下敏捷的基础：透明、检视和调整。根据这三个基础，我们逐一来看怎么做。 透明。 人类大脑的美妙之处在于思考，而不是记忆。你是否有过某件物品突然之间就是找不到了？你是否碰到过有个人的名字就在嘴边，说不出来了？这就是我们通常说的大脑短路，忽然想不起来了。那么对于这些需要记忆的信息，我们需要做的是把它写下来，存储到一个便于查找的地方。比如我常用的几个工具是：笔、本子、印象笔记。笔和本子记录平时的各种想法、学习笔记等，还有一个专用的本子记录行程，印象笔记记录不错的网页和图片。这些信息对我来讲都是透明可视化了，我清楚地记得它们的位置。 检视。检视指的是不仅要记录，还要不断回过来看一下。做了一些尝试，记录一些内容，回过头来看看，通常会冒出一些新想法。这些新的想法也可以补充到笔记上去。 调整。做到透明和检视还不足够，还需要不断调整。这个调整有一个重要的动作指的是反思。回顾反思之前我做过的事情，哪些地方做的非常不错，哪些地方还可以提高，从中学到了什么，以后我可以做出哪些改变。 一旦掌握了上述的三个基础，个人开始就变得敏捷了，也变得更加开放和包容了。 我们最常说的敏捷，指的是团队级别的敏捷。透明，把团队的进度公开可视化。检视，团队不断回顾检视潜在可交付的产品增量。调整，团队不断反思如何改进工作方法和工作流程 同理，组织或者企业层面的敏捷也是按照同样的思路进行。 敏捷基础 敏捷的学习可以参考日本合气道的修炼之道，守破离。在学习敏捷之前，可以先选择一种敏捷方法或框架，如Scrum。然后守破离。守，指的是完全遵守Scrum框架的规定，不去进行调整或定制。要的是一丝不苟的练习。这个阶段至少6-10个迭代。破，可以对Scrum进行调整（打破框架），这个必须是在团队进行了大量的练习之后。一次一个地方进行调整试验，然后总结。然后再调整再总结。离，指的是根据实际情况，采用适合当时情况的措施，做出合适的应对。这个时候已经不是Scrum，也不是极限编程这样的方法或框架。 而是心中时刻留存的是敏捷的精髓，即敏捷宣言。以及敏捷的基础，透明、检视、调整。 常见的敏捷方法和实践包含：Scrum、极限编程、看板方法以及持续集成。 敏捷核心 敏捷核心的内容包含：敏捷宣言，以及敏捷原则，敏捷的心态（敏捷基础）和敏捷价值观。 敏捷进阶 敏捷入门之后，可以在这条路上继续前行。本部分一共包含三个方面：敏捷知识、教练知识、引导知识。上述每个方面的知识，从入门到精通至少需要七年时间（参见李笑来所著的《新生—七年就是一辈子》）。 专业知识：敏捷 图1所示的敏捷包罗万象，包含40多种方法，那么如何去学习敏捷专业知识是一个复杂的事情。建议可以从其中的1-2种方法或框架入手，如当前最流行的Scrum框架。Scrum入门可以参考官方提供的《Scrum指南》 ，想要全面学习Scrum，可以参考《Scrum精髓》。 学习的方法有很多种：如体验、观察，这些是基础的学习方法。举个例子，记得有一次去北戴河度假，有段时间流行自己蒸海鲜，我们买了一堆螃蟹回去。丈母娘自告奋勇帮忙洗海鲜，忽然我听到一声惨叫，哎哟哎哟。我赶忙跑过去看看发生了什么事情。原来丈母娘的大拇指被螃蟹给夹住了。仔细询问后得知，丈母娘把绑着螃蟹腿的皮筋解开了，想要放开洗。我相信丈母娘以后会非常小心螃蟹的钳子。这种学习的方式叫做体验，你亲身体验了就会记忆深刻。当时我老婆站在附近，她也看到这件事情。那么她也学到了要小心螃蟹钳子。这种学习叫做观察。对应到如何学习敏捷（具体说是Scrum），最好的方法是体验，在自己的团队中开始尝试采用Scrum。如果实在没有环境，也可以采用观察的方法。找一个正在采用Scrum的团队，去观察团队是怎么做的。 还有两种高级的学习方法是阅读和反思。阅读是拓展知识非常有效、非常快速的一种方式。世界上的事物有千千万万种，我们不会有那么多时间和精力一一进行体验。因此我们可以通过阅读优秀书籍来进行学习。拓宽自己的眼界和知识，这也是为什么敏捷当前包罗万象。另一种高级的学习方法是反思。曾子 曰：吾日三省吾身。每天都需要反思一下，那么反思怎么做，都需要反思什么。 对于个人反思，可以每天睡觉前花5-10分钟思考以下三个问题：今天我什么事情做得非常棒？今天有什么事情我可以做得更好？今天我学习了什么新的知识？ 对于团队或组织的反思，可以通过定期（如每周、每 月）组织回顾会议来实现。组织一次回顾会议可以参考这个步骤：预设会议基调，收集数据，激发灵感，决定做什么，总结收尾。具体每个步骤中的环节，可以参考《敏捷回顾》。 专业知识：教练 什么是教练？专业教练作为一个长期伙伴，旨在帮助客户成为生活和事业上的赢家。教练帮助他们提升个人表现，提高生活质量。教练经过专业的训练，来聆听，观察，并按客户个人需求而定制Coaching 方式。他们激发客户自身寻求解决办法和对策的能力，因为他们相信客户是生来就富于创意与智慧的。教练的职责是提供支持，以增强客户已有的技能，资源和创造力——（摘自百度百科）。 为什么学习敏捷，还需要学习教练知识。让我们一起看下敏捷宣言中的“个体与互动高于流程与工具”。这里个体与互动，强调的就是人以及人与人之间的互动（即团队）。如何激发个人表现，改善个 人的生活与工作，对于这些教练可以有很大的帮助作用。针对具体的教练技术和流派，在本文就不一一详述，有兴趣的朋友可以网络搜索一下，或者参考ICF（International Coach Federa）官方网站 。 专业知识：引导（facilitation） 什么是引导？引导是指通过创造他人积极参与，形成活跃氛围，从而达到预期成果的过程。这种成果可能简单到学习一项新技能，也可能复杂到解决一个跨组织和部门的复杂问题。总之，引导的作用就在于积极引导他人主动参与的互动过程。 在团队的日程工作中，团队会议是最常见的活动。那么如何形成活跃氛围，如何帮助团队高效组织会议，如何能够达成预期，如何解决跨部门的复杂问题等等。这些问题都可以通过引导来进行有效的解决。如《敏捷回顾》 一书中，就提到了很多引导的技巧。学习引导还可以参考《引导》这本书。引导进阶可以参考《引导的秘诀》。