行为驱动开发（BDD）能够用于改善测试人员、开发者和业务人员之间的沟通。举例来说，你能够使用以 given-when-then 方式表述的场景开发测试脚本，同时定义系统的需求。在敏捷测试日荷兰2015 大会的某场演讲中，Nick van Giessel 探讨了使用BDD 改善沟通与协作的方式。
van Giessel 说道，只有当我们把软件发布到生产环境之后，才能获得它的价值。而敏捷能够帮助你将软件更快地推向生产环境，并且更早的获得反馈。如果在开发软件时，开发者和测试人员依然无法打破壁垒，那么你只是在敏捷中继续使用传统的瀑布式开发罢了。van Giessel 表示，你必须打破不同专业人员之间这堵无形的墙，让他们成为平等的团队成员，这样才能够实现真正的敏捷。
van Giessel 说道，使用 BDD 的主要目的在于让团队中的所有人达成一致的理解。他在演讲中表示可以通过不同的方式实施行为驱动开发，例如采用实例化需求方式、举办 3 Amigos 会议（又称为实例工作间）、定义验收标准或使用 given-when-then 场景等等。这些方式都需要将团队成员聚在一起，并帮助他们对这个项目进行思考。你也同样可以使用 given-when-then 场景开发自动化测试脚本。
Nick van Giessel 认为，使用同一种语言有助于帮助人们进行沟通，并更好地互相理解，这一点对于团队来说也是一样的。比如让开发者与测试人员使用 given-when-then 场景，他们就能够描述系统的行为。这些场景也可以用于设计测试脚本，并且用于定义系统的需求。
InfoQ 有幸采访了 van Giessel，内容涉及团队之间的协作以及团队和业务人员之间的协作，如何处理沟通问题，以及行为驱动开发所能产生的价值。
InfoQ：你提到让大家使用同一种语言对于团队来说是非常重要的，对于这一点你能否详细说明一下？
van Giessel：在一个 Scrum 团队中存在着各种不同的专业，例如开发者、测试人员和业务人员。人们对于问题有着不同的思考方式，这本是一件好事，但它也会导致沟通的低效。团队工作的一个必要条件是共同的理解，而行为驱动开发描述了某个客户的实际行为。因此要通过 BDD 创建一种每个人都能够理解的语言。客户始终是最重要的人，因为是他在为你的 IT 项目买单。
InfoQ：你能否举例说明一下，你曾看到敏捷团队中出现过哪些沟通方面的问题？
van Giessel：我曾经在某些团队中工作过，这些团队中不同的专业人员之间形成了一道壁垒，他们不会在整个团队之内对问题进行沟通。这种方式好像是在 Sprint 中进行瀑布式开发一样，虽然我们尝试每两周一次交付承诺的工作，但使用的方法仍然是瀑布式的。由于这种方式延迟了获取反馈的时间，因此导致软件交付的延误与出错。当发现问题与错误的实现时往往为时已晚，因而导致了更多的返工。
InfoQ：你是怎样解决这些问题的呢？
van Giessel：我们将不同团队的成员混在一起，向他们详细地介绍了 BDD。我们打破了成员之间的壁垒，在 Sprint 还没有开始之前就邀请每个人参与到会议之中，共同讨论我们的产品。这需要投入一些时间与精力，但经过几个 Sprint 后就会显出效果。这其实是一种心态，即每个人都对最终结果负责，我们都是同一专业的团队成员，而不是泾渭分明的测试人员、开发者或业务分析师。
InfoQ：你能否分享一下你对行为驱动开发的看法？你认为它的价值体现在哪里呢？
van Giessel：本质上，BDD 是一种帮助敏捷以本来面貌进行应用的方式。它的一个主要价值（对于我这个软件测试人员来说）在于在开始创建软件之前，先从测试开始设计，并思考它的业务价值。这就减少了每个 Sprint 临近结束时团队中每个人的压力，尤其是负责测试的人的压力。与其它专业的成员进行沟通让我的工作变得更为轻松，最重要的是它给我带来了更多乐趣。
Nick van Giessel 是敏捷测试日荷兰 2015 大会中 “优秀的荷兰敏捷青年才俊”这一专题的演讲者之一。InfoQ 之前也发表过这一主题中其它一些讲座的内容，包括“ Scrum Master 如何帮助团队增加敏捷性”以及“变得更透明有助于管理工作”。
查看英文原文： How BDD Has Helped to Address Communication Problems and Improve Collaboration
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论