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）这个词呢？据称当时有两个提议： Adaptive 来自Jim Highsmith的提议，和 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.

《在TOYOTA学到的只要纸1张的整理技术》 作者：浅田卓 本书的核心 一句话，用一张纸整理思路。 适合场景 工作清单 会议（培训）记录 市场分析 新商品策划 一张纸文件的共通点 目的 现状 课题 对策 日程 如何用一张纸进行整理 第一步，将思考用的基础信息整理到文件内 第二步，将自己独有的思绪、归纳到文件内 第三步，文件的内容要传达、沟通的对象 讲概念的三板斧 Why，这个概念的目的是什么，有什么好处 What，这个概念是什么，听众想听什么 How，这个概念如何用到我的工作或生活中 举例子 如何用一张纸进行自我介绍 在一张A4纸上画出8个（或者16个）格子 在左上角的格子内写上自己的名字 30秒内迅速填满剩余格子（填写内容为你想到自己特点的关键词，即你想要介绍的方面。只写关键词即可） 格子之间找关联，相同类型的标识一下 排序，介绍的时候先说哪个部分，再说哪个内容 下图是工作坊中大家介绍的例子，大家自我介绍完后都觉得这样进行介绍太轻松了。 用一张纸进行自我介绍的示例图 为什么一张纸这么有效 最后这里我自己总结了一下为什么一张纸这种方式有效。因为这种方式它有效地帮助我们进行了思考的分类。 比如上述的例子主要分为三大步骤： 收集整理数据。这个步骤做的事情是发散，头脑风暴。目的是记录脑子里出现的所有和目的或主题相关的词。 思考、归纳、找出联系。这步做的是思考。在上一步的基础上，审视已有的关键词，找出它们的联系，进行深度思考。 做出决策。最后基于上面的思考，进行最后的决策。 有关于决策，也叫作选择，是一个很大的话题。下一次我想专门来聊一下选择这个事情。 下一个话题你期待吗？

Norman Kerth 在《Project Retrospectives》一书中曾提到回顾会议的primary directive principles: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. 无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。 如何理解回顾会议最高指导原则 这句话至少有三层深意： 信任 对事不对人 发展的眼光 信任 人与人之间很重要的一层关系是信任。唯有信任，团队才是真正的团队；唯有信任，人与人之间的协作才能顺畅。在回顾会议中，第一个要传递的信息就是信任。管理者对于团队是信任的，相信团队每个成员都已全力以赴。团队成员之间也是互相信任的。我们在现有已知情况、个人的技术水平和能力、可用的资源下已经做到最好。 对事不对人 回顾会议的目的是帮助团队提高与改进工作的流程。在这个过程中，团队必然会碰到发生过的问题。那么针对每个问题，必须明确的一个原则是对事不对人。我们现在讨论这个问题，目的是能从这个问题洞察到更深层的原因以避免之后发生同样的问题。而不是为了羞辱一个人。作为引导师，需要密切关注会议中的氛围。一旦发生针对个人的行为，引导师需要立刻采取行动。根据行为的严重程度采取的应对方式不同，细节可以参考引导方面的书籍。 发展的眼光 指导原则中提到“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况……”，这段话说明即使现在发现了问题，部分是由于个人技术水平和能力有限，那么给我们一个很好的启示是，团队现在某个方面技术水平和能力需要提高，即团队（或个人）总是有提高发展的空间。 如何使用回顾会议最高指导原则 我最常使用这个原则的方法是：每次回顾会议开始的时候，团队全体成员集体朗读一遍。确信大家都理解之后才进行下一个环节。 ————————————————————— 最后广告时间 – Scrum联盟的CSM敏捷认证课程 2017年4月16日-17日 上海 2017年4月24日-25日 深圳 2017年5月25日-26日 北京

阅读《技术人创业攻略》一书中，作者对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：敏捷估算与规划 敏捷中的估算怎么做，需要细化到什么程度。敏捷宣言中提到“响应变化 高于 遵循计划”，那么在敏捷中是否还需要计划。敏捷中的规划都有哪些，分别是什么用处，在什么阶段使用。本模块主要讨论这样的一些主题。