敏捷开发者培训回顾-（CSD认证scrum开发者-敏捷技术实践）
2017年12月25日Scrum 行业报告 2017-2018摘要由Scrum联盟发布
2018年1月4日
前些日子写过一篇《一面镜子的使命》。在文章里，我倡议ScrumMaster应该把自己看作平整、干净的“平面镜”。看待问题有景深，面对问题要全面。而不要去做带有主观偏见的“哈哈镜”，也不要去做违心奉承的“魔镜”。文章反响不错，有很多人同意这个观点 。我很欣慰，也很感谢大家的支持。但我觉得有个角度还没有覆盖到。所以今天再来补充一下，貌似有点自我迭代的意思。
正如标题上说的，“你只是一面镜子”。而镜子是无法代替行为的。就好比一个人在镜子里发现自己上火了，他可以立刻用厚厚的粉底将其掩盖；他可以决定今晚不吃火锅了；他也可以忽视这个问题，什么都不做。而镜子传递“你上火了”这条信息的使命后，也就没它什么事儿了。
在敏捷开发对于角色的定义来说，ScrumMaster不负责开发和需求制定。如果ScrumMaster无法得到团队的信任，他对于问题的洞察无法得到团队的支持，那么很多改善就无法落地。（他撸起袖子自己干的情况除外）
某个团队在项目早期做自动化发布策略时承诺，用户测试环境（UAT）和生产环境（PRD）的配置是完全一致的。所以在成功发布UAT之后再发布PRD是一定不会出问题的。
生产环境发布当天，在过往一周多次发布UAT成功的前提下，发布PRD失败了。得利于强大的团队，在几个小时的排查后，最终赶在期限前半小时成功发布PRD。
排查过程中，团队发现的问题如下：
• UAT环境上某个服务的版本，和PRD环境上同服务的版本不一致
• 用来发布UAT环境，和用来发布PRD环境的用户账号权限不一致
事后，ScrumMaster表达了自己看到团队体现出过硬的能力。另外也提出了一个问题：如何能确保之前说的那样，在成功发布UAT之后再发布PRD是一定不会出问题的？因为只有确保这样，团队才有信心在以后进行频繁的发布。
对于这位镜面ScrumMaster所体察到的问题，团队会如何响应呢？
响应一：很快从成功救场的兴奋中冷静下来，开始回顾在排查中发现的问题。一位对于发布全过程很熟悉的DevOps工程师趁热打铁，草拟了一份发布准备项清单。由全队帮他补充。更让人兴奋的是，出于对“UAT和PRD的配置应该是完全一致”的追求，有人提出了取消UAT的设想，并且开始梳理和讨论可行性。
当然还可能有第二种响应：• 这很正常的，在以往的项目中都有类似的情况
• 我们都不是很有经验的DBA，没办法提前预见这些情况的 发生。即便是DBA，也可能无法提前预见的
• 绝对不可以没有UAT！！！
• 问题不是解决了嘛。我们玩的是敏捷，就应该见招拆招
第一种情况里，ScrumMaster的价值通过团队得到体现。团队认可他的存在，正面他观察到的问题。团队作为一个整体在逐步改善。第二种情况里，团队没有重视ScrumMaster观察到的问题，甚至可以说有意在回避。就好像前面提到那个上火的人在镜中看到自己时，感觉镜子会“批判”自己一样，找着各式各样自己上火的理由。更糟糕的情况可能是，有的因为不愿意看照镜子，从而搁置或毁坏无辜的镜子。
到这有人可能会说，Scrum Master是个很考验软技能的角色。对于如何表达来赢得他人认同，并积极引导（Coaching）他人采取行动，这本来就是ScrumMaster的职责。
是的，我认可Coaching技巧的重要性，或许我会在另外一篇文章里分享一二。但在这，我们不能用“想救人就得就救全世界”的道德绑架来偷换概念。有些人不会被改变，或者改变他的成本很高。而ScrumMaster不是孔圣人，不是传教士。他是站在第三人视角反应实际情况的。他只是一面镜子。而镜子不是所有人都能用得出价值的。
YY一下，实在被逼急了，或许可以变身贞子从镜子里爬出来
