验收测试驱动开发后记

上次分享团队进行的验收测试驱动开发(ATDD)的尝试之后(感兴趣的小伙伴可以看一下我之前的文章《一次ATDD的团队实践》)，收到一些小伙伴的反馈，觉得这种时间会不会有点长，效率是不是并不高？今天分享一下我们团队在上次之后的后续情况。

第一次拆分的效果

上面的文章说到团队用 ATDD 的方式尝试对一个需求进行梳理，同一个迭代中其他功能仍然按照之前的方式进行评估和执行。在回顾会上大家一致认为 ATDD 拆分的功能最后完成度最高，质量最好。另一个角度，在迭代开始时 Team 统计了上次迭代中修改超过 1 天的 bug 对应的 Task 的数量，占比高达 54%。这说明任务开发完成后 Team 仍需要对一半以上的任务花费 2 天以上的时间进行修改，这可是一笔不小的时间开销哦，而且是可以避免的。尝试 ATDD 的这次迭代，最后发现对应的 ATDD 的 Task 基本没有出现修复拆过 1 天的 Bug，而且 Bug 数量很少。从这个尝试让 Team 感受到如果任务开发后没有 Bug，节省出来的时间做其他工作，这可是最直接的提高了团队效率。

新的收获

Team 接受了 ATDD 带来的改变。开始考虑能否缩短 ATDD 过程的时间。团队有针对性地开始练习。并在最新的一次迭代中，选择了一个更复杂的功能来尝试。按以往的工作方式，这种同等规模的 User Story 需要 1 个前台、1 个后台、一个 QA 三个人用 4 个小时进行需求梳理，之后仍然需要和 BA 来 Review 和澄清一些问题。但这种规模的 Task 以往的经验仍然会因为不确定性而产生 bug。这次的效果是：整个 Team 用上下午各 2 个小时，拆分出 34 条 AC。虽然同样是 4 个小时，区别是整个 Team 都参与了需求梳理，而不是仅仅 3 个人，同时对齐了大家理解不一致的内容，分享了这部分的业务逻辑知识。无需后续交叉 review。另一个方面，AC 天生属于端到端交付内容，和以往横向拆分的前台、后台、数据库这种方式不同。大家发现 AC 本身彼此独立。可以重新排列优先级，实现增量开发的同时无需反复测试，因为他们依赖相对少。

我的感受

很高兴看到团队开始接受 ATDD 的方式来梳理需求。这个活动是需要团队持续刻意练习的。从实际情况看，Team 一旦开始讨论 AC，点子和问题就会持续涌现出来。而停止的条件就是大家已经有信心开始做这个功能。同时会神奇的发现每个 AC 的粒度相对平均且可以在一天内完成。此外还有如下的一些好处：

1. 团队内部知识分享。

2. 形成业务逻辑的集体记忆。而不会依赖于某几个人。

3. 逐步形成用户思维。

4. 自然进行用户故事的拆分。而且是纵向切分。

5. 方便形成团队吞吐量——AC 个数。

6. 团队不再惧怕一句话需求。

践行敏捷实践，让工作变得更美好。欢迎留言交流落地经验。

【欢迎关注我的博客】