上次分享团队进行的验收测试驱动开发(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的粒度相对平均且可以在一天内完成。此外还有如下的一些好处：
- 团队内部知识分享。
- 形成业务逻辑的集体记忆。而不会依赖于某几个人。
- 逐步形成用户思维。
- 自然进行用户故事的拆分。而且是纵向切分。
- 方便形成团队吞吐量——AC个数。
- 团队不再惧怕一句话需求。
践行敏捷实践，让工作变得更美好。欢迎关注我的公众号，交流落地经验。
