写点什么

ATDD 的小妙用

作者:Bruce Talk
  • 2022 年 9 月 11 日
    吉林
  • 本文字数:953 字

    阅读完需:约 3 分钟

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

遇到的困难

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

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

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

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


采用的方法

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

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

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

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

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


注意事项

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

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

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


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

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


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


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


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


【欢迎关注我的博客】


发布于: 刚刚阅读数: 3
用户头像

Bruce Talk

关注

动机至善,私心了无。 2008.09.26 加入

一只程序猿,热爱新技术,痴迷于精益敏捷,现在北国春城工作。践行软件工艺,让工作因我而不同。个人博客:https://brucetalk.com

评论

发布
暂无评论
ATDD的小妙用_敏捷开发_Bruce Talk_InfoQ写作社区