实战 TDD (2): Tasking to Action

B站视频版

如果给我一个小时来砍树，我会先花 20 分钟来磨刀。

​ ---- 林肯

在上一篇内容 TDD 实战（1） 通过一个案例来展现了 TDD coding 的过程，编码之前首先要做的事情就是确保已经准确理解了需求。TDD 也不例外如果需求不能获取准确后续用什么实践都无法完全交付想要的。

工作中有 BA 人员来挖掘需求，DEV 将业务需求转化为软件功能，其中 Tasking to Action 是开发之前的利器，也是 TDD 过程的第一步。

Tasking to Action 能够帮助开发人员确定自己理解了业务需求，并将需求分解为若干个可以小步实现的任务，工作中在做卡之前，首先就是对要做的卡进行 Kick-Off，Kick-Off 的过程中 DEV、BA、QA共同进行的，DEV 可以针对分解之后的Tasks 与 BA、QA 达成用户故事卡理解上的共识，并调整 Task，从而确保需求的实现是建立在共识下的。

因此，Tasking to Action 能够很好的将质量验证前置，并为质量内建提供帮助。

01，如何进行Tasking to Action？

当解决一个复杂的问题的时候，你会怎么做？是不是先将复杂的问题进行拆解，生成一个个简单的问题，当一个个简单问题解决，那个复杂问题也就解决了。

Tasking to Action 就是对问题进行拆解的过程，将业务需求分解为有上下文、有行为、有结果的若干个 Task。每个Task 都是简单的、能够快速实现的、代表具体场景的。

在做 Tasking to Action 的过程中发现遗漏的、不确定的需求，User Story 的上下文以及涉及到的边界，能够帮助我们更加准确的进行Tasking 过程，避免遗漏。

Tasking 之后的生成的 Tasks 我们可以通过 BDD 的方式来进行描述。

02，Tasking to Action 使用 BDD

工作中我们要描述清楚一件事情，通常会介绍四部分内容：

什么背景下?

遇到一个什么问题?

我的解决思路是什么?

这件事的主要干系人是谁?

通过这样的格式我们能够轻松的完整的让其他人了解清楚的来龙去脉。

BDD 提供了一种良好的描述信息的格式，能够清晰的描述一个用户故事的某个场景的上下文和结果。就是我们常说的 Given、When、Then。它们代表了不同的信息Context、Event、Outcomes，如下图所示是一个摩托车打火的过程。

为了进一步说明，我们举个例子，需求如下