凭啥总逼我拆成小故事啊？

为啥要拆用户故事啊？

一定要拆吗？

你不就是想要看进度吗，我拆成一堆不超过8小时的任务给你看不就行了吗？

这个故事就我一个人做，拆故事，这不是自己玩自己呢吗？

来来来，别着急，聊5毛钱儿滴！

故事越大，你越难想得清楚！你以为你大概齐清楚了，一拆，发现还有那么多东西没想清楚！

不拆，那就是做到哪算哪了？

你受得了，我可受不了！

想要估算的靠谱，就要拆小！

小了就明确了，明确了就知道怎么做了，然后你就更知道要多长时间了！

“大故事，就这么一坨，优先级那是杠杠滴，我需要10天才能完成这个故事！其他的故事都给我靠边站！”

“这......”

>>

可是如果你把这个故事拆成5个小故事，很多时候只有其中的2个小故事优先级非常高，另外的3个小故事完全可以排到其他故事的后面。

怎么样，齐活了，对吗？

有些小伙伴和我抱怨，他的功能上线经常延期，因为总是有领导临时塞来高优先级任务，导致原来的工作停滞！

>>

故事拆小就好了！把大故事拆成A、B、C、D、E五份！老板又来塞活了！我正在做D，打断没关系，那就先上线A、B和C！

当然，前提是该用户故事的拆分真的是相互独立，而且是能够独立交付业务价值的。

你也许会问，我手里的这个故事虽然大，但是把它再拆小，就无法给客户交付完整的业务了！还是不要拆了吧！

>>

把故事拆小的意义在于，我们可以尽早看到结果，尽早进行测试，尽早得到反馈，尽早调整！

我们可以等到所有的这些小故事完成后再上线！

注意：这里拆分成的小故事虽然无法为客户交付完整的业务，但是我们还是要将它拆分成业务层面能够验证的故事，而不是技术层面的拆分！

我辅导的一个小伙伴和我说，为了能够交付相对独立的用户故事，他们不得不修改原来剪不断理还乱的复杂架构，否则这个用户故事说啥也摘不出来！

怎么样，神奇吧！

还是那个小伙伴和我说，生产线上曾经报出来一个Bug，不能稳定重现，问题定位还非常困难，时间长了大家都快忘记了！

因为实施敏捷，故事拆细了，每个故事又要进行彻底测试，结果当初的Bug自然浮现出来了，直接改掉了！

WoW!