故事卡分解任务的实践及意义
分析了原因:
1)我们的BA(商业分析师)能力不达标:故事卡里的验收标准不够详细，没有深入思考所有相关的用户旅程。
2)在这样一个故事卡的背景下，作为一个开发者，如果没有提前思考用户旅程的整个意识，你会发现很多问题只有在接触到的时候才会思考，才会发现这是一个需要各种角色讨论的大坑，才可以继续做下去。
3)如果开发者在做卡的时候没有想清楚各种业务场景，如果完全按照不完整的AC来做，会产生很多bug。如果这些bug只是在测试人员测试这块卡的时候出现，问题就小了，可以重做。但是往往测试人员只会跟着AC去测试，这样这张卡就会被视为完成，合并回你的主分支。这样，这些bug会在后期暴露出来(在真实数据测试的情况下)，你不得不创建一个新的故事卡来跟踪，这甚至可能影响整个项目的发布。
这样一来，一张故事卡的开发和完成，就需要比原来预计多一倍的时间，整个团队的交付效率极低，组内成员也会很吃亏。
在这种情况下，作为开发者，我们能做的就是在我们的环节尽可能的解决这样的问题。这个时候最有效的就是把故事卡分解成小任务。
我第一次接触这个概念是在学习TDD的时候。当你想实现一个功能的时候，你可以先把它分解成更小的任务。
例如:除法运算
你的任务可以是:(1)除数不为0，舍入(2)除数为0，打印错误日志。
只要你的函数满足这两个任务，它就是完整的。
同样，这个概念也可以应用到故事卡上。这些步骤如下
(1)从易到难列出所有能快速实现并让人有成就感的任务:
这个过程可以帮助你了解故事卡的整个业务流程，找出隐藏的业务场景和需要业务人员提供的缺失信息。同时developer也会思考如何实现这个功能，可以快速帮你理清实现思路。这种类型的任务更像一个检查点。
至于如何分解任务，我一般是借助黄金金字塔原理，按照层级来划分。在故事卡中，通过用户旅程打分应该是最简单直接的。
(2)如果功能复杂，您可以将每个任务再次分解为功能性任务:
一般这种纯功能性的任务不需要太仔细的拆解，只需要记录重要的点就可以了。
(3)重构:第一次列出的任务不一定全面，边做边改进。
当业务场景太多的时候，第一步的比例就会过大。但当故事卡偏向功能性时，可以省略第一步，直接开始第二步，同时以一些简单的UI改动为任务。
这个方法其实就是提前总结你从制作这个故事卡开始到这个过程结束的思维模式，让你更早的发现问题。无论是开发、BA还是测试，都非常适用。符合TODOLIST的人生哲学。
最后，附上显示用户行为表功能的任务图: