最早听说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我理解就是属于这样的一种工程实践方式。
曾经的坑
看到这里大家可能会问，真的有必要搞这么复杂吗？嗯，回答是看情况。如果你所在的团队任务是固定分配的，相对稳定，需求清晰，那么完全不需要，可以跳过下面的部分了。如果你的团队任务并不清晰，甚至总是出现一句话需求。那么你应该会有如下的体会：
- 团队每次迭代的压力大。抱怨需求太粗糙。有重做的风险。
- PO或者BA的压力大。要回答大量团队提出来的细节问题，一旦回答错误或者延误，迭代延期的责任就压在了他们身上。
- 团队养成了依赖的习惯，等待PO/BA给出全部清晰的内容。对业务设计和讨论参与度低。
- 拆分研发任务的工作落在了Tech Lead的身上，Team只是接受任务，拆分是否合理正确压力都在Lead自己身上。Lead工作繁忙且压力巨大。
- #3，#4本来Team希望减少自己的责任来轻松一些，但环节中存在很多单点依赖：BA/PO是否业务理解正确；Tech Lead任务拆分正确。一旦某个环节有错误，工作量仍然会重新回到Team自身，回到上面#1，形成了恶性循环。
新的尝试
下面我做的一次ATDD的尝试，步骤如下：
- 预定一个小时的会议室，有白板，马克笔，便利贴。
- 和Lead和PO在Backlog中选择一个“一句话需求”作为尝试的案例。
- 在会议一开始宣读需求。开始询问Team是否当前需求可以下笔进行开发？如果不能那么哪里需要澄清。
注意：这个过程中Tech Lead尽可能不要说话，只是听就可以，或者记录自己的想法。让Team和PO充分交流。 - 循环#3的澄清过程，直到全部澄清。可以使用一个小约束来限定团队沟通方式：具体形式是每一次澄清需求的时候按照特殊的格式(Gherkin)形式写出来。
Gherkin的格式是：Given(前提条件)，When(操作步骤)，Then(验收标准)。
注意：强制让Team用Gherkin格式来和PO澄清需求，主要的目的是让大家避免讨论技术细节，只是聚焦到需求澄清到否足够开始动手做的水平就行。 - 用便利贴记录所有讨论中产生的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。
如果您有疑问或者想法，欢迎在我的公众号留言交流。
