“就是他，就是他撞的我们”

——2014年2月15日中午，在我回家的路上，确切的说是马上进入小区大门的时候，我结结实实的撞上了一辆三轮摩的。“我的个娘亲，新车处女撞”就这么没了。如下图，我从南向西左转弯进小区，摩的从北向南直行，转弯不让直行，非常明显我应该负全部责任。

狗血第一幕：警察在现场发生的事故。

在我左转弯位置的前方有一辆警车，正在处理另一起交通事故。警察叔叔亲眼目睹我撞车全过程。撞车之后，我第一时间下车，想看一下摩的的情况以及是否有人员受伤。没想到啊没想到，摩的想要逃逸。。。怎奈摩的大叔没有想到咱是山东大汉，想当年景阳冈上武松打虎，都是何等威风。对付一个小小的摩的，那是手到擒来。嗨！哪里跑！我一下子就把摩的前轮抬起，失去了动力，它也就跑不掉了。警察叔叔关键时刻快速跑来，拔下摩的车钥匙。拿下！

狗血第二幕：摩的司机竟然是……

我和警察叔叔拦下摩的后，回到本文开头，一位大妈厉声怒斥：“就是他，就是他撞的我们！”什么情况啊，我刚刚拦下摩的，还没有和摩的交涉细节，就杀出一个程咬金。（该不会是趁机敲诈摩的司机吧）这时候，警察叔叔起到关键作用。他竟然判罚这次事故是主次责任（我负主要责任）。那也就是说摩的有责任啦，jcss问你们要不要私了。。。此处按下不表，回到大妈那边。不大一会儿，就出来4、5个壮小伙子，拦住摩的司机不让走。摩的司机死不承认和大妈有任何瓜葛……最后经过jcss的现场勘查鉴定（开头提到的另一起事故），我撞下的摩的司机，原来他真的是另一起事故的肇事者！

结尾：天网恢恢疏而不漏

摩的司机怎么这么笨蛋，撞人逃跑了，还要回来？回来之后又被我撞倒！真所谓“天网恢恢疏而不漏”。

最后附上我受伤的大拇指留念（拦截摩的时所伤）。

OKR是Objectives and Key Results的缩写，这套系统由英特尔公司制定，在谷歌成立不到一年的时间，被投资者约翰·都尔(John-Doerr)引入谷歌，并一直沿用至今。

那么OKR和KPI之间有什么联系和区别呢？

1. 国内的很多绩效管理，很多时候只是做到了“考核”这一步而已，并不是完整的绩效管理体系，这是大前提。 2. OKR的思路是先制定目标，然后明确目标的结果，再对结果进行量化，最后考核完成情况。本质上和其他的绩效管理思路没有太大的不同。任何一种绩效管理，都是先有目标，对目标进行分解，量化KPI，然后考核。 3. 说说OKR和常规绩效考核的不同。

（1）.OKR实行的前提，是员工具有主观能动性、创造性，并且具有较高的职业道德素养和突出的专业技术能力。OKR体系下的目标，是由个人提出，然后由组织确定，这点与常规的KPI自上而下的方式不同。 （2）.其实目标管理法，德鲁克大师在1954年就提出来了。德鲁克1954年提出一个“目标与自我控制管理”。德鲁克认为，并不是有了工作才有了目标，而是相反，有了目标才能确定每个人的工作。不过，德鲁克的这个理论，更偏向于组织目标的统一性。 （3）.其实，任何一个公司，都有一部分员工在使用OKR思路，不过大部分员工采用的是KPI思路。区别在于： A. KPI思路是自上而下，首先确定组织目标，然后对组织目标进行分解直到个人目标，然后对个人目标进行量化。 B. 而OKR的思路是一定程度上的自下而上，个人提出目标，然后对目标进行量化。通过把大量的个人目标进行统一，汇总成公司的目标。

那么作为Google使用的OKR有哪些特点：

1. 简单：操作简单，每个被考核者的目标不超过5个，目标多了方向不清晰，重点不明确。每个目标不超过4个具体KR （具体行动）。简单就是抓住重点，容易操作；

2. 直接：每个KR都必须是能够直接完成相对应目标的；不是间接完成，更不是协助完成，最不能接收的就是可能有帮助；

3. 透明：每个单位、每个人的目标和KR，以及最终的评分都是对整个公司，甚至对每个人都是公开和透明的。一来有助于团队合作，二来有助于公平，三来是一个不错的激励手段，总是完成的不好是很丢人的咯。

具体实施OKR的关键点是什么：

1.设定目标。如何设定目标，可以参考SMART原则。

2.明确每个目标的****KRs（关键结果）

3.定期回顾。每个季度做回顾。到了季度末，员工需要给自己的KRs的完成情况和完成质量打分——这个打分过程只需花费几分钟时间，分数的范围在0到1分之间，而最理想的得分是在0.6到0.7之间。如果达到1分，说明目标定得太低；如果低于0.4分，则说明可能存在问题。

阅读首先应该是一种主动阅读，一种学习的态度。

根据本书的一些规则，针对《如何阅读一本书》本身，我尝试回答以下问题。

这本书的分类

实用性的书

用最简短的文字描述本书在谈些什么

阅读的层次，以及针对不同类型的书的阅读方法

作者要解决的问题是什么

提高阅读水平

阅读分为4个层次（每个后面的层次都包含前一个层次）

1. 基础阅读
2. 检视阅读（可以理解为粗读、或快速阅读，虽然不是完全一致的含义）
3. 分析阅读（精读，吃透一本书）
4. 主题阅读（某个相关主题的一系列书记的阅读）

基础阅读还可以分为4个阶段：

1. 阅读准备阶段：从出生到6、7岁。
2. 学习读一些简单读物（看图识字，几百字的书籍）。
3. 快速建立词汇的能力，从上下文所提供的线索，“揭发”不熟悉的字眼。
4. 精炼和增进前面的技巧。

检视阅读分为2个阶段：

1. 有系统的粗读——帮助读者分析在这个阶段一定要回答的问题。准备了解书本的架构。
2. 粗浅的阅读——帮助读者在分析阅读中进入第二个阶段。

分析阅读，本书做了大量的介绍。分为3个阶段，15个问题。

1. 找出一本书在谈论什么
   • 按照书的种类和主题进行分类
   • 使用最简短的文字说明整本书在谈些什么
   • 将主要部分按顺序和关联性列举出来。将全书的大纲和各个部分的大纲列出来。
   • 确定作者想要解决的问题
2. 了解一本书的内容
   • 找出书中的关键字
   • 由最重要的句子中，抓住作者的重要主旨
   • 知道作者的论述是什么，从内容中找出相关的句子，再重新架构出来。
   • 确定作者已经解决了哪些问题，还有哪些是没解决的。再判断哪些是作者知道他没解决的。
3. 评论一本书
   • 除非你已经完成大纲架构，也能诠释整本书，否则不要轻易批评。
   • 不要争强好胜，非辩到底不可
   • 在说出评论之前，你要能证明自己区别的出真正的知识和个人观点的不同
   • 证明作者的知识不足
   • 证明作者的知识错误
   • 证明作者不合逻辑
   • 证明作者的分析和理由是不完整的

主题阅读：

1. 准备阶段：针对要研究的主题，设计一个试验性的书单。
2. 浏览书单上所有的书，确定哪些和主题相关。
   • 浏览所有确定的书籍，找出相关章节
   • 根据主题创造出一套中立的词汇
   • 建立一个中立的主旨
   • 界定主要和次要议题
   • 分析这些讨论

敏捷转型是一种涉及管理层的组织级变革。我们常说管理层的认同对于敏捷是否能取得成功很关键，缺少管理层的支持，敏捷转型就可能会遇到巨大障碍。公司中管理层支持敏捷有很多不同的方法。

Arijit Sarbagna在《规范的Scrum（prescriptive Scrum）》一文中讨论了在敏捷转型过程中管理层的认同和支持的重要性：

假设我们正在以敏捷方式开发项目，最初采纳敏捷不是自上而下的，而是徒劳的“自下而上”。在这种情况下中，很可能我们就会错失了“管理层认同”这个关键因素。缺乏管理层的支持，打造自组织团队的良好意图很可能会走进死胡同。作为ScrumMaster或者敏捷教练，我们需要花费大部分的精力来说服管理层（或者客户），而不是实际上的指导团队。

根据Arijit的观点，对经理而言支持自组织团队非常困难：

（……）管理团队遭遇决策的困境，在团队成为“自组织团队”过程中应该留有多少回旋余地。这很搞笑方，我们不得不跟管理层解释敏捷是如何工作的，为了使敏捷有效，管理层应该相信敏捷。有时我们必须要提醒管理层，如果我们不信赖员工，即使瀑布式开发也不会成功。信任是成功的支柱，围绕着信任我们补充了工程实践。

Arijit建议经理不应该强制实施Scrum：

但是，如果我们正在处于规范化Scrum困境的话，比如很可能管理层会指导团队，敏捷应该怎么做（或不应该怎么做）——这些人可能从未实施过敏捷而只有理论知识——那么这只会让事情变得更糟，或者变成“失败的故事” 。

相反，Arijit建议“宣扬和鼓励理解敏捷的人，从而拥抱实践”。

Zvonimir Križ写过一篇文章《亲爱的经理，我们已经敏捷了（dear management, we’re already agile）》，文中质疑缺少管理层的支持是否是采纳敏捷的真正障碍。这个问题可以理解为，当关注于实践而不是敏捷原则的时候，实施敏捷的唯一方法就是自上而下：

从诸如Scrum之类的实践直接开始敏捷可能使人们相信，敏捷“旅程”需要深层的组织变革。当然组织变革需要管理层的支持。另一个更有趣的原因是瀑布式开发本身。为了更加精确，瀑布式开发需要大量的前期规划（upfront planning）。这也是我们大脑中的一种思维惯性，为了成功，所有事情——包括敏捷转型——都应该详细规划。此外，管理层需要如此大量的前期规划和重大决策。

Arijit建议敏捷转型还可以采用自下而上的方法：

有时候人们忘记了自下而上的敏捷转型是合理的。

每个人应该都知道采用敏捷原则不需要依赖管理层。（……）你可以现在就开始。不需要任何理由！

我们曾采访过Jeff Sutherland，他在《敏捷做了对的事，但方向却错误（agile done right and agile gone wrong）》一文中提到了领导力和团队。Jeff在Google Plus上分享了这次采访，他提到管理层可以采取如下做法来支持敏捷：

这和管理层的认同无关。而是与敏捷管理层如何敏捷、领导以及展示变化相关。在某些大型公司内，会有由高级管理层组成的Scrum团队。他们不会赋予团队执行Scrum的权利，而是自己也在执行Scrum，并且希望团队和他们一样执行Scrum。

在敏捷转型过程中，中层管理者该如何支持呢？Em Campbell-Pretty写了一篇文章描述这个问题《对敏捷教练与中层管理者沟通的建议（advice for agile coaches on “dealing with” middle management）》。文中说明了为什么管理层的认同如此重要：

和开发团队一起工作时，中层管理的认同非常关键。对于敏捷转型工作，中层管理者可以是良好的动力也可以是克星。如果团队认识到管理层不支持敏捷，那么在试验和冒失败风险的时候他们还会觉得安全吗？我曾见过有些组织尝试敏捷转型，而管理层仍然是传统思维。对于团队而言，这将是毁灭性的问题，如果团队相信敏捷的价值观如透明性，那么他们就会因为暴露事实而受到管理层的谴责。

针对如何解决来自中层管理者的阻力，Em Campbell-Pretty给出了如下建议：

有些管理者慢慢发现敏捷对他们有威胁。实施敏捷很可能意味着改变，没有人喜欢改变。在这种情况下，或许可以考虑一下Dennis Stevens和Mike Cottmeyer的建议（Agile 2013大会上的“不要谈论敏捷”），而不是迫使顽固的经理实施敏捷。相反，我们应该关注于业务目标，以及如何帮助管理层达到他们的目标或减轻他们的痛苦。

通常组织里的中层管理者也同样处于困境。根据Em的文章，敏捷教练应该负起责任，寻找方法和中层管理者一起工作并支持他们的工作：

中层管理者其实并不容易，实质上他们就像“三明治里的肉”，处于组织的高级管理者和普通业务人员之间。中层管理者的责任大于权利的情况司空见惯。这可能非常令人沮丧，并且让我怀疑命令与控制管理风格的盛行，是否是大型的官僚组织里中层管理者丧失权利的直接后果。中层管理者的注意力从组织繁文缛节的沮丧转移到改善员工的生活上，对于管理者和团队都是一种回报。不要忘记，中层管理者和其他人一样，倾向于能为我带来什么好处（WIFM——what’s in to for me）。中层管理者必须明白敏捷会如何帮助他们获得成功。

Mike McLaughlin写了一篇题为《耐心的敏捷教练（the agile coach on patience）》的文章，文中他谈论了敏捷转型对于中层管理者的影响：

许多中层管理者在放手控制权上似乎都有一段困难时期。他们觉得还是需要插手。微观管理了许多年，可能有数十年，要想打破这些实践很困难。即使在团队授权的重要性方面中层管理接受过很多培训，但是在脑海里，他们仍然不确信团队是否可以完成工作，因此还是继续执行微观管理。

几乎我教过的每堂课或辅导过的每个组织都有下面这个问题：“我应该用什么指标来确定团队是否运行良好？”我可以理解这个问题的背景是，大多数人想问开发团队的绩效，而不是整个Scrum团队（包含产品负责人、ScrumMaster和开发团队），也不是整个组织的绩效。

有时候我也想知道开发团队做得怎么样，所以我会在本文阐述这个问题。但是，对我来说这个问题和下面两个问题几乎不相关：“作为敏捷组织我们做的怎么样？”或“Scrum团队做的怎么样？”。这些问题的答案可以使我们在经济相关性和可操作性层面有更深入的理解。在组织层面我想了解我们是否高效地交付客户期望的价值。为了理解这一点，我会采用如下指标：

• 无用功（Idle work） 和闲散员工（idle workers） — 衡量工作流受阻的时间和频率（而不是衡量员工有多忙）。
• 交付可工作和验证过的产品—如果我们交付的产品客户不用的话，那么按时及在预算内交付就没有任何意义。
• 作为组织我们的学习速度—采用如innovation accounting （精益创业的概念）的指标来评估我们学习的速度，该速度可以作为汇聚业务价值结果的进度指标。

在组织层面之下我会关注整个Scrum团队。3个角色一起交付正确的客户价值并快速较好的完成。所以我更喜欢下面这个指标“每个迭代Scrum团队都在交付较好的价值吗？”(more on this shortly)。但是如果我们只想衡量开发团队怎么办（以下简称“团队”）？或许我们想知道给团队分配某人是否是正确的选择。如果开发团队会长久在一起，那么我们就想知道团队的绩效。下面我推荐几个指标（排除使用开发速率）：

• 几乎每次团队都能完成迭代目标
• 产品负责人相信团队交付较好的经济价值
• 团队以可持续的节奏工作
• 团队的T型技能（一专多能）
• 团队的学习速度

开发速率（不建议使用这个指标）

许多人认为，开发速率是一种衡量团队绩效显而易见的方法。不幸的是，开发速率应该只是一种计划工具（如发布计划）和团队诊断指标（如流程改进工作）。速率不应该作为一个绩效指标来判断生产效率。因为速率太容易做假了。如果团队成员知道速率作为绩效指标的话，他们就会在每个迭代随意增大产品backlog条目的大小（故事点通胀），或者为了完成更多的故事而偷工减料（注：即牺牲质量或增加技术债）。在《Essential Scrum》一书中，详细描述了什么是速率，应该如何使用速率以及应用速率的误区。在本文中，我不会把速率作为团队绩效的指标。

实现迭代目标

排除了开发速率，我们应该用什么来衡量团队绩效呢？一个指标是团队以什么频率实现迭代目标。作为Scrum原则，每个迭代应该有一个目标（就像可执行的汇总说明），这个目标是团队一起承诺要实现的。每个迭代团队尽最大努力实现目标。我宁愿每个迭代团队没有完成目标，因为这可能是团队习惯性无法完成承诺的迹象。有时候，团队为了达到目标做出了相当的努力，但最终由于正当的原因（比如目标的弹性比较大）而没能完成。这个现象更好地表明了团队应该在合理的限度内进行工作。

交付价值

检查和平衡团队“虚报估算”的一种简单而恰当的方法是，咨询产品负责人是否每个迭代都能获得良好的价值。多数的迭代都是固定成本的——我们知道团队人员和迭代的时间长度都是固定的，因此每个迭代的成本也就是固定的。假设每个迭代的成本是2万美元，对产品负责人而言一个重要的问题就是，“你觉得每个迭代能至少获得2万美元的价值吗？”好的产品负责人会知道答案。如果产品负责人说，“没错，我很满意团队正在交付的价值，”那么这就是团队良好绩效的表现。再说明一点，产品负责人对迭代级别和发布级别的经济性是总体负责的。因此，如果产品负责人草率地花了2万美元，让团队只交付1万美元的价值的话，那么这个产品负责人就是不负责任。总之，交付良好价值是整个Scrum团队（产品负责人，ScrumMaster和开发团队）的责任，当评估开发团队时可以考虑这个指标。

可持续的节奏工作

我还想要知道是否每个迭代团队都能以可持续地节奏交付良好的价值。我们都见过为了交付迭代目标而一周工作80小时的情况。对于这个情况的第一个反应可能是，“看看，多么棒的团队，他们为了完成工作愿意加班！” 常常一个迭代中为了完成目标，工作更长时间切更努力一点是必须的。因为总是有一些难以预料的事情。然而，人们不能长时间以这种节奏工作，所以一周工作80小时的团队不会长久的成为“优秀团队”，很快他们就变成“疲惫不堪的团队”了。因此，第三个衡量高绩效团队的指标是，每个迭代都以可持续的节奏交付良好的价值。

扩展T型技能

另一个高绩效团队的指标是：“团队成员有没有更进一步扩展T型技能？”T型技能职这样一个比喻，用来描述一个人在专业领域有深入的垂直技能，同时其它相关领域拥有广泛的（没必要那么深入）水平技能。由T型技能的人组成的团队更不易受到工作变化的影响，因为可能多个团队成员都可以工作在该领域上，所以在有大量工作时团队可以蜂拥式的集中工作。我认为团队成员的T型技能是团队健康和高效能的重要指标。

快速频繁地学习能力

最后，需要评估团队的学习能力。尤其是，我想评估团队完成学习循环的能力：假设、构建、反馈、检视和调整。高效能团队总是快速验证重要的假设，并根据结果而采取行动。高效能团队以最大化学习重要细节能力的方式组织工作，因此他们可以根据学习进行调整。考虑到快速而频繁学习的重要性，我会在组织层面和团队层面都采用这个指标。快速学习重要信息并尽最大的努力工作，超越那些学习慢的团队，就像团队那样，学习最快的组织常常痛击他们的对手。

总结

总结一下，当衡量绩效的时候，首先考虑的是较高层面如组织、Scrum团队级别的。当评估开发团队的时候，不要采用速率。相反，考虑之前我提到的一套多维的指标会获得团队绩效的全面情况。最后一点意见。以我的经验，组织里好的经理实际上不需要任何官方团队绩效的指标。这样的经理和团队保持紧密联系，细心观察发生的一切。咨询一个好的经理关于团队绩效，包含强项和弱点，这个经理都会马上给出全面的答案。

英语原文请点击链接

人生的5F

很早以前，时大鲲公开表示把自己的人生次序用5个F来排列（按照重要顺序从上到下）：

• Faith - 理念或信仰
• Family - 家庭
• Firm - 公司
• Fun - 娱乐
• Future - 未来

点评：人生在世，时间非常短，做事就要有一个先后，主次顺序。否则东做一点，西做一点，到头来就是大黑傻子掰苞米——两手空。时大鲲的这个5F就完美的总结了成功人士看待事情的优先级。信仰>家庭>公司>娱乐>未来。

企业的3P和3I

全世界的公司，你抽茧拨丝后无外乎有三个核心：

• People - 人员 - 人员需要激励(Inspire)
• Process - 流程 - 流程需要整合(Integrate)
• Product - 产品 - 产品需要创新(Innovate)

点评：太精辟了！3P和3I，公司的事情全都包括了。人、流程和产品，如果哪一个做不好，公司都很危险。

你刚刚走出CSM课程，全身充满了Scrum知识和对于软件开发实践的信心。你迫不及待地要分享新的世界观，以及告诉别人敏捷是如何帮助团队的。但是，在第一个敏捷项目中，你就碰到阻力、反对，甚至更糟糕的，Scrum-But（注：伪Scrum，如每周只有2次站会；流于形式而没有领会Scrum的精髓）。ScrumMaster要做什么呢？

不要放弃希望！你肯定不是第一个碰到这些问题的ScrumMaster，也不会是唯一一个。我以前在项目中碰到过这些情况，并且我很愿意分享给大家。学会克服这些问题，将会使你成为一个优秀的ScrumMaster，也能帮助团队达到高效能。

1. 缓慢开始。

敏捷（Scrum）对于多数团队、公司（尤其是大公司）和文化而言是一个巨大的挑战。仅仅因为你相信Scrum和敏捷的奇迹，这不能保证其他人也有同样的感觉。先尝试实现那些马上有结果的事情（先摘好摘的果实）。如果你所在的组织允许你挑选团队成员的话，那么太棒了。但如果不行的话，比如给你一个组建好的团队，来进行Scrum转型可能会困难一些。因此缓慢开始，先解决团队的问题，比如构建信任……参见《克服团队协作的五种障碍》

2. 有耐心。

我必须强调这一点。团队在第一天、甚至是第一个迭代不会形成自组织。开始的时候，团队很可能不会每天更新敏捷工具（白板等）。每日站会可能超过15分钟或者大家偏离了3个问题的形式。尝试耐心一点，辅导团队让他们时刻记住Scrum的原则。团队会以自己的方式记住这些。团队需要时间学会一起工作，相信彼此，相信流程，信任你（ScrumMaster）。

3. 坚持Scrum。

当团队开始偏离（迫于管理层的要求）Scrum实践时，你就会看到额外的不必要的复杂性。你的工作是在Scrum基础知识方面辅导团队，这些已经被证明是成功的，你要保护团队不受外界的打扰。尽你最大的努力帮助团队，避免修改Scrum。如果团队和管理层坚持要修改Scrum的话…… 那么

4. 多问“为什么？”

这个简单的词可以产生事情是如何完成的现实。通常，偏离Scrum的原因不是实质的问题。通过问为什么，可以找到根本原因并开始解决真正的问题。如果没有得到很好的答案，那么继续问；有时候需要多问几次为什么才能找到原因。（参考精益里面的5个为什么）

5. 说明、解释。

当团队知道你做这些事情的原因，或要求他们这么做的原因后，团队可能更愿意接受改变。通过确认让团队理解为什么要这么做，团队会感到更有自主权，因为这样团队有一个清晰的目标。

6. 授权团队和你自己。

通过授权团队，团队能够获得更多的自主权。这是自组织的第一步。通过授权你自己，你能展示和鼓励团队遵循Scrum。团队通过行动而学习；当你用敏捷的原则行事时，团队都可以注意到。自我授权会让你看起来更加自信，也会成为一个优秀的ScrumMaster。

7. 寻求帮助。

面对现实吧，CSM课程不会告诉你如何面对所有的情况。团队、利益相关人和管理层之间的关系是非常复杂的。不要试图一个人解决所有的问题。团队一起来面对问题，并移除障碍，当然你要展示出识别问题的能力。如果等太久而没有寻求帮助的话，那么团队就危险了——这是ScrumMaster要避免的事情。

8. 寻求反馈并给出反馈。

这点要回到“检视和调整（Inspect and Adapt）”原则。反馈不必等到迭代结束的时候，在回顾会议上提出。如果你发现有可以改进的地方，用建设性的方式提出来，因此你可以很早就帮忙改正问题。同时也要向团队要反馈。欢迎团队提出反馈意见，这样也创建了一个开放的文化和持续改进的环境。

9. 信任团队。

我已经多次提到信任，但信任太重要了我想单独讨论一下。信任即使不是团队必须的最重要的元素，也是最重要的元素之一。团队成员需要相信你，了解你信任团队，并且彼此之间相互信任。团队相信他们可以交付良好的软件，即使碰到了上述的障碍。团队相信走在正确的道路上，会开发出正确的软件，也会最终成功。最重要的是，团队要相信失败不是最可怕的；他们要相信可以做的更好，并且不会犯同样的错误。

10. 习惯不自在的事情。Get comfortable being uncomfortable

Scrum一开始会让人感到不自在。情况不会马上好转：团队的开发速率一团糟，需要花一点时间改变团队的动态，并且管理层不总是支持敏捷。作为ScrumMaster，你会碰到很多的未知，这些都很不容易。此外，当团队开始自组织的时候，团队需要更多的自主权。尤其你以前是项目经理的话，这会让你更抓狂。

另外，拒绝人也是不自在的事情。你要习惯告诉团队之外的人“可以还是不可以参与”。你需要给产品负责人提出指导，如何在产品backlog里增加用户故事，而不是在当前迭代里面修改产品backlog。你需要拒绝改变Scrum流程，并且你需要组织伪敏捷的方法。保护团队的方法，就是学会说“不”。

回头看看所有这些战胜不自在的方法。相信自己，相信Scrum实践，信任团队会持续在正确的方向上： 努力争取高效能并交付商业价值。

原文链接：https://www.scrumalliance.org/community/articles/2013/january/confessions-of-a-new-scrummaster

注：认真理解并做好上述的方法后，你也可以成为一个认证的ScrumMaster （CSM）

GROW模型是一种解决问题或设定目标的方法，最早起源于1980年的英国。下面介绍一下什么是GROW模型：

Goal - 目标。我最终要达到一个什么结果，可以让客户对自己有一个清晰的规划。 Reality - 现实。当前的现实情况是怎样的，存在什么问题、挑战，以及和目标之间的差距。 Obstacles - 障碍。从现实到目标之间的障碍是什么。如果没有障碍，客户就已经实现目标了。 or Options - 方案。一旦识别出障碍，就需要找出如何移除障碍。这就是方案。 Way Forward - 前进的道路。形成方案之后，就需要具体的行动计划来达成目标。这就是前进的道路。

下面举一个例子

比如我想减肥（作为胖子，泪奔……）。因此我定了一个目标是“在1年之内体重减到70公斤”。下一步找出现实情况（当前体重为79公斤，继续泪奔）。接着我们需要一些开放问题，来引导自己识别障碍并形成方案。

1. 曾经有过减肥吗——如果有减肥前后有什么区别？
2. 减肥后反弹是什么心情？
3. 这次想要有些什么改变来保持体形？

假如我能很好的反思这几个问题，就会发现在减肥的时候，哪些行为会阻碍减肥、哪些方法有效。接着会根据这些发现来寻找解决方案，（比如减肥菜谱，增加运动）一旦我找出这些，就会建立一套可行的行动计划。毫无疑问要对自己做出承诺，每天需要坚持某个减肥菜谱，每周进行多少运动。

GROW模型里面有2个非常关键的元素：1. 设定目标。我们想要达到什么，时刻记着自己的方向。2. 识别障碍。找出现在的情况，并识别出有哪些因素阻碍达到目标。

《网球的内心游戏》作者Tim Gallwey将GROW模型在学习领域做了进一步的推广与应用（不仅仅限于学习打网球）。

1. 在多数学习环境下，学习者很少会关注正在发生的事情。如果学习者能够更加关注当前的事情，而不是“应该做什么”或“怎么做对”的话，那么他们将取得更大的进步。
2. 当学习者关注于当下的时候，他们就会察觉如何可以获得成功。
3. 如果学习者关注观众、奖金或耍酷——这些毫无疑问会妨碍专注力，从而导致失败。学习过程中越少的打扰，通常来说进步会越大。

卡诺模型是有关需求认知的一个很重要的模型。1984年日本人Noriaki Kano博士提出的。在这个模型里把需求分为4类。

• 亮点（attraction）需求
• 线性（linear）需求
• 基础（fundamental）需求
• 无差异（indifference）需求

模型是一个二维图表，横坐标是产品功能（左边是不需要实现，右边是必须实现），纵坐标是客户满意度（上边是客户非常满意，下面是客户不满意）。

一个产品的需求无外乎包含以上4类需求。我们需要知道这4类需求的特点，来区别对待才能最优我们的产品。

• 亮点需求

对于一个产品，如果没有亮点需求，那么就很难出类拔萃，赢得大部分的用户。这类需求有点类似锦上添花（注意不是画蛇添足噢），如果没有实现，不会有太大的问题，一旦实现了这类需求，产品能让人们眼前一亮。现在公司都提倡创新，也是这个原因。从模型上我们不难看出，亮点需求对客户满意度的影响最大，但不是必须实现的。

• 线性需求

这类需求包括可用性、易用性、可扩展性。线性需求的特点是完成的越多，客户越满意。在产品中大量的功能是这一类，因此我们需要尽可能多的实现线性需求。

• 基础需求

基础需求是产品的基石，也可以说是基本法则。比如安卓应用的图标或者默认操作，如果擅自修改（尤其是逆天不符合用户操作习惯的改变），就属于破坏了用户的基础需求。从卡诺模型上可以看出，这类需求的特点是必须实现，但是不会对客户满意度有太多贡献。相反如果没有实现这类需求，客户肯定不满意。

• 无差异需求

无差异需求可以看做是可有可无。根据注明的二八法则，可以先不实现这类需求。

游戏规则

• 一组或者多组都可以（每组建议5-9人——你懂得）
• 从哪个人开始，到那个人结束
• 不允许把球传给相邻的人
• 球必须有滞空时间
• 所有人都参加
• 每个迭代2分钟
• 迭代后有1分钟做回顾和下一迭代的估算
• 一共5个迭代（可以酌情删减）

游戏手册

• 介绍游戏（2分钟）
• 介绍游戏规则（2分钟）
• 团队准备时间（2分钟）
• 估算能传递几个球
• 开始第1个迭代
• 回顾和下一个迭代的估算（1分钟）
• 重复4次
• 总结（15分钟）

计分用的表格

总结的要点

• 在游戏里发生了哪些事情？
• 哪个迭代是最好的？为什么？
• 哪个地方能体现出Scrum工作流的好处？

洞察（Insight）

• Scrum工作流=PDCA（戴明环）
• 系统都会有一个固有速度（类似于系统有上限、瓶颈）
• 只有挑战是可行的时候，才会有工作流

游戏规则的例子

游戏手册的例子

戴明环

我在QCon 2013北京上带领大家做的抛球游戏。

抛球游戏的创始人链接bor!sgloger。