凭啥总逼我拆成小故事啊？
2018-11-28
来源：杰克船长与精益敏捷 徐东伟
为啥要拆用户故事啊？
一定要拆吗？
你不就是想要看进度吗，我拆成一堆不超过8小时的任务给你看不就行了吗？
这个故事就我一个人做，拆故事，这不是自己玩自己呢吗？
来来来，别着急，聊5毛钱儿滴！
01：拆得明白才想得明白
故事越大，你越难想得清楚！你以为你大概齐清楚了，一拆，发现还有那么多东西没想清楚！
不拆，那就是做到哪算哪了？
你受得了，我可受不了！
02：拆小才好估算
想要估算的靠谱，就要拆小！
小了就明确了，明确了就知道怎么做了，然后你就更知道要多长时间了！
03：排优先级的秘密
“大故事，就这么一坨，优先级那是杠杠滴，我需要10天才能完成这个故事！其他的故事都给我靠边站！”
“这......”
>>
可是如果你把这个故事拆成5个小故事，很多时候只有其中的2个小故事优先级非常高，另外的3个小故事完全可以排到其他故事的后面。
怎么样，齐活了，对吗？
04：老板再也不用担心我延期了
有些小伙伴和我抱怨，他的功能上线经常延期，因为总是有领导临时塞来高优先级任务，导致原来的工作停滞！
>>
故事拆小就好了！把大故事拆成A、B、C、D、E五份！老板又来塞活了！我正在做D，打断没关系，那就先上线A、B和C！
当然，前提是该用户故事的拆分真的是相互独立，而且是能够独立交付业务价值的。
05：快速反馈，我喜欢！
你也许会问，我手里的这个故事虽然大，但是把它再拆小，就无法给客户交付完整的业务了！还是不要拆了吧！
>>
把故事拆小的意义在于，我们可以尽早看到结果，尽早进行测试，尽早得到反馈，尽早调整！
我们可以等到所有的这些小故事完成后再上线！
注意：这里拆分成的小故事虽然无法为客户交付完整的业务，但是我们还是要将它拆分成业务层面能够验证的故事，而不是技术层面的拆分！
06：优化架构，没想到吧！
我辅导的一个小伙伴和我说，为了能够交付相对独立的用户故事，他们不得不修改原来剪不断理还乱的复杂架构，否则这个用户故事说啥也摘不出来！
怎么样，神奇吧！
07：还有更神奇的！
还是那个小伙伴和我说，生产线上曾经报出来一个Bug，不能稳定重现，问题定位还非常困难，时间长了大家都快忘记了！
因为实施敏捷，故事拆细了，每个故事又要进行彻底测试，结果当初的Bug自然浮现出来了，直接改掉了！
关于作者：
徐东伟，光环国际敏捷高级咨询顾问，SPC/ACP/CSM，很享受读万卷书，行万里路，阅人无数的生活！
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
