软件项目的目的是向利益干系人交付价值,而行为驱动开发(BDD)正是为此而生。在阐述对于BDD 的看法时, Viktor Farcic 表示:BDD 能够确保在整个项目过程中,项目聚焦于为利益干系人提供的价值。
作为一位从事从瀑布模型向敏捷过程转型方面工作的软件开发者,Viktor 继续补充道:BDD 的一条准则是必须用每个人都能理解的方式来撰写需求。作为对比,在传统的瀑布式项目中,许多情况下人们都不知道或是忘记了要向利益干系人交付价值。参与此类项目的大部分人关心的是“完成各自部分的工作”,然后将工作“抛给墙那边”负责下一阶段任务的人。
在 BDD 中描述需求的关键是故事,Viktor 将故事的形式概括为两部分组成元素:介绍描述(Narrative)以及随后出现的一个或多个情形(Scenario)。介绍描述是从提出新功能要求的某个人或某个角色的角度,对功能所做的一段简短的叙述。它恰到好处地为所有涉及到的人(业务分析师、开发者、测试者等待)提供了沟通的基础,并且是以对话而不是编写描述为中心。其目的在于回答这样三个问题:价值是什么?对谁来说它是有价值的?实际特性是什么?回答这些问题后,团队就可以开始与利益干系人协作,定义最佳解决方案。
介绍描述将通过情形来进一步定义——这些情形提供了对完成的定义以及接收的标准,用来确认针对介绍描述进行的开发,其输出的成果能够满足预期。
对 Viktor 来说,尽管介绍描述拥有某些传统需求的特性,但他相信依旧存在一些非常重要的不同。其中之一在于以下二者之间的区别:重视口语化和持续沟通,与使用可能非常不精确的语言。另外一点不同则是重视使用特性来描述功能,而不是使用大量如下形式的文字陈述:“该系统应该……”——后者往往会妨碍读者理解项目的整体视图和真正的目标。
最后,Viktor 介绍了让 BDD 向着自动化方向前进的内容——可以通过许多不同框架来执行 BDD 中的情形,例如 JBehave 、 Cucumber 、 SpecFlow 和 Jasmine 。他的建议是分三步走来实现 BDD 自动化:
- 创建标准化步骤的库,以帮助将情形从实际代码中分离,从而简化非开发人员编写故事的工作。
- 在更高的业务层面将这些步骤整合,以便分析师和其他类似角色更好地理解。
- 使用实例表(example table),以便同一个情形可以被执行若干次,并在每次执行中配备不同的参数集。
Victor 的建议是,从第一阶段入手,直到采取足够的措施以支持创建第一个情形后,再继续落实后面两阶段的内容。
Dan North 在 2006 年开发了 BDD,并撰写了一份入门简介,以及在BDD 中如何编写故事。
实例化需求(specification by example)是一种与BDD 密切相关的需求定义方法。
查看英文原文: Behaviour-Driven Development: Value through Collaboration
评论