初创的敏捷团队采用行为驱动开发共创用户故事

如果说TDD是让我们正确地做事，那么BDD就是让我们做正确的事。

在原本的计划中，2021年农历新年前发布另一篇文章，还是应了计划赶不上变化的这句老话，也算是体现了敏捷的价值观，希望本文对初创敏捷团队有一定的帮助。

维基百科的解释

行为驱动开发（英语：Behavior-driven development，缩写BDD）是一种敏捷软件开发的技术，它鼓励软件项目中的产品负责人、开发者、QA和非技术人员或干系人之间的协作。BDD最初是由Dan North在2003年命名，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。BDD介于业务领域和开发领域之间，如下图的位置。

行为驱动开发强调使用领域特定语言描述用户行为，定义业务需求，使需求分析人员、开发人员与测试人员进行沟通的有效方法。领域特定语言，相比自然语言更加精确，又能以符合领域概念的形式满足所谓“活文档”的要求。

行为驱动开发的核心在于“行为”。当业务需求被划分为不同的业务场景，并以“Given-When-Then”的形式描述出来时，就形成了一种范式化的领域建模规约。编写领域特定语言的过程，其实就是不断发现领域概念的过程。因此，团队采用BDD共创用户故事，最重要的产出不是文档，而是提供了团队交流的平台，并在其约束之下完成了领域建模。由于团队的不同角色都参与了这个过程，就保证了领域模型的一致性与准确性。

敏捷开发中的理解

行为驱动开发是一种敏捷开发的技术，想必大多数同学都对敏捷开发领域中另一技术，测试驱动开发（Test-Driven Development，TDD）较为熟悉，BDD是建立在测试驱动开发基础之上。BDD的重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识。行为驱动开发人员使用混合了领域中统一的语言的母语语言来描述他们的代码的目的，通过用自然语言书写团队成员（业务、产品、开发、测试等）都可以读懂的实例。这让开发者得以把精力集中在代码应该怎么写，而不是技术细节上，而且也最大程度的减少了将代码编写者的技术语言与商业客户、用户、利益相关者、项目管理者等的领域语言之间来回翻译的代价。

敏捷团队面临的交付困境

在软件项目中涉及多人紧密协作，由产品业务讲解功能需求，开发负责代码实现，测试保证软件质量，高质量的沟通对项目成功至关重要。如果在一个项目中业务人员用自己行话，开发人员用技术语言、技术思维去理解业务，在沟通过程难免出现分歧，开发人员就可能按自己的理解去评估和实现了一个错误的功能。

理解需求

敏捷开发团队围绕产品的沟通，大部分都是为了理解需求，从而在业务、开发和测试之间达成共识。用户故事关注的是业务需求而不关注技术，系统业务专家、开发者、测试人员一起合作，分析软件的需求，然后将这些需求写成一个个用户故事。并且，首先开发和发布业务关键的用户故事，尽早为最终用户提供业务价值。

评估与计划

需求理解不一致，验收标准不清晰，就会导致用户故事评估工作的困境，开发人员对故事点的评估就缺少依据。有了上一步需求理解的统一，开发团队与产品负责人在工作量评估上有更坚固的共识，从而管理层在产品计划上，也会有更好的预见性和期望。

测试工作

这样的用户故事可以直接应用到测试中，作为测试的标准文档。我们在做单元测试 时，经常是针对某个函数，或是某个类进行测试，但是被测函数或是被测的类是可能经常变化的，我们的测试案例也需要经常性的随之变化。然而，用户故事描述的是软件的整个系统行为，几近于需求文档，可变性大大减小。因此，测试案例不需要做太大变化。同时，这样的测试案例最贴近于需求，贴近于实际的系统行为。

产品相关文档

经常看到产品在不断的推进，当干系人问起文档的时候，我们却难于启齿。不是因为我们不重视文档，而是我们更重视交付？如果必要的产品说明文档也没有就是有点走极端了。基于BDD 的用户故事，使用几乎近于自然语言的方式描述了软件的行为过程，因此，可以直接作为软件的需求文档。

团队基于BDD共创用户故事

用户故事User Story

用户故事是从用户的角度来描述用户渴望得到的功能。

一个好的用户故事包括三个要素：

• 角色：谁要使用这个功能
• 活动：需要完成什么样的功能
• 商业价值：为什么需要这个功能，这个功能带来什么样的价值

验收条件Acceptance Criteria

验收条件就是一系列可以接受的验收条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和干系人接受。

验收条件可作为验收测试用例的具体例子。这也是我们常说的实例化需求，让抽象的需求变得具体和可测试。

一个用户故事包含若干个验收条件，包括正常场景与异常场景。

场景中的Given…When…Then…实际上就是设定该场景的状态、适用的事件，以及场景的执行结果。

通过这样的用户故事描述和场景设置，基本就完成了一个完整测试的定义。

验收条件的作用：

1. 以用户的视角表达业务交互过程
2. 为PO与用户的需求理解上提供场景化、具象化的沟通
3. 有助于用户体验友好性的识别和改进
4. PO与团队需求共识的标准和记录
5. 可视化一个用户故事的粗细粒度
6. 开发与测试对功能实现与质量的共识
7. 需求完成边界的限定
8. 比单纯故事点更为直观的工作估算标准
9. 活文档，用户手册(帮助FAQ)的素材
10. 更公平透明的甲乙方的定价标准

举个例子

在农历新年，中国人的习俗中会有很多活动，如果把过年当做一个产品交付，那么会有很多Epics或Feature，过年三十就是其中一个大故事。那么我会基于BDD，写这么一个用户故事（当然，我也可以拆解出一个更小的用户故事：和家人一起吃年夜饭）：

基于BDD写用户故事的优点

BDD为敏捷开发流程提供了许多优势。 BDD 提供业务关键功能，通过高效的协作和沟通推动产品成功。

提高开发效率

帮助开发人员、测试人员与PO对需求的理解在同一个平面上，帮助团队快速构建和交付更多有价值和高质量的产品，减少返工和修改可降低维护成本。

提高测试效率

帮助测试人员准备测试用例，并进行符合验收条件的用户故事测试。

正反馈循环

以用户故事为中心，用验收条件填补PO-开发-测试之间的认知鸿沟，进行需求拉通与协作对齐。由于所有团队都对应用程序有共同的理解，因此开发人员可以更快地获得反馈，以增强应用程序并走上正轨。

用户体验

从用户角度定义功能使设计人员和开发人员能够从最终用户的角度进行思考，以解决用户难题。 创造了内在的业务价值和增强的客户体验。

文档生成

帮助PO在日常的迭代开发中逐步完善整理产品需求，提升实战性用户故事和验收标准的编写技巧。组织产品PRD文档的信息来源。

写在最后

通过上面的了解，我们知道了行为驱动开发很大意义上是一个PO、开发、测试共创的一个行为。同时也是一个自然而然的过程，我们可以使用行为驱动开发的人类语言描述方法来编写我们的用户故事。行为驱动开发，还需要打破传统的魄力，因为之前几乎没有人会告诉你用户故事写的可以跟逻辑代码一样，作为从代码到需求的桥梁。当你习惯BDD，编写用户故事会变得非常好玩。行为驱动开发，可以使你的测试更加贴近实际的用户行为，从而找到系统的问题所在。

如果你要做完整BDD的话，可以看下面的彩蛋部分。祝各位新年快乐，万事如意！

彩蛋：Gherkin简介

1、Gherkin语言使用的是主要英文关键词Feature、Scenario、Given、When 、And、Then和But等，这些关键词可以转换成中文关键词，场景、加入、当、那么等。根据用户故事，需求人员或测试人员使用Gherkin语言编写好测试场景的每个步骤，Cucunber框架会一步一步地解析关键词右侧的自然语言并执行响应的代码。

关键词的含义如下：

1）Given：用例开始执行前的一个前置条件，类似于编写代码setup中的一些步骤

2）When：用例开始执行的一些关键操作步骤，类似单击元素等

3）Then：观察结果，就是平时用例中的验证步骤

4）And：一个步骤中如果存在多个Given操作，后面的Given可以用And替代

5）But：一个步骤中如果存在多个Then，第二个开始后面的Then可以用But替代

2、使用Gherkin编写测试场景的操作步骤，并将执行步骤保存在以.feature为扩展名的文件中，每一个.feature文件都要开始于feature（功能），feature之后的描述可以随便写，直到出现Scenario（场景）。一个.feature文件中可以有多个Scenario，每个Scenario包含步骤step列表，步骤使用Given、when 、And、Then等关键词，Cucumber对这些关键词处理是一样的。

—

END

感谢你阅读本文，希望能在评论区学习到大家的经验和想法~

如果对相关内容感兴趣可以关注我的公众号：捷伴行Agile。会有更多更及时的内容与君分享。

• 敏捷方法
• 用户故事
• 行为驱动开发