敏捷需求管理︱如何拆分需求实现渐进式交付
2022-10-30
来源：王宇教练 ACT敏捷教练
果拆分更细致的话，比如以小时为单位进行拆分，对于跟踪与记录来说就会存在粒度太细碎的问题。
太小（细碎）的粒度会带来管理成本的提高。因为每一项事情你都需要进行关注，进行管理。太细的粒度会导致管理成本提高。但如果粒度太大或太粗又会造成机会成本的提高。也就是你可能会因为粒度太大反馈速度太慢而造成一些更大的损失。我们需要在机会成本和管理成本之间进行平衡，这样粒度才是合适的。（如下图所示）
对于拆的太过细碎的需求，你完全可以打包形成一个单独的需求。这样其实拆小，拆细才是对需求管理的更高要求。
四、什么是合适的粒度
对于一般的具体软件开发项目来说，每一个需求3天左右的粒度是一个拍脑袋的经验数据。所以，任何开发工作都要从这个3天左右的粒度的需求进行汇总形成更高阶的需求合集。如果说你不能控制粒度到3天左右的话，也强烈建议最大工作量的需求在5天内完成。对于这个粒度的需求，就可以汇总形成便于管理与决策的内容，如下图所示。
我需要再明确一下，一切的决策建议都基于这个最细粒度的需求来进行整体讨论，而不是反向而行之。因为恰恰是这个粒度的需求才会平衡技术与业务的关键粒度，小了大家觉得太细碎了没必要讨论。大于这个粒度，技术的风险和业务的风险不一定能暴露。
这其实牵扯到一个非常重要的概念，就是估算。对于估算的更多内容，我们会有单独的文章详细介绍。这里就主要讨论粒度和切分手段。
到现在为止其实我们还没有触及敏捷概念，你可以理解上面的所有拆分就是按照功能与模块的拆分。如果整体同一时间点进行交付的话，这没有什么问题。一旦我们面对需要增量和不停市场反馈的场景之下，之前的切分手段就感觉捉襟见肘了。我们先需要的是……
五、增加敏捷的能力
敏捷的能力从产品的角度来看，就是能够尽早获得市场反馈的能力。这对于习惯于大而全进行设计的IT人员来说却是是一个挑战，因为整个设计的过程是贯穿整个开发的过程，每来一个需求都需要进行一次设计工作。所以对于是否打开敏捷能力的切分，我建议还是因不同情况而抉择。一次制作10个功能，和10个功能一次一次的做，显然第二种方法更费劲一些。但你不能因为一次做一个功能费劲，就不去选择这种方式。可能迭代的一次次的制作从产品角度来说就是非常正确的道路。所以要警惕技术开发人员惯性思维对切分造成的潜在影响。
我在带领团队进行敏捷转型的过程中，很多时候都是略显逼迫技术人员按照业务角度进行切分的。那这种让业务人员参与的一个好处就是，业务人员可以做出一些调整优先级的决策。如果完全是按照技术角度进行切分的话，你只能按照这个切分的思路进行开发过程。往往到后期，业务人员其实是被技术人员绑架了（因为只能这样的交付过程）。这也是业务与技术关系很多时候不太融洽的一个原因（业务的参与感太少了）。
对于敏捷需求的切分，期望的是每一个需求都是制作陶器时手部的一次变化，随着转盘的转动陶器的形状实现了逐渐的变化。手的每一次位置的调整，陶器的形状就发生一次变化，而且这种变化是基于上一次变化。对于软件来说是相似的，软件的每一次需求，都对软件进行了一次调整与改变。每一个需求都是基于上一个需求的一次增量。
这种增量是一种可
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
