ATDD的小妙用

在项目中引入工程实践以提升遗留系统改进工作的质量，团队成员面临不熟悉代码和业务逻辑的挑战。

遇到的困难

• 团队需要改进现有功能并增加新功能，但代码的结构复杂，难以理解业务逻辑。
• 代码缺乏业务描述性，使得开发人员难以获取业务的全貌，无法进行进一步开发。
• 如果代码存在不准确性，会误导新的开发人员，使他们偏离正确的开发路径。

采用的办法

• 组织PO、QA、Dev参加1小时左右的会议，不涉及代码，而是在屏幕上操作应用程序，以用户角色进行实际操作。
• 各方基于对需求的理解，使用验收标准(AC)的形式来演示和介绍需求，讨论直至达成共识。
• 会议产出的AC包括现有和新业务逻辑的AC，并附有界面截图，作为参考。
• 基于AC，开发人员重新审视代码并制定重构或修改方案。

注意事项

• 使用Gherkin语句来聚焦业务层面讨论，避免讨论范围扩散。
• 会议中只关注业务逻辑，不涉及代码逻辑。
• 结合实际系统操作，使用角色扮演来讨论，使讨论更加直观。

通过这种方法，团队成员能够从业务角度而不是代码结构来梳理逻辑，这实际上是接受测试驱动开发(ATDD)过程的一部分。通过AC的梳理，业务逻辑结构变得更加简单和直观，显示AC在业务方和团队间起到了粘合剂的作用，大大提高了效率。作者鼓励践行敏捷实践，分享更多经验，并欢迎关注其公众号进行交流。