故事卡分解任务的做法和意义

最近在一个业务逻辑很复杂的项目上工作，这个项目第一期大概做了半年时间，过程中遇到了很多问题，印象最深刻的就是大部分的故事卡(小feature)经常在快做完的时候，developer才发现有一些原来没有意识到的一些业务场景。

分析了一下原因:

1）我们的BA(Business Analyst)能力不达标：故事卡里面的acceptance criteria不够详尽，没有深入思考所有相关的user journey

2）在这样的故事卡的背景下，作为developer，如果你没有事先思考整个user journey的意识，那么就会发现好多问题都是当你接触到了你才会去思考，结果却发现是一个大坑，需要各种角色来讨论，然后才能继续做。

3）如果developer在做卡时候没有思考清楚各种类型的业务场景，只是完全follow 不全面的AC来做的话，会产生很多bug。如果这些bug仅仅出现在测试人员测试这张卡的情况下，问题还小点，可以回炉重做。但常常测试人员也只会follow AC 来去测试，这样这张卡就会被当成已经做完，merge回你的主分支。这样一来，这些bug就会在更晚的时间暴露出来（真实数据测试情况下），你又不得不创建新的故事卡去track，严重的话，甚至可能影响到整个项目的发布。

这样导致的结果是：一张故事卡从开始开发到完成花费的时间是原来估计的两倍，整个team交付效率极低，组内成员也会很suffer。

在这种情况下，作为开发人员，我们所能做的就是在我们这一环节尽可能的去解决这样的问题。这个时候最有效的就是：将故事卡分解成一个一个小任务了。

最早接触到这个概念是在学习TDD的时候，当你想实现一个功能时，你可以先把它拆成一个个更小的任务。

举个例子：除法运算

你的tasks可以为：（1）除数不为0，取整 （2）除数为0，打印错误日志

只要你的功能满足了这两个task，就算是完成。

同样的，这种概念也可以应用故事卡上，步骤为

（1）列出所有tasks，可以由易到难，这样能快速实现，让人有成就感：

这个过程能帮你理解故事卡的整个业务流程，找出隐藏的业务场景，缺失的需要业务人员提供的信息。同时，developer也会去思考大概要怎么实现这个功能，能快速帮你理清实现思路。这种类型的task更像是checkpoint。

关于如何分解task，我一般会借助金字塔原理按层次结构来分。在故事卡中，通过user journey分应该是最简单直接的了。

（2）如果功能性比较复杂的话，可以把每个task再次拆细，拆成功能性的task：

一般这种纯功能性的task不用拆的过细，记录重要的点即可

（3）重构：第一次列出的tasks不一定全面，边做边补充边改善

当业务场景过多的时候，第一步比重会过大。但当故事卡偏功能性时，可以省略第一步，直接开始第二步，同时把一些简单的UI change作为task。

其实，这种方法就是把你从开始做这张故事卡到做完这个过程的思维模式提前总结，让你能更早的发现问题。无论是开发，BA还是测试都是很适用的。和生活中的TODOLIST理念一致。

最后附上一张用户行为表展示功能的task图：