上篇《代码写完了，QA 可以测了》用了“流氓”码农们的一些典型语录，来说明工匠对于测试的一些价值观：

1. 把测试当作开发的一部分。

2. 事情要么“做完”，要么“没做完”，没有“做完了，但是”。

3. Test First，往往会告诉QA哪里可能有bug，而不总是被QA告知。

4. 把测试当作一种设计过程。

然而，价值观或者文化不是关于如何说的，是关于如何做的。

作为一个管理者或者Scrum Master，有什么实践可以让团队从流氓开始走向工匠呢？

下面结合本人经历，按顺序推荐4个配套实践：Event Storming，开发拆解Story，Example Mapping， Test Case Map Review。

NO.1 DDD 之 Event Storming

时间：新的 Epic 或 Feature 启动时。

人物：Scrum Team， SME， End User。

有个常见的荒唐事实：开发团队作为解题者，往往不很清楚问题是什么。

他们只负责交付产品经理提的“需求”，而不理解需求背后真正的业务问题，而那，才是我们要解的题。

让团队理解真正的业务，不是一件容易的事情。事实上，各种陡峭的“群体学习”曲线，总是软件开发面临的最大的困难。

软件研发是个学习的旅程，软件只是副产品。—— 记不得名字的某外国人

Event Storming 最大的作用之一就是加速团队对业务的群体学习，建议在一个 Epic 或者 Feature 启动之前进行。

会议的产出对业务问题的一致性理解，和一个共创的 Domain Model。

NO.2 开发团队拆 Story

时间：Refinement meeting。

人物：Scrum Team。

很多团队是产品经理（PO）来拆 Story 的，这很不高效。

我们都知道计算机算法里的“分而治之”：解题的关键手法是分解问题。所以开发团队作为解题人，把大的 Story 分解成小的 Story，再自然不过了吧？

另外一个重要的目的是，培养团队“拆”的习惯，工匠级的程序员，无时无刻不在“拆”，拆需求，拆任务，拆类，拆函数，拆 test case。这可谓第一心法。

哪有什么天才，我只是把别人写代码的时间都用在拆解上了。—— 不愿透露姓名的工匠程序员周迅

NO.3 BDD 之 Example Mapping

时间：Refinement meeting。

人物：Scrum Team。

这个是拆 Story 的延续，每个 Story 都有一些“业务规则”，这些规则在 PO 传递给团队的过程中可能就遗漏或歪曲了，所以让开发团队针对每个核心的业务规则，举些例子出来。

这样可以进一步澄清模棱两可的需求，确保开发对需求的理解是准确的。

NO.4 Test Case Map Review

时间：Sprint 开始后，Story 开发完成前。

人物：QA 和 Dev 主导。

Backlog Refinement Meeting上的 Example 不全，但足以让团队开始开发。进入开发后，QA 的任务之一是继续精化那些 Example，确保它覆盖足够的场景。

注意这里不是设计完整的 Test Case，而是

用脑图的方式列出所有的场景。

跟开发去 Review，大家讨论并确定，这些场景哪些用单元测试覆盖，哪些用集成测试覆盖，哪些用手工测试。

上图是我司一个例子。这就是 Test First，本质就是以终为始。

NO.5 总结

工匠级的团队首先有好的工程实践，所谓工程，就是做事的方式方法。

我们把开发团队定位成解题人，而不是一个盲目的执行者，所以我们的工程方法是：

1. 理解问题 （Event Storming）

2. 分解问题 （开发拆解 Story）

3. 不断确定对问题的理解和度量 （Example Mapping 和 Test Case Review）

软件只是这些工程实践的副产品。

这些实践是在预防 bug，节省的是后面找 bug 的时间。同时这些都是团队实践，不是个人实践。它们背后共同的原则是：反分工，反传递。

它们简单，但很不容易，一个团队花一年能熟练掌握这些实践，就很了不起了。原因下一篇说明。

你们的团队有哪些团队实践去保证质量？你们是基于什么原则去选择的这些实践呢？