上篇说了流氓码农们的一些典型语录，来彰显工匠的一些价值观：
- 把测试当作开发的一部分。
- 事情要么“做完”，要么“没做完”，没有“做完了，但是”。
- Test First，往往会告诉QA哪里可能有bug，而不总是被QA告知。
- 把测试当作一种设计过程
然而，价值观或者文化不是关于如何说的，是关于如何做的。作为一个管理者或者Scrum Master，有什么实践可以让团队从流氓开始走向工匠呢？
下面结合本人经历，按顺序推荐4个：Event Storming，开发拆解Story，Example Mapping， Test Case Map Review。
DDD之Event Storming
有个常见的荒唐事实：开发团队作为解题者，往往不很清楚问题是什么。他们只负责交付产品经理提的“需求”，而不理解需求背后真正的业务问题，而那，才是我们要解的题。
让团队理解真正的业务，不是一件容易的事情。事实上，各种陡峭的“群体学习”曲线，总是软件开发面临的最大的困难。
软件研发是个学习的旅程，代码只是副产品。by 记不得名字的某外国人。
Event Storming 最大的作用之一就是加速团队对业务的群体学习，建议在一个 Epic 或者 Feature 启动之前进行。会议的产出对业务问题的一致性理解，和一个共创的 Domain Model。
让开发团队拆 Story
很多团队是产品经理（PO）来拆 Story 的，这很不高效。
我们都知道计算机算法里的“分而治之”： 解题的关键手法是分解问题。所以开发团队作为解题人，把大的 Story 分解成小的 Story，再自然不过了吧？
另外一个重要的目的是，培养团队“拆”的习惯，工匠级的程序员，无时无刻不在“拆”，拆需求，拆任务，拆类，拆函数，拆 test case。这可谓第一心法。
哪有什么天才，我只是把别人写代码的时间都用在拆解上了。by 不愿透露姓名的工匠程序员周迅。
BDD 之 Example Mapping
这个是拆 Story 的延续，每个 Story 都有一些“业务规则”，这些规则在 PO 传递给团队的过程中可能就遗漏或歪曲了，所以让开发团队针对每个核心的业务规则，举些例子出来。
这样可以进一步澄清模棱两可的需求，确保开发对需求的理解是准确的。
Test case map review
拆 Story 和 Example Mapping 一般发生在 Backlog Refinement Meeting上。Story 进入开发后，QA 继续精化那些 Example。
注意这里不是设计完整的 Test Case，而是
- 用脑图的方式列出所有的场景。
- 跟开发去 Review，大家商量好，这些场景哪些用单元测试覆盖，哪些用集成测试覆盖，哪些用手工测试。
上图是我司一个例子。这就是 Test First，本质就是以终为始。
总结
工匠级的团队首先有好的工程实践，所谓工程，就是做事的方式方法。
我们是解题人，所以我们的工程实践是：
- 理解问题 （Event Storming）
- 分解问题 （开发拆解 Story）
- 不断确定对问题的理解 （Example Mapping）
- 不断确定对问题的衡量 （Test Case Review）
代码只是这些工程实践的副产品。
后记
开头说过，这是管理者或者 Scrum Master 可以去主导的实践，它们都是非技术实践，也都是团队实践，不是个人实践。它们背后共同的原则是：反分工，反传递。共识是共创出来的，不是传递来的。
业务把问题“传递”给PO，PO把需求“传递”给开发，开发把代码“传递”给QA。这些都是敏捷的敌人，你的团队还有哪些“传递”？
备注
一种精简版的 Event Storming 玩法：
- 按时间先后，团队脑暴出重要的 Domain Event。
- 对每个 Domain Event， 脑暴它是怎么发生的？可能是谁需要做点事情( Command)，可能是另一个 Event 直接触发，也可能是 Time。
- 从这些 Event 和 Command 中识别出业务对象（Business Object）。
- 把 Business Object 归类，识别出 Aggregate （和Aggregate Root）。
- 把 Aggregate 归类，识别出 Sub-Domain，它基本上就是一个 Bounded Context，很可能对应一个 Micro-Service。
