行为驱动开发(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
评论