最近在读乔梁写的一本《持续交付2.0业务引领的DevOps精要》的书籍，有一节讲需求拆分的方法的原则写的甚好。其中的INVEST原则，需求拆分的5大技法及用户故事地图等工具的使用在实际的工作中有很好的指导意义。好多产品经理面对一堆用户场景和用户故事的时候不知道如何进行有效的需求拆分，要么颗粒度较大不利于迭代的顺利交付和后期的验证。要么对需求的优先级没有清晰的概念，什么都想要，眉毛胡子一把抓导致开发周期较长，最终上线之后发现与用户实际需求的偏差较大。本文是对书中提到的有关需求拆分的一些方法和指导原则进行读后总结，希望能对从事产品相关工作的童鞋有点启发。
INVEST原则
INVEST原则是用于检测用户故事是否拆分得当的原则，它由下方6个英文单词的首字母组成。
1.Independent（独立原则）：
指的是用户故事需要彼此独立，低耦合。笔者理解此处还有一层意思，每个用户故事需要是完整的，对应的每个需求都是相对完整可验收的。这样做的目的有利于团队开发任务分配和保证用户使用场景的完整可用。
2.Negotiable(可协商原则）：
在进入开发前，故事卡片/需求项用来提醒团队及干系人进行讨论，而不是作为产品经理与开发人员的契约来使用。这一点与我们常见的工作开发节奏是所有不同的，它更加强调团队各角色对于用户场景故事的讨论，这个需求和用户故事不是固定的，是个动态的逐步深入明晰的过程，不是产品经理直接定义好的需求项。这样做的好处能够集各角色之长，使得用户场景考虑的更加全面，减少产品经理因思考不周而造成的决策失误，也能使研发团队更好的理解项目的上下文，有助于产品的功能和体验的顺利达成。
3.Valuable（有价值原则）：
指用户故事（功能项）对于用户来说是重要的，有价值的。此观点较好理解，故不赘述。
4.Estimable（可估算原则）：
开发团队能够根据用户故事估算所需的工作量。这项类似于开发看到需求之后要对开发周期，工作量，难点有个清晰认识，方便后续开发的顺利推进。
5.Small&Similar Size（规模小且适中原则）：
用户故事必须足够小，尽可能在一个迭代内完成；并且多个用户故事之间的开发工作量差异不宜过大。这样做的目的是能够保证开发能够合理的预估工作时长，降低不确定因素的影响。此处有一个比较形象的比喻：你对一个足球体积的估算偏差一定远远小于对于月球体积的估算偏差。
6.Testable（可验证原则）：
用户故事必须是可以被验证的。笔者认为此处包含两层含义，一个是功能开发阶段：开发设计完成之后有明确的验收标准，确定开发完成了该用户需求。另一个是产品发布之后，针对这个场景/用户故事能够收集到明确的市场反馈，是否满足用户需求，有没有达到用户预期等等，方便后续的迭代改进。
五大需求拆分技法
1.路径拆分法：
路径拆分法是根据用户使用场景的不同路径进行拆分。通俗点的理解就是：你要通过什么方式达成你的目的地。举个例子：放假了你打算去三亚旅游，你需要考虑通过什么交通方式抵达三亚：火车、汽车、飞机、骑行等等。你可以把不同方式的解决方案罗列出来，以进行利弊优缺点的综合考量以辅助你决策。用户故事就可以写：（1）用户可以通过坐飞机抵达三亚；（2）用户可以通过坐火车抵达三亚；（3）用户可以通过坐汽车抵达三亚。
2.接触点拆分法：
所谓的接触点指的是用户与系统之间的交互通道，例如移动端应用和PC浏览器是两种不同的接触点。在PC浏览器有可以按照不同的浏览器类型进行区分：Safari、Chrome、Firefox和IE。IE浏览器的适配工作量大，而其他几种浏览器的适配工作量较小，因此我们的用户故事可以分开写：（1）用户可以使用IE浏览器查看；（2）用户可以使用非IE的浏览器查看。
3.类型或格式拆分法：
这个就是我们常见的一种分类方式，举例：朋友晚上来家聚餐，需要买点喝的，那市场上可选择的喝的分类有很多：酒精类的、碳酸气泡类的、功能型、0糖类的等等。大家如果对分类想有进一步认识，可以了解一下“MECE原则”，该原则最初是由麦肯锡的女咨询顾问巴巴拉·明托在金字塔原理中提出的，主要讲如何给事物进行分类，能够做到不重叠、不遗漏的分类。
4.按规则拆分：
规则指的是业务规则或者技术规则。例如ios的设计开发规则与android的规则就大相径庭。再举个例子：假设研发一款系统，专门用来推荐邮寄方式的。妈妈要邮寄家乡特产给远在异地的你，其中有个需求就是：最快送达，邮费便宜。该需求就可以规则就可分成四个：（1）按速度最快；（2）按价格最便宜；（3）按速度最快价格可以稍微高点；（4）按价格最便宜，速度可以稍微慢点。四者产生的结果方案可能会截然不同。
5.探索路径拆分：
在开发过程中，团队总能遇到一些对团队来说比较陌生或者不确定的实现方案，是可以将对陌生事物的试验性探索逐步拆分成不同的探索故事。这种探索故事有较大的不确定性，因此要作为高风险点管理，保持持续关注。
