admin 管理员组文章数量: 1086019
2024年4月15日发(作者：recording是什么意思)
浅析需求拆分
一、为什么要做需求拆分
一般情况下，当需求抵达研发团队，会先进入需求池等待处理，直到产品团队和研
发团队完成理解、评估、规划和分工等一系列工作后，才会正式进入开发阶段。很多团
队会在迭代开始后，才开始需求的细化拆分。这就导致那些看起来不复杂，但其实工作
量很大的需求被拆分成几十个甚至上百个子任务，有的甚至需要嵌套 N 层子任务才能
触底落到每个开发者身上。此外，这些子任务颗粒度混杂：有的任务可能几个小时就能
完成，有的则需要几天、一周甚至更长的开发时间。这势必会带来进度管理上的混乱。
与之不同的另一种处理办法：前置需求拆分环节，在开发阶段专注价值创造和交付，更
有条理地管理项目进度。项目团队应该在需求评审到进入研发之间的时间内，将需求拆
分到尽可能小的粒度，再推进后续的工作
二、如何对需求进行拆分
1. 交互逻辑拆分法
此处说的交互逻辑为页面整体的功能跳转逻辑，在需求评审之初我们已经绘制了整
个功能结构图，此时需要我们对照着功能结构图去审核我们的交互跳转逻辑。
细化交互逻辑：细化交互逻辑是指我们在整体交互逻辑下要去考虑交互发生时，页
面上按钮、链接、提示等信息交互逻辑，比如：具体跳转页面、具体按钮的状态及颜色
变化、具体的跳转提示等。
2.静态信息拆分法
此处说的静态信息为页面整体的信息流程图，在需求评审之处我们已经绘制了了整
个需求的信息结构图，此时我们需要对照着信息结构图去审核我们的页面静态信息逻辑。
细化静态信息：页面上显示字段的逻辑，比如具体的显示字段；某个字段显示的个
数、类型、字号、颜色等；涉及到排序的字段排序规则，默认排序规则等。
3.数据流转拆分法
在需求评审之初我们会和研发核对数据表及相关信息，页面跳转时也需要考虑状态
不同，存储及上传数据是否不同。数据是整个项目的关键部分，不同状态下点击不同按
钮的具体数据显示形式需要确认。
4.路径拆分法：
路径拆分法是根据用户使用场景的不同路径进行拆分。通俗点的理解就是：你要通
过什么方式达成你的目的地。举个例子：放假了你打算去三亚旅游，你需要考虑通过什
么交通方式抵达三亚：火车、汽车、飞机、骑行等等。你可以把不同方式的解决方案罗
列出来，以进行利弊优缺点的综合考量以辅助你决策。
5.接触点拆分法：
所谓的接触点指的是用户与系统之间的交互通道，例如移动端应用和PC浏览器是
两种不同的接触点。在PC浏览器有可以按照不同的浏览器类型进行区分：Safari、Chrome、
Firefox和IE。IE浏览器的适配工作量大，而其他几种浏览器的适配工作量较小，因此
我们的用户故事可以分开写：（1）用户可以使用IE浏览器查看；（2）用户可以使用
非IE的浏览器查看。
6.类型或格式拆分法：
这个就是我们常见的一种分类方式，举例：朋友晚上来家聚餐，需要买点喝的，那
市场上可选择的喝的分类有很多：酒精类的、碳酸气泡类的、功能型、0糖类的等等。
大家如果对分类想有进一步认识，可以了解一下“MECE原则”，该原则最初是由麦肯锡
的女咨询顾问巴巴拉·明托在金字塔原理中提出的，主要讲如何给事物进行分类，能够
做到不重叠、不遗漏的分类。
7.规则拆分法：
规则指的是业务规则或者技术规则。例如ios的设计开发规则与android的规则就
大相径庭。再举个例子：假设研发一款系统，专门用来推荐邮寄方式的。妈妈要邮寄家
乡特产给远在异地的你，其中有个需求就是：最快送达，邮费便宜。该需求就可以规则
就可分成四个：（1）按速度最快；（2）按价格最便宜；（3）按速度最快价格可以稍
微高点；（4）按价格最便宜，速度可以稍微慢点。四者产生的结果方案可能会截然不
同。
三、需求拆分的原则
INVEST原则是用于检测用户故事是否拆分得当的原则，它由下方6个英文单词的首
字母组成。
ndent（独立原则）：
指的是拆分完的需求需要彼此独立，低耦合。笔者理解此处还有一层意思，每个子
需求需要是完整的，都是相对完整可验收的。这样做的目的有利于团队开发任务分配和
保证用户使用场景的完整可用。
able(可协商原则）：
在进入开发前，需求项用来提醒团队及干系人进行讨论，而不是作为产品经理与开
发人员的契约来使用。这一点与我们常见的工作开发节奏是所有不同的，它更加强调团
队各角色对于用户场景故事的讨论，是个动态的逐步深入明晰的过程，不是产品经理直
接定义好的需求项。这样做的好处能够集各角色之长，使得用户场景考虑的更加全面，
减少产品经理因思考不周而造成的决策失误，也能使研发团队更好的理解项目的上下文，
有助于产品的功能和体验的顺利达成。
le（有价值原则）：
指拆分后的需求对于用户来说是重要的，有价值的。此观点较好理解，故不赘述。
ble（可估算原则）：
开发团队能够根据拆分后的需求估算所需的工作量。这项类似于开发看到需求之后
要对开发周期，工作量，难点有个清晰认识，方便后续开发的顺利推进。
&Similar Size（规模小且适中原则）：
拆分后的需求必须足够小，尽可能在一个迭代内完成；并且多个需求之间的开发工
作量差异不宜过大。这样做的目的是能够保证开发能够合理的预估工作时长，降低不确
定因素的影响。此处有一个比较形象的比喻：你对一个足球体积的估算偏差一定远远小
于对于月球体积的估算偏差。
le（可验证原则）：
每个需求必须是可以被验证的。笔者认为此处包含两层含义，一个是功能开发阶段：
开发设计完成之后有明确的验收标准，确定开发完成了该用户需求。另一个是产品发布
之后，针对这个场景能够收集到明确的市场反馈，是否满足用户需求，有没有达到用户
预期等等，方便后续的迭代改进。
版权声明：本文标题：需求拆分浅谈 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/b/1713176584a622609.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论