有一阵没有写博客了。周末参加了Evelyn老师的一次分享。有感而发，今天分享一些我的小思考和感受。
Evelyn老师提到作为敏捷教练和敏捷培训师，对于scrum概念的掌握标准是不同的。如果只是作为敏捷教练，为了应对企业的各种实际情况，可以不精确的理解scrum的标准、要求。例如：哪些是scrum的要求范围哪些不是。不过当你作为认证讲师的时候，就需要严丝合缝，一是一二是二，不能含糊其辞了。传道授业和实际工作存在一定的区别。要求也大不相同。
老师举了一个例子，DoD（Definition of Done）和DoR（Definition of Ready），哪一个是scrum范畴内的，哪一个不是？咋一听的时候好像觉得这不都是吗？我们平时也是这么做的呀！不过去查了一下scrum指南，确实只提到了DoD，并没有DoR。Evelyn老师提到，指南强调的是scrum框架的关键的事件、节点以及活动，而其他一些“实践”并没有在指南中，而是我们在工作中为了适应现状，变通出来的“智慧”。这些习以为常的做法常常会被误认为也是scrum的一部分了。
回顾一下工作中，我总是很开心自己找到了很多这类的智慧？而且总能通过他们绕开各种阻碍？从另一个角度思考，这么做很好的掩盖了实际的问题。例如DoD本来是需要开发Team保证迭代交付质量的一钟团队协议，但是团队觉得，这个责任需要有高质量的需求作为输入才能达到，所以提出了DoR，让PO来承担起这个责任。
另一个场景，当团队的CI\CD流水线经常由于自动化测试遇到错误case而无法通过的时候，团队因为无法拿到一个可以部署的环境而烦躁，这时候会想各种方法绕开限制，让这个带着问题的包部署到测试环境，例如增加各种新的流程或者条件，最简单的一种是开发的冒烟环境可以不用通过测试；另一种增加手动部署功能绕开自动化测试）。这样团队不用积极的寻找因其错误case的原因，是case过时了？写错了？还是有新的代码影响了以存在的业务逻辑？不需要尽快解决掉问题，而只是想让工作从开发这一侧推进到测试团队那边，让流程顺利推进。这种推进对我们的实际意义代表着什么呢？有多大意义呢？
是什么原因让我们害怕工作流程中的阻碍？暴露它还是让它“顺利”的流动下去？哪个对我们更有价值？很多敏捷框架或者方法其实都是想办法让问题透明出来，发现痛点，解决掉问题（例如：scrum暴露阻碍；KANBAN发现瓶颈）。不断的循环这一过程，让工作更顺畅和高效。不过实际工作中我们也会面临企业文化与工作环境的冲击，例如：并不想暴露问题，需要多一些流程，多一些工作挺好的。这可能也是敏捷落地时最难的部分之一吧。
大家实际的遇到的情况是什么样的呢？欢迎一起交流分享。
践行敏捷实践，让工作去繁从简。欢迎给我留言，交流落地经验。