行为驱动开发（BDD）认为软件开发是现如今企业运营的根本，有助于改善企业利益相关者和软件开发者之间的沟通。Kevin Smith在其一篇最近的博文中介绍了他使用BDD的工作经验。

在进行了多年的敏捷项目后，Dootrix公司的技术总监和联合创始人Smith注意到了敏捷开发的一些共同缺点：

由于用户故事越来越多关注于用户以及他的软件需求，这样很容易让开发者忘记商业需求。 用户故事生命周期较短，因此很容易忘记一个应用程序的整体规范。 由于用户故事生命周期较短，基于用户故事的验收标准往往质量较低。 缺乏可以发现并解决业务问题的敏捷工具。 测试驱动开发（TDD）是目前常用的一种手段，但是往往这些测试仅仅验证了细节，而没有验证功能是否正确的实现了。

根据Smith过往的经验，BDD可以帮助解决这些问题，尤其是在引入实例化需求（Specification by example）以及影响地图（Impact mapping）等概念的时候。

Smith曾经实现了一个简单的改变，他将用户故事转换为一个更加偏向于BDD风格的形式，他认为通过这样可以让人们将关注点转移到商务价值上，并更多讨论它：

为了<实现利益>，作为一个<角色>，我需要<功能>。

BDD强调要使用具体的用例来减少歧义。这些用例有助于建立共同的认识，并找到丢失的功能。当编写验收标准时，可以用正式的语言Gherkin来写这些用例，并可以基于这些用例进行自动化测试。

构建软件的一个常见的挑战是如何创建正确合适的文档。由于BDD关注于用用例来解释行为，因此可以用于自动化生成文档。这个文档与实际实现的功能同步，我们通常称其为活文档。

虽然Smith认为BDD给我们带来了很多方便，但它还是存在一些潜在的缺点值得我们的注意：

BDD没有涉及到用户界面，所以我们还需要使用原型和其他的工具来保证界面完好设计。 有很多现成的工具可以测试编写的用例，但缺少可以管理运行哪个测试、何时运行的工具。 它很难开发一个很好的自动化测试套件，在短期内它较为昂贵。

Smith最后指出BDD还是一个新兴的想法，因此缺乏如同敏捷方法一般的生态环境。不过他相信这是帮助人们在搭建软件的时候更好沟通的一个好方法。为了再一次激起人们对BDD的关注，他引用了BDD的作者Dan North的一句话：

BDD是促进合作并通过实例探索的一大选择。

本文转自d1net（转载）