经常碰到迭代结束了，还很多任务未完成，若按照敏捷的原则，得将未完成的任务延期到下一个迭代，但会导致不少重复工作量；若不这么做，就得延长迭代周期，变得不伦不类。于是不少团队开始怀疑敏捷开发的好处，要是按照传统瀑布模式，就没有这些烦恼了。之所以会有这样的问题，我觉得最主要的是需求没有拆分到足够细，这里总结一下需求拆分的几个好处吧。

更方便安排工作

如果每个需求能拆分到足够小，可以有效防止任务遗漏，避免到迭代末才陆陆续续冒出来没有考虑到的任务。也方便大家领任务，且小需求可让大家均衡的工作，不会一阵忙一阵松，改善团队的绩效。

及时发现风险

需求拆分越细，思考就越多，识别的风险就更充分，这样有更多时间去减缓风险的发生，凡事预则立不预则废。

更快获得反馈

敏捷最大的好处之一就是通过频繁交付，快速获得反馈，而这最主要还是通过需求细化来实现。如果需求太大，多于一周甚至一个迭代，那么就必然会出现到迭代末还有大量需求未完成的情况，也就无法获得PO或客户的反馈，所以我在团队内一直强调，需求要细化到1-3天内。特别是，迭代内要求同时要完成测试任务的，就要拆的更细，否则到迭代末才有可测试的版本。

发现问题更及时修复

迭代内发现的BUG，在迭代内修复效率是最高的，超过一个迭代，可能开发已经忘记自己写的代码了，再去定位要花费更多时间。

便于优先级的排列

需求越细，PO越容易排列优先级，原有大需求中的高价值部分可能会被排前面，而低价值部分会排后面。这样团队将会持续在开发“更精确的”高优先级需求，防止到迭代末还有高价值的需求未实现。

节约估算时间，提高估算准确度

需求粒度越小，需求间的差距就会越小，这样团队就不需要估算每个故事的大小了，可以直接算故事个数。迭代结束未完成的需求也会小很多，防止有大粒度需求未完成，这样迭代交付率就会很高。

提高信用度

试想一下，假若每个迭代跟干系人承诺的需求实际完成率都很低，下次还会有人信任你们的团队吗？只有每个迭代都按期完成了，才能提高团队的可信度，而便于团队形成稳定的迭代速率，团队的信心也会增强。每个迭代90%以上的交付率，总比50%的交付率给人的感觉更舒服吧。