4个实践，开始流氓向工匠的转型之路

上篇说了流氓码农们的一些典型语录，来彰显工匠的一些价值观：

• 把测试当作开发的一部分。
• 事情要么“做完”，要么“没做完”，没有“做完了，但是”。
• 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 传递给团队的过程中可能就遗漏或歪曲了，所以让开发团队针对每个核心的业务规则，举些例子出来。

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

Example Mapping

Test case map review

拆 Story 和 Example Mapping 一般发生在 Backlog Refinement Meeting上。Story 进入开发后，QA 继续精化那些 Example。

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

1. 用脑图的方式列出所有的场景。
2. 跟开发去 Review，大家商量好，这些场景哪些用单元测试覆盖，哪些用集成测试覆盖，哪些用手工测试。

Test case map.png

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

总结

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

我们是解题人，所以我们的工程实践是：

1. 理解问题 （Event Storming）
2. 分解问题 （开发拆解 Story）
3. 不断确定对问题的理解 （Example Mapping）
4. 不断确定对问题的衡量 （Test Case Review）

代码只是这些工程实践的副产品。

后记

开头说过，这是管理者或者 Scrum Master 可以去主导的实践，它们都是非技术实践，也都是团队实践，不是个人实践。它们背后共同的原则是：反分工，反传递。共识是共创出来的，不是传递来的。

业务把问题“传递”给PO，PO把需求“传递”给开发，开发把代码“传递”给QA。这些都是敏捷的敌人，你的团队还有哪些“传递”？

备注

一种精简版的 Event Storming 玩法：

1. 按时间先后，团队脑暴出重要的 Domain Event。
2. 对每个 Domain Event， 脑暴它是怎么发生的？可能是谁需要做点事情( Command)，可能是另一个 Event 直接触发，也可能是 Time。
3. 从这些 Event 和 Command 中识别出业务对象（Business Object）。
4. 把 Business Object 归类，识别出 Aggregate （和Aggregate Root）。
5. 把 Aggregate 归类，识别出 Sub-Domain，它基本上就是一个 Bounded Context，很可能对应一个 Micro-Service。