TDD视角下的Tasking：为何要站在业务角度？

在极限编程训练营中有学员提出一个这样的疑惑：

为什么我们在TDD的时候，Tasking要站在业务的视角？

对于这个问题，我们上演了一段连环追问的剧情。大致过程如下：

讲师：“Tasking所处的位置是哪？ ”
学员：“获取到业务需求之后，进行开发之前。”
讲师：“所以此时的Tasking肯定是跟业务相关咯。”
学员：“嗯，是的。”
讲师：“Tasking所做的事情是什么？”
学员：“梳理业务需求，拆分业务场景”
讲师：“没错，那做完了Tasking我们要干什么？”
学员：“拿着Tasking去找业务人员确认需求理解”
讲师：“所以Tasking应该用什么语言？”
学员：“业务语言。”
讲师：“那要用业务语言，是不是应该站在业务视角？”
学员：“是的。”

有没有发现，上述对话刚好发生了5个问题，是不是跟丰田佐吉提出的5 Why分析法有点类似。很有意思的一个对话，这个学员被讲师的5个问题问的自己找到答案，所以有时候讲师的提问引导是一项硬核技能，尤其是教练。

我做一个小补充，上述学员问题的上下文是TDD之前针对业务需求的Tasking，此时关注的是业务问题域，建议站在业务视角去理解业务需求，拆分需求，得到一份需求任务列表，并能够在开展实际开发工作之前，通过反馈来确保对业务问题的理解正确的。

另外在实际开发过程中，开发人员对技术解决方案也会做Tasking，这种技术任务的Tasking所关注的点跟业务需求的Tasking稍微有点不同。关于Tasking的两种视角，参考：如何区分Tasking的两种视角?