行为驱动开发：通过协作传递价值

软件项目的目的是向利益干系人交付价值，而行为驱动开发（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