敏捷看板需要对需求拆分任务。需求拆分是敏捷过程中有一个最重要的部分，拆分需求的好处包括：一、更方便安排工作；二、及时发现风险；三、更快获得反馈；四、发现问题更及时修复；五、便于优先级的排列；六、节约估算时间，提高估算准确度；七、提高信用度。
一、更方便安排工作
如果每个需求能拆分到足够小，可以有效防止任务遗漏，避免到迭代末才陆陆续续冒出来没有考虑到的任务。也方便大家领任务，且小需求可让大家均衡的工作，不会一阵忙一阵松，改善团队的绩效。
二、及时发现风险
需求拆分越细，思考就越多，识别的风险就更充分，这样有更多时间去减缓风险的发生，凡事预则立不预则废。
三、更快获得反馈
敏捷最大的好处之一就是通过频繁交付，快速获得反馈，而这最主要还是通过需求细化来实现。如果需求太大，多于一周甚至一个迭代，那么就必然会出现到迭代末还有大量需求未完成的情况，也就无法获得PO或客户的反馈，所以我在团队内一直强调，需求要细化到1－3天内。特别是，迭代内要求同时要完成测试任务的，就要拆的更细，否则到迭代末才有可测试的版本。
四、发现问题更及时修复
迭代内发现的BUG，在迭代内修复效率是最高的，超过一个迭代，可能开发已经忘记自己写的代码了，再去定位要花费更多时间。
五、便于优先级的排列
需求越细，PO越容易排列优先级，原有大需求中的高价值部分可能会被排前面，而低价值部分会排后面。这样团队将会持续在开发“更精确的”高优先级需求，防止到迭代末还有高价值的需求未实现。
六、节约估算时间，提高估算准确度
需求粒度越小，需求间的差距就会越小，这样团队就不需要估算每个故事的大小了，可以直接算故事个数。迭代结束未完成的需求也会小很多，防止有大粒度需求未完成，这样迭代交付率就会很高。
七、提高信用度
试想一下，假若每个迭代跟干系人承诺的需求实际完成率都很低，下次还会有人信任你们的团队吗？只有每个迭代都按期完成了，才能提高团队的可信度，而便于团队形成稳定的迭代速率，团队的信心也会增强。每个迭代90％以上的交付率，总比50％的交付率给人的感觉更舒服吧。
延伸阅读：
什么是敏捷开发？
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待。
文章标题：敏捷看板需要对需求拆分任务吗，发布者：Flawy，转载请注明出处：https://worktile.com/kb/p/49526
微信扫一扫 
支付宝扫一扫 
