一次ATDD的团队实践

ATDD的初识与背景

ATDD（验收测试驱动开发）最早是在Ethan Huang老师的CSPO课程中接触到的，作为BDD（行为驱动开发）的一种实践形式。它的核心思想是通过业务左移，编写可自动化的业务脚本，使测试更早形成，从而提升团队对需求的理解和开发效率。

ATDD与BDD概念解析

TDD（测试驱动开发）是一种开发实践，旨在通过设计测试用例让代码逻辑在编写前明确，减少逻辑错误。BDD则希望在此基础上进一步左移到业务层，通过更易理解的业务脚本（如Cucumber）形成测试。ATDD作为一种实践方式，帮助团队以类似TDD的形式构建更清晰的需求。

团队面临的问题

在需求不清晰的团队中，可能面临以下困境：

• 迭代压力大，需求粗糙导致高重做风险。
• PO/BA压力大，需回答大量细节问题，错误或延误可能导致迭代延期。
• 团队依赖PO/BA提供完整需求，参与讨论度低。
• Tech Lead独自承担任务拆分压力，工作繁忙且易受单点依赖影响。

这些问题形成了恶性循环，最终影响团队效率与成果质量。

ATDD的实践尝试

作者尝试通过ATDD改善团队协作与需求澄清流程，具体步骤包括：

1. 召开一小时会议，准备白板、便利贴等工具。
2. 选择“一句话需求”，宣读并询问团队是否能够直接开发，澄清模糊点。
3. 通过循环澄清需求，使用Gherkin格式（Given-When-Then）避免技术细节讨论，专注于需求是否足够明确。
4. 用便利贴记录讨论得出的验收标准（AC）。

经过约40分钟的讨论，团队从“一句话需求”中拆分出21条AC，显著提升了需求理解的深度与质量。

实践体会与优势

通过共创式头脑风暴，ATDD实践带来了以下积极影响：

• 团队参与更多，增强主动性与责任感。
• 减轻PO/BA压力，团队贡献更多新思路。
• 促进业务与技术知识分享，减少信息单点依赖与丢失风险。
• 提高团队应对不确定需求的能力，形成高质量BDD测试脚本。
• 拆分出的AC粒度均匀，符合INVEST原则，便于实施与追踪。

实践建议与技巧

为了更好地实施ATDD，作者提供了一些建议：

• 避免需求澄清时陷入技术细节讨论，使用Gherkin格式拉回焦点。
• 让团队成员扮演PO/BA角色，激发参与度并提供新视角。
• 通过拆分AC实现用户故事的细粒度划分，替代传统Story Point统计迭代吞吐量。

总结与交流

ATDD实践不仅优化了需求澄清流程，还推动了团队协作与知识共享。如果您有相关疑问或想法，欢迎在作者的公众号留言交流。

如何有效改进回顾会议（下）？

了解更多

Bruce Talk

查看原文：一次ATDD的团队实践

文章来源：

Bruce Talk

扫码关注公众号