ATDD 的小妙用

最近在和一个团队的小伙伴们一起，尝试在项目中应用一些工程实践，从而提高项目的完成质量。因为项目是对一个遗留系统做改进，而小伙伴们大部分是从别的团队重新组队过来的，所以遇到了一个很普遍的问题——对代码不熟悉；对业务逻辑也不熟悉的小尴尬。今天分享这期间我们进行的一个小尝试。个人感觉还不错，希望带给小伙伴们启发。

遇到的困难

• 背景是希望改进一个已有功能的逻辑，增加新功能。

• 开发看 code 的结构对已有业务逻辑的梳理，结果越看越一头雾水，像递归调用的函数一样，一层一层越看越深入。只见树木不见森林。

• code 本身的特点，并不具备业务描述性，从而导致开发，就算读懂 code，也无法获得对应业务逻辑的全貌。更无法进行进一步的业务开发。

• 如果 code 以往的开发就带有不准确性，那么从 code 的角度反而会误导新的开发人员，离正确的道路越来越远。

采用的方法

• PO、QA、Dev 一起参加一次 1 小时左右的会议。

• 不看代码。大家对着一个屏幕，打开当前的应用程序。对需要修改的业务逻辑部分，用具体的用户角色来操作应用。

• PO、QA、Dev 基于自己当前对需求的理解，用 AC(验收标准)的描述形式来演示并介绍自己对需求的理解。

• 充分讨论，直到三方达成一致，之后产出物是一组 AC(既包括已有逻辑的 AC，也包括新作业务的 AC)。而且可以带着界面截图，方便大家回顾。

• 基于形成的最终 AC，Dev 重新看 code 并制定重构或修改方案。

注意事项

• 一定要用 Gherkin 语句。它的好处可以参看我之前的一篇文章<一次ATDD的团队实践>
  

• 会议期间不考虑代码逻辑，只关注合理的业务逻辑。

• 最好是结合已有系统的操作，并使用 Role 带入使用场景讨论，直观形象。

下面是同一个开发小伙伴，经过两种方式后的梳理产物的对比：

1. 从 code 梳理出来，当前部分的业务逻辑：(错综复杂的网状关系让人眼花缭乱)

2. 通过 AC 梳理出来，当前部分的业务逻辑：(树形结构简单直观)

看到这里小伙伴们可能已经发现，这种 AC 的梳理就是 ATDD 的过程。没错，其实一开始我也没想到会是这种结果，当时只是实在无法理解 code。从开发小伙伴梳理的脑图就能看出来，他当时的内心是多么的凌乱。所以索性不看 code，带着他从业务角度重新入手，没想到结果竟然更加简单的结构。这也是 ATDD 的一个小妙用。不禁感叹 AC 真的是业务方和团队之间的粘合剂，用好了事半功倍。

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

【欢迎关注我的博客】