在 2015 年 QCon 伦敦大会上， Cucumber Ltd 创始人 Matt Wynne 讲述了 BDD 如何利用敏捷在团队作战的优点解决缺乏预见性、沟通和质量这些常见问题的。
在与一些需要帮助的公司一起工作中，Wynne 发现他们经常会受困到上述问题之中，因为他们误解了成为敏捷、达到敏捷和某些像货物崇拜形式的敏捷实践的区别。
为了抚平常见的痛点，Wynne 提议找回那些最终丢失的敏捷特性。当团队开始将软件以组件为单位构建时，预见性就会增加；当团队在每天的基本事务中都有合作时，沟通就会更好；当技术规范能被贯彻时，质量就会提高。
接着，Wynne 从其自身角度解释了为什么 BDD 可以做到这点。
维基百科上说，
“行为驱动开发（BDD）是从测试驱动开发（TDD）中产生的软件开发过程。行为驱动开发结合了 TDD 的一般方法和原则，使用领域驱动设计和面向对象的分析和设计思路，为软件开发和管理团队提供共享工具和软件开发合作的共享过程。”
Wynne 专注于他自己对使用者预期行为上的定义。
“BDD 实践者使用对话、具体实例以及自动化测试，探索、发现、定义并得到预期的软件行为。”
他使用不确定性的锥图展示了该如何从不确定性最大的探索阶段出发，获得尽可能多的确定性。Wynne 祭出了探索之旅的三大法宝：对话、具体实例和测试驱动开发。
对话很重要，因为软件是人做出来给人用的。每个人都有一个独特的视角，而每个视角都很重要。有一种技术叫发现工场（discovery workshop），可以用来加强对话，每个用户故事都有一个“锵锵三人行（three amigos）”工场来发现场景。
具体实例很重要，让人们觉得合乎情理，具体实例植根于问题领域，有利于构建通用语言和分享事实的起源。
测试驱动开发是必选的，因为自动化测试是警示灯，不要忘记倾听测试在说什么。
Wynne 在演讲的最后出于某种原因追溯了 TDD 的根源：
“夫无代码整洁之道，岂可保持敏捷；
若无重构，焉有代码整洁之道；
然非自动化测试，何有重构哉”
查看英文原文： http://www.infoq.com/news/2015/03/bdd-save-agile
感谢夏雪对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论