写在前面
这篇是2020.3.28敏捷四季·春季峰会分享主题的文字版本，属于后补版，后补版肯定会拿掉废话，直奔主题，也会补上当时的初衷和忘了说的内容，也算是提炼和升华吧。
标题的由来，其实就想跟大家聊聊，在做Scrum的时候，遇到了哪些坑，又是怎么样跳出来的。
首先给大家带来的是一个Scrum的实践步骤：
1.挑选一位产品负责人。
2.挑选一个团队。
3.挑选Scrum主管。
4.拟定待办事项清单，并确定优先顺序。
5.改进和评估待办事项清单。
6.冲刺规划会。
7.工作透明化。
8.每日立会。
9.冲刺评估或冲刺展示。
10.冲刺回顾。
11.上一个冲刺阶段结束之后，立即开始新的冲刺阶段。
这个内容来自《敏捷革命》的附录： Scrum实践步骤P261-265，需要的同学可以去翻翻，我今天要讲的并不是这个内容，也会有同学立马就呵呵了，并没有条件给我们“挑选”吧！
我们今天要聊的，就是没得挑的情况下，怎么整！范围只有Scrum框架3355中的第一个3，再收窄到3个角色中的前两个：PO和Scrum Master，这两个角色，足够决定你的Scrum团队的生死存亡以及喜怒哀乐。
先来看PO，这个小场景给我们塑造了一个看起来就是我们身边不靠谱的PO：
我们通过这个片子能看到：
1、计划会的时候，PO没有出现；
2、PO迭代过程中改AC；
3、找不到PO；
4、依然见不到PO，没跟团队在一起过。
除此之外，PO的反模式还包括：
•PO在迭代中大部分时间缺席，不能回答团队的问题。
•在迭代计划之后，改变故事的范围或验收标准。
•对于无法实现或不再有效的验收标准，缺乏改变的灵活度。
•PO不能及时对完成的故事提供反馈。
•误用取消迭代的权力。
•在迭代目标不再有效时，也不取消迭代。
那么，我们如何从这些反模式中走出来呢，让我们来看看Scrum Guide里面是怎么说的：
产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：
•清晰地表述产品待办列表项；
•对产品待办列表项进行排序，使其最好地实现目标和使命；
•优化开发团队所执行工作的价值；
•确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及
•确保开发团队对产品待办列表项有足够深的了解。
其实指南就已经给了我们完好的答案，我只是来用我自己的理解和我所辅导的团队实践，来尝试解读一下。首先，产品负责人是一个人，不是一个部门或者组织，不管所在的组织内是已经有PO团队，BO团队都好，到Scrum团队里面的PO，就是那个对我们的PB负责的人。
他要清晰地表述我们的PB，让大家都清楚，我们到底要做什么，目标在哪里？需要对咱们PB的优先级进行排序。排序最大的作用，我们使用过排序的团队都明显地感受到了，优先级不高的故事，很可能经历了2、3个迭代之后就彻底消失了；再就是PO当下想的不是很清楚的故事，还有待斟酌的故事，都可以往后排，集中团队精力关注在高价值的，明确的故事上，从源头杜绝浪费。
PO需要负责团队的ROI，PO本身就是为价值服务的，在选取进入迭代的故事的时候，需要反复验证需求的合理性，预估未来可能产生的市场价值。PO还需要给到团队一个稍微远一些的规划，建议是采用用户故事地图的形式，给团队呈现一个初步协商的发布计划暨当前的产品全景。
———————我是手工分割线———————
接下来我们来看看Scrum Master，那个决定我们是吃香的喝辣的，还是水深火热的人：
这页片子里呈现的SM：
1、自作主张安排好工作；
2、作为PO的二传手，传的一手好球；
3、压榨团队，毫无保护团队的意识；
4、没有回顾会，随波逐流，改变无力就彻底放弃了。
常见的SM反模式还有：
•允许管理者或干系人在迭代中打扰团队，让团队从事与迭代目标无关的事情或会议。
•不能支持需要帮助的团队成员。
•允许微管理，允许PO向团队分配任务。
•没有回顾会议。
•命令与控制。
SM获得解脱的终极手段依然在指南里，还是先贴图、再解读！
Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。
Scrum Master 以各种方式服务于产品负责人，包括：
•尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域；
•找到有效管理产品待办列表的技巧；
•帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
•理解在经验主义的环境中的产品规划
•确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
•理解并实践敏捷性；以及，
•按要求或需要引导 Scrum 事件。
Scrum Master 以各种方式服务于开发团队，包括：
• 在自组织和跨职能方面给予开发团队指导；
• 帮助开发团队创造高价值的产品；
• 移除开发团队工作进展中的障碍；
• 按要求或需要引导Scrum 事件；以及，
• 在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。
Scrum Master 以各种方式服务于组织，包括：
• 带领并指导组织采纳Scrum；
• 在组织范围内规划Scrum 的实施；
• 帮助员工和利益攸关者理解并实施Scrum 和经验产品开发；
• 引发能够提升Scrum 团队生产率的改变；以及，
• 与其他 Scrum Master 一起工作，增加组织中Scrum 应用的有效性。
如果一份指南就能解决所有问题，那做敏捷为什么那么的“南”，做规模化敏捷更是“南上加南”呢？！都是说起来容易做起来“一言难尽”的事。
服务于PO要怎么解读呢？教会他怎么用两张脸来面对外部的干系人和内部的团队，对外如何引导干系人、大领导的预期；对内，如何更好的诠释用户故事，用团队能听懂的语言跟团队反复沟通、确认。能做到这个程度是需要SM有一定的功力的，直播间有小伙伴问，敏捷教练的学习路径，最起码是需要先做好SM的，保证能带好自己的Scrum团队才能考虑其他，自己的团队怎么都好说，自己那套打法很可能换个团队就不好使了。
需要在Scrum的场景下教会PO包括但不限于：管理PB，写用户故事，跟团队沟通用户故事，尊重团队成员；（别笑，这个太重要了！）梳理需求，引导需求梳理过程，优先级的排序方式及原则，干系人管理，如何验收，如何用团队已有的成果管理外部干系人期望，清晰地在评审会是同步给团队用户故事的结论，根据当前PB的状态预测可能的发布计划；评审市场或潜在市场的产品使用方式，预期产品功能、潜力和市场走势……
我们再来看服务于团队，这就是SM的日常，确保团队所有人对Scrum有一致的理解，确保每个人对我们正在开发的产品有一致的理解，哪怕是拉着PO不断地跟他学习业务或是说团队对需求进行反串讲以同步对需求的认知，直到理解我们产品的价值所在。不同的组织内部，根据组织的合规性要求或是大范围的体系要求，调整团队的实施方式，比如用PO确认的评审结论来取代《业务验收测试》等。（当然，需要得到组织的许可才行。）
保护团队，一直是个值得探讨的话题，保护团队的终极目标也是为了让团队更专注，用好团队的脑子，而不需要被无端的打扰或者是陷入无穷尽的事务性工作中。
曾经见到过很多改进无力的回顾会，我对此的态度一直都是，组织的整体改进是需要量变的积累的，我们每个团队一点一点小的提升，积累到一定程度，放大到整个组织就是蜕变。
如果是一个权责对等的组织，SM能保证团队产能的情况下，是可以跟组织协商团队福利的。（具体做法就看环境了）组织也是希望看到不断突破的团队，能解决更多困扰组织整体效能的问题。
接下来是另一个维度的反模式的解读，片子贴上来就不做过多的解读了，之后会到敏捷四季在线讲堂——【敏捷的模式】专栏做详细的解读。
写在最后
Scrum是：轻量的、易于理解的、难以精通的
• 修行靠个人——我们都是终身学习者，学习我们的团队小伙伴，学习其他团队不一样的思路，学习“有趣”的做法
• 分享最佳实践——我的分享对你不见得有用，但是能给到你行动起来的启示也是极好的。
• 探明未来之路——take a bite，咬一口，不好吃吐掉换别的。
• 整装待发——做好充足的准备，在能承受的风险范围之内，开始干！
演讲中的段子我就不发了，中心思想是：
任何企业发展过程中匪夷所思的现状，在未来的某一天，回过头来看，都是必然。
2020.3.30——陈凤 写于讲完段子回好了血忍着恶心听了自己的回放后
