最近一周犯了一个常见的错误，操之过急和揠苗助长。也与我一向宣导的原则相违背。在这里分享出来，一是引以为戒；二是帮助ScrumMaster们避免掉进相同的坑。
公司基于业务方面和技术层面考虑，决定启动一个新项目。
业务方面的目标: 通过这个项目把一个业务产品化，用于支持多个产品的某一个共同的关键业务，提升交付能力和减少重复工作。
技术方面的目标: 希望为公司的技术架构探索一个新的方向，微服务化，提升公司的架构水平；为其他团队提供一个有单元测试、一致代码规范、良好的工作过程实践的范例。
两个目标都达成方能算是真正的成功。
这个项目成立了一个Scrum团队，团队内部的人员要求由我担任ScrumMaster来引导他们。团队的成员之前已经在另一个团队与我有过一段时间的合作(这一点恰恰是我自己坑自己地方)。
正式启动之前，我都会帮助团队认识，什么是ScrumMaster，ScrumMaster不做什么，做什么。Scrum中的各项工作，是哪些角色的范围。让大家达成一致的认知：
- ScrumMaster是没有权力的角色。
- ScrumMaster不是保姆，什么都干。
- 交付是团队的范围，不是ScrumMaster的。
- 质量是团队的范围，不是ScrumMaster的。
- 会议是团队的范围，不是ScrumMaster的。
.....
为了限制强技术背景型ScrumMaster(我)，不自觉的干涉团队，我给团队一个重要约定, 也是对自己的一个紧箍咒:
- 团队有权决定做什么，ScrumMaster无权强迫与干预的团队决定。
- ScrumMaster可以给出建议，团队决定是否采纳，甚至可以当场怼回ScrumMaster "你在胡说八道, 回去喝茶吧"。
- ScrumMaster 承诺为项目过程中的一切技术实践问题提供帮助和培训和解决。
- 如果团队采纳ScrumMaster的某项建议，ScrumMaster 必须负责兜底。
- ScrumMaster 负责给团队提供一个安全的空间，挡住各种干扰。
- 团队对项目的结果负责。
接下来便是和团队形成工作约定, 并且确保每一条都当场认可的。
团队达成如下工作约定
PO 编写用户故事
团队编写验收标准，PO负责审核
用户故事满足DoR方可进入Sprint
DoR:
- 故事粒度满足 INVEST, 可实现故事
- 故事已经拆解AC，并通过PO审核确认
- 必要时，附上原型图，设计图
团队交付必须满足 DoD
DoD:
- 故事的每一个AC都必须已实现，并验证通过。开发人员为首要验证人员。
- 至少在API级别提供相应的测试用例代码
Sprint 1的开始时间为下个星期一 (如果我记错，请纠正)
Sprint 周期为两周，10个工作日。
Stand Meeting 为每日上午 10:20
团队尝试采用物理白板来可视化状况
团队的速率(Velocity), 用 AC 数量进行度量
团队作为一个整体进行考核，不单独考核某个个体。团队需要的是内部合作，而不是内部竞争。
代码提交必须采用 Pull Request 方式, 测试代码是提交内容的重要部分之一。
提交的PR, 必须满足 ESLint 的检测，和测试用例的通过，方可合并。
陷阱之一:
约定是否能遵守，取决于成员的认知水平、能力、廉耻程度。
不会的可以问、可以学，不明白的可以动手尝试。
但是对于面对一点困难就各种理由各种现实客观因素的，告诉你这"不可能" 那"做不到"，又不愿承认自己做不到并不代表其他人也做不到，就属于廉耻问题了。
教练能解决认知、能力。解决不了廉耻问题，也不建议费力去解决。
团队的单一个体，有一些经验和技术，在公司中算不错，按照我的标准(我的标准较高)，还达不到优秀的程度。但作为一个整体运作，却属于比较初级。
由于上面提到的，这个项目除了有交付的目标，还有技术实践的目标。
团队连微服务的本质都不甚了解，还只是浮于从网上获取的表面的认识。DDD, Bounded Context, Aggregate, Hexagonal Architecture 是什么鬼？
由于各方的这个项目有着过高的期望。作为ScrumMaster，太过于想要确保这个团队能成功，因此发出太多声音。
如何需求拆解成一个个独立的可交付故事，如何再从一个个独立的故事中，识别出完成整个完整的业务流程的最小化故事，如何继续从最小化故事中，识别出验收标准，并通过验收标准来指定Sprint规划。确保每个sprint都能交付完整流程的交付。
图片取自 Scrum中文网 资料库中的 玩转MVP不要错过这四个案例
PO比较nice, 按照引导调整做事方式，识别出Sprint1的最小完整流程的故事与验收标准。
团队也接受编写验收标准，一开始能写的多好不是最关键的，从零到壹已经是一个值得赞扬的进步，这也为马上要做的自动化验收标准测试提供了基础。
但是在技术实践方面
-
开发团队对需求还是不够重视，还是以旧有的习惯，做到哪再理解到哪。
-
领域模型都还没整理清楚，急于交付，就投入到细节实现。
-
拿着个MVC框架就当是微服务。
-
认为质量就是测试人员的事。
-
单元测试属于不现实，甚至连接口级别的测试都不愿意写，认为这些都是属于测试人员该干的事情。
-
对 Pull Request 的作用与价值和基本使用方法不愿去了解。
-
压根不用考虑什么 Code Review。
.....
(注: 我发现许多人还不明白Pull Request为何在团队协作中非常重要、价值之大。既然如此，我也不打算免费教大家了，未来我会设计一个付费课程，专门解读 Pull Ruquest 的作用和价值，以及在工作如何用它来如虎添翼。)
作为ScrumMaster，应当引导团队自己去学会钓鱼，安安静静的喝茶，静待团队慢慢的改变。
我违背了这个原则，发现他们学不会钓鱼，操之过急，便直接给鱼他们。
人的差别在于认知高度的不同，当团队缺乏相应的高度，又不愿意不敢面对这一点的时候，直接建议他们该如何做，是没有效果的，并且会得到反弹。
幸好，我在一开始，给自己上了一个紧箍咒、保险：
我只能建议，不能强迫；团队可以决定不听，坚持自己的做法。
如果团队认为SM的一些做法，是给团队制造障碍，SM必须立刻停止。
尽管我一再强调，我只给建议，不是要求，更不是命令，不需要感到有压力，甚至可以不理会。对于不认同的，只需公开说，"我不认同", 便不会继续。
但随着我的建议越多，团队依然感到压力越大，却不敢公开表达 (勇气何在？)。正得益于上面的"保险"，一周左右，终于反弹，不承认一开始的那些约定，理由：“不现实", "不可能"。
这便造成，操之过急，揠苗助长的想把团队提升一个level，违背团队意愿的"车祸"。
出现状况，作为SM
1. 主动向团队认错，改变做法。除非团队主动求助，否则，不再直接给任何建议与解决方案。
严格遵守赋予团队的权力。团队甚至可以要求 SM 离开团队。
2. 允许并鼓励团队修订约定，把认为是障碍的约定项，统统删除。
有意思的是，居然没有一个成员敢于在这个项目组里，说出要移除哪些约定项。
好吧，既然PR是个无用的，拿掉，所有人直接push代码；
API级别测试用不愿做，拿掉，反正我是不做任何要求；
但是，有一点，只要大家没有把"团队写验收标准"这一条拿掉，我便强要求做
"自动化验收标准测试", 因为这个是我和测试人员做，不是开放团队做。
3. 同CTO与PO进行沟通，把情况说明，降低与平衡好期望。
能MVC这把刀耍好就不错了，不要奢望一步到位的微服务。
4. 分离职责：交付的要求与期望，归PO承担，PO对交付结果负责；技术实践要求和指标，归CTO； SM不需要再承担交付于技术实践的要求，回归SM的领域，对过程负责，对团队愿意改进的部分提供支持。
SM之所以操之过急的一个根源，也是因为SM承担的职责过多。
这也是团队发展的四个阶段中一个阶段，震荡期(或叫冲突期)，实际上，也正是通过这个时期，才能形成真正的规范与行为。
团队的行为模式背后有一个严重的根源: 主要成员认为 Scrum 就是竞争，成员与成员之间的交付竞争，比谁产出多，产出最少的，有给干掉的风险。所以，怎么快怎么整。
这个问题一开始就存在，我问过他们，为何有这种理解，他们说他们以前经历的Scrum团队，就是竞争模式。 即使我一再强调我们要的是协作而不是竞争，甚至专门在工作约定中单独写明这一点，并承诺在公司层面确保这一点。依然没能很好的消除他们心里的担忧。
团队与团队之间，可以有竞争。但是，团队内部竞争，只会是灾难。
回顾:
1. SM可以引导团队的节奏，但不可以试图掌控团队的节奏。
2. SM尽量避免直接给鱼。
3. SM不要太过于想要为团队保驾护航。要根据团队的个性来定，团队作死，就看着他们死。
4. SM避免去过多承担团队的职责，过度保护。
5. SM要因人而异，对于认知层级低且固执的人，不要试图去改变他。
6. 知识与经验是有价的，主动免费提供，反而不受重视。
7. 牛不喝水，你按不下它的头。强按，当心牛角。
8. 保持更多的耐心，安心喝茶，静待花开。
9. SM也会犯错, 发现了，必须第一时间公开承认错误，并纠正。不要太在意面子，越追求面子，越容易被打脸。
下一步，我会以实践的经验，设计一个付费 Scrum的分解系列课程，帮助更多的人从零到入门，从原理到如何实际操作。
