一次 ATDD 的团队实践

最早听说 ATDD(Acceptance Test Driven Development)是在 Ethan Huang 老师的 CSPO 课上。是在介绍 BDD(Behavior Driven Development)这个概念的时候引入的一种实践方式。以前从没有想过纯开发的 TDD(Test Driven Development)可以应用到业务讨论上面。当时听着很新奇。不过如何能够落地，让团队能够接受它却没有多想过。恰好在去年 10 月份的时候 Ethan 老师有一次关于“不用做估算来做估算”的分享，再一次加深了印象。结合这两次学习的内容，我尝试了一次团队的 ATDD 实践。

先明确一下概念 ATDD，BDD 都是什么？

大家都知道 TDD 是一种开发实践，来自于极限编(XP)，它的主要目的是让测试左移，通过设计测试用例来形成代码的有效安全网，让代码逻辑在下笔之前明确。我们知道很多 bug 主要就是逻辑理解不准确造成的。

BDD 的思想和 TDD 类似，是希望比测试左移更进一步——业务左移 ，通过编写更容易理解的业务脚本的形式将测试更早的形成，而且是能够应用到自动化测试脚本的业务脚本(Cucumber 就是最著名的一款 BDD 脚本语言)。

了解了 BDD，那么应该谁去写？如何产生呢？这就需要通过一些工程实践，类似 TDD 的形式，ATDD 我理解就是属于这样的一种工程实践方式。

曾经的坑

看到这里大家可能会问，真的有必要搞这么复杂吗？嗯，回答是看情况。如果你所在的团队任务是固定分配的，相对稳定，需求清晰，那么完全不需要，可以跳过下面的部分了。如果你的团队任务并不清晰，甚至总是出现一句话需求。那么你应该会有如下的体会：

1. 团队每次迭代的压力大。抱怨需求太粗糙。有重做的风险。

2. PO 或者 BA 的压力大。要回答大量团队提出来的细节问题，一旦回答错误或者延误，迭代延期的责任就压在了他们身上。

3. 团队养成了依赖的习惯，等待 PO/BA 给出全部清晰的内容。对业务设计和讨论参与度低。

4. 拆分研发任务的工作落在了 Tech Lead 的身上，Team 只是接受任务，拆分是否合理正确压力都在 Lead 自己身上。Lead 工作繁忙且压力巨大。

5. #3，#4 本来 Team 希望减少自己的责任来轻松一些，但环节中存在很多单点依赖：BA/PO 是否业务理解正确；Tech Lead 任务拆分正确。一旦某个环节有错误，工作量仍然会重新回到 Team 自身，回到上面 #1，形成了恶性循环。

新的尝试

下面我做的一次 ATDD 的尝试，步骤如下：

1. 预定一个小时的会议室，有白板，马克笔，便利贴。

2. 和 Lead 和 PO 在 Backlog 中选择一个“一句话需求”作为尝试的案例。

3. 在会议一开始宣读需求。开始询问 Team 是否当前需求可以下笔进行开发？如果不能那么哪里需要澄清。

   
   

   注意：这个过程中 Tech Lead 尽可能不要说话，只是听就可以，或者记录自己的想法。让 Team 和 PO 充分交流。

4. 循环 #3 的澄清过程，直到全部澄清。可以使用一个小约束来限定团队沟通方式：具体形式是每一次澄清需求的时候按照特殊的格式(Gherkin)形式写出来。

   
   

   Gherkin 的格式是：Given(前提条件)，When(操作步骤)，Then(验收标准)。

   
   

   注意：强制让 Team 用 Gherkin 格式来和 PO 澄清需求，主要的目的是让大家避免讨论技术细节，只是聚焦到需求澄清到否足够开始动手做的水平就行。

5. 用便利贴记录所有讨论中产生的 AC，一个便利贴一个 AC。

最后我们这次尝试的澄清过程大约持续了 40 分钟。一个一句话需求被 Team 拆分出来 21 条用户 AC。Team 非常惊讶居然能有这么多 AC。

体会和感受

• 共创式头脑风暴让 Team 参与更多，更有主动性和自主性，对于功能的设计与验证更有责任心。

• 分担了 PO/BA 的业务压力，团队更积极的参与讨论了并贡献新的思路。一些 AC 是 PO/BA 没有想到的。

• 通过共创和讨论，业务和技术知识得以分享，让更多的人了解，而不是只是集中在个别人上。大家的压力会得以缓解。

• 业务逻辑形成集体记忆，因为每个人都参与了讨论，会有一定的记忆部分，减少了个别人的记忆压力，和长时间后的信息丢失的风险。

• 更能够锻炼团队接受不确定的需求，给予积极的反馈，因为不确定意味着我们可以更主动的把握内容。

• AC 的大小相对均等，并不会存在非常复杂的 AC，因为一旦复杂，团队认为无法动手实现就会自然而然的进行拆分。

• 更早的形成高质量 BDD 的测试脚本。

小贴士

• 作为 SM 或者教练，尽可能让团队避免在需求澄清时陷入技术细节的讨论。我用的方式是格式化表达方式(Gherkin 语句)。几次陷入细节讨论时要求重新描述一遍你考虑的场景，都可以容易的拉回来。

• 练习时建议选择 Team 中的一个成员来做代理 PO/BA。接受 Team 的询问，基于他对产品业务的理解，尽可能进行澄清。真正的 PO/BA 作为候补，只有在必要的时候进行澄清。这样做可以激发 Team 成员的参与度，同时换一个思考视角可能会给 PO 带来新的洞察。

• 拆分 AC 实际就是在拆分用户故事。而且最终都是满足 INVEST 原则的细粒度故事。这种方式比很多用户故事拆分都更容易让 Team 接受并使用，还能保证力度可控。一举多得。

• 团队迭代吞吐量以后可以通过数 AC 个数来代替 Story Point。

如果您有疑问或者想法，欢迎在这里回复，也欢迎到我的公众号留言交流。

【欢迎关注我的博客】