1.角色定位：

    a. SM不是安静且无用的开发人员/团队秘书，并且SM不能认为自己是团队秘书，这样的SM没有价值，是浪费时间浪费钱的，不如换成项目经理。

    b. SM不能兼任团队中的其他角色。因为SM做的是重要但不紧急的事情，如果和其他角色结合，SM的角色很容易因为在短期内看不出价值而被其他角色的当前心态，和短期内产生的价值掩盖忽略。SM必须独立出来，并且强调扩散自己的价值，增加影响力。

    c. SM的目标是建立一支优秀的高效率的团队，这只团队是自组织的，拥有高积极性。通过团队的建设，将这种变革扩散到组织当中，形成自组织的组织。除此以外的任何目标都会让SM的角色失去价值直到被忽略。

2. 职责：

    a. 鼓励团队承担责任，支持团队的单一身份和目标

    b. 鼓励透明度，实现协作

    c. 通过鼓励团队接管活动，移除障碍

    d. 了解敏捷和Scrum思维，不断教育自己

    e. 保持敏捷和Scrum的价值，帮助别人理解并遵循Scrum

    f. 在需要时保护开发团队

    g. 引导Scrum会议

    h. 帮助团队变得更有效率

3. ScrumMaster自己应该不断改善：

    a. 聆听他人---掌握真正的现实情况和真正的问题所在

    b. 共情---梳理团队情绪，避免失败的变革

    c. 治疗关系 --- 指修复团队成员（包括PO）之间的关系？

    d. 作为领导者的意识和自我意识---自我意识即我有能力跳出环境主动做出选择，而不是被环境逼迫去做某事。

    e. 使用说服，而不是依靠职位权威

    f. 概念化---在大脑中，保持更大图景的能力，超越日常现实和短期目标去思考

    g. 先见之明---使你能够将过去的经验教训与当前的状态和未来的决策联系起来的直觉，但是在实践上，一次只领先团队一步

    h. 管家---保持开放，服务他人

    i.  承诺他人的成长？

    j. 建立共同体(community)作为可行的生活方式

4. ScrumMaster应该能： 

    a. 有经验，通过社区追踪最新趋势，了解更多Scrum的实践

    b. 嘴炮技能max，能向任何观众售卖Scrum，并且引起观众的兴趣和热情

    c. 教练和引导别人

5. ScrumMaster应该再了解一些：

    a. 业务知识， 以便引进管理产品组合的新实践，新概念

    b. 变革管理知识

    c. 技术知识：极限编程，如共享代码，简单性，持续重构，配对变成，持续集成，测试自动化或测试驱动开发

6. ScrumMaster的方法论

每天都从“我可以做些什么，让团队更容易地执行工作”开始。

首要是先观察，弄清楚现实的情况，避免臆想，被压力/情绪影响过分放大或者过度关注在自己的想法上。

现实情况弄清楚之后，要对标目标，想对策，想策略。谋定而后动。

所有的对策策略都是希望团队能够自己发现问题，团队自己接手去解决问题。

在这中间，SM常用的方法有：

    a. 教导解释Scrum思想，指导，分享经验，给予建议---前期常用，需要不断重复

    b. 移除障碍---要注意，最好是由团队自己去移除障碍，增长团队信心和积极性。否则团队可能会对ScrumMaster形成依赖。这需要ScrumMaster克制自己亲自移除障碍的冲动。

    c. 引导---会议上常用

    d. 教导 – coach，一对一交谈常用

自测：

SM技能 （1~10分）现状(2018)期待(2019)

敏捷36

引导45

教练35

技术24

变革34

业务13

经验24

解释15

7. 开发团队和Scrum团队不是敏捷组织中唯一的团队；在#ScrumMasterWay模型的所有三个层次上工作。（团队，有关系的团队，整个系统）

8. Scrum团队

团队发展的塔克曼模型：

组建期 –大家依旧保持着以前的工作习惯，呈戒备和孤岛状态，不谈合作。SM需要给大家解释，教导Scrum。

激荡期 –大家不适应Scrum，在实践中遇到各种问题导致冲突。SM需要引导，这也是变革最容易失败的时期。

规范期 –一切都达到了及格线，大家开始满足现状。SM要coach，鼓励团队去探索，继续改进。

执行期 –团队充满自信，有好奇心，童心来进行各种改进实践，自组织承担责任…SM以观察为主，必要时进行一些辅导。

改变期 –因为客观原因，有人离开有人加入，可能导致团队状态回退。SM要观察并且及时揭示这种趋势。

9. 团队中的问题

对于团队，有很多问题追查下来可能是以下这个金字塔。

缺乏信任（信息，技能孤岛），害怕冲突（制造人为和谐，避免任何难以进行的讨论），欠缺投入（不愿做出团体承诺），逃避责任（失败后强调客观因素），无视结果（提交的价值才是结果，而不是其他任何）。

必须记住，团队只有一个共同目标，为客户提供价值。而不是很多个个人目标，比如完成代码或者测试等等…

常见的团队毒素（导致以上情况恶化）：

互相指责

防御心理

鄙视

壁垒

10. 变革过程

敏捷轮盘（1~10分）现状期待

生产率  

上市时间  

团队健康  

团队协作  

与他人沟通  

持续改进  

效率  

质量  

对变革的反应  

获取客户的反馈  

结果产品交付的可预测性  

客户满意度  

    a. 有缺口才会有变革需求，如果大家看不到缺口，应该通过描绘愿景，对比和现实的差距来挖掘缺口。改革是困难的，每一次改革都应该有充分的理由和动力。

    b. 在团队中识别早期采用者，形成滚雪球效应来影响别人

    c. 由浅入深地描述自己的变革愿景，这样每个人都能理解，且获得一定程度上的支持

    d. 首先要理解和认同别人的处境，再通过反复解释让别人理解和认同你的想法

    e. 在实施过程中，要不断移除改变行为中的障碍物，让改变行为变成一件简单的事情

    f. 不断庆祝短期胜利，鼓舞士气

    g. 情况好转之后不要放松

    h. 坚持变革

11. 微观上的一些观察，理论和实践：

    a. 守破离

守，follow，持续练习，模仿，反复练习，直到这件事情变得像刷牙一样自然

破，开始思考做的这些动作背后的意义，拿着这些意义来重新审视自己的行为改变，并且调整

离，开始审视意义，审视背后的哲学基础。从自己的实际生活中学习并且开始影响别人。

要注意这三个过程在大体上是循序渐进的，但是没有严格的分界，在第一阶段的时候，可能就会有一些第二第三阶段的思考，同样，在第三阶段，可能也会有一些守的练习。

每一个阶段的时间可能都会持续很长，保持耐心，尤其在守的阶段，强调实践。

将团队作为一个系统来处理，聆听系统给你的反馈。

    b. 积极性

提高团队的积极性：当人类系统的积极性是消极性的3到5倍时，这个系统更有可能茁壮成长。

    i. 使用反思会来提高积极性

    ii. 从乐观的一面看问题

    iii. 可视化积极实践，并庆祝成功

    iv. 不要惊慌失措

    c. 引导

教导者负责框架而不是内容。框架包括会议的目的和可交付的结果。这两项在会议开始的时候就应该明确，并且和大家一起review。如果有脱离会议目的的话题出现，记在“停车场” （提前和大家说明停车场的作用）。根据实际情况也可以调整会议计划，扩大或者缩小话题的范围。

会议的目的可以用头，心，手来概括：

头：可以了解的任何东西，技能，想法，状态更新。

心：得到认可、信念、承诺或兴奋

手：创建的有形的输出，如行动规划、时间表或者清单

    d. 一些有用的技巧：

会议开始和结束时让每个人都说话，不仅让他们听，还要引发他们的思考，得到输出，在脑海中夯实会议的讨论结果。 （开始时的说话则是为了集中大家注意力，需要有趣）。例子：

如果用天气来表示你现在的心情，你是什么天气？

用一个词来总结你今天的收获。

工具：头脑风暴、列表和分组、优先排序、成对或成组工作、扩大或缩小话题范围

教练式对话中的问题列表：

你想要实现、改变、获得什么？

现在什么对你很重要?

你眼中完美的站立会议是什么样的？

什么能够很好地发挥作用？

到目前为止，你有什么进展？

为了实现目标，你需要改变什么？

对此，你能做些什么呢？

你有什么不同的做法？

你需要什么，才能停止做手头的事情?

还有什么吗？

下一步是什么？

5 Why’s (问自己和他人)

    d. 极限编程 Extreme Programming XP

        1). 持续整合-每天多次

        2). 共享代码-集体所有制

        3). 编码标准或惯例

        4). 测试驱动开发、自动测试

        5). 简单设计

        6). 配对编程

        7). 审议

        8). 将重构作为常规活动

        9). 用户故事格式

    e. 产品负责人清单？

        1). 说“不“

        2). 产品/发布章程

        3). 故事地图与旅程

        4). 行为驱动开发 （Behavior-Driven Development）

        5). 禁止估算

        6). 相对权重优先排序

        7). 影响地图

        8). 精益创业