共计 2771 个字符，预计需要花费 7 分钟才能阅读完成。
在上周的文章中，咱们理解了用户故事的 INVEST 准则，以及研发需要拆分的两个规范：
- 大需要拆分的起点是用户故事，而故事要能在一个迭代中实现；
- 用户故事下的开发子工作应尽量满足 0/1 判断规范，且工作量倡议设置为 0.5~1 人 / 天。
本篇内容，Liga 将进一步介绍需要拆分的两种常见形式和具体拆分流程。
一、需要拆分的两种形式
01 程度切片 Horizontal Slice
如果将一个史诗级需要视作一个千层蛋糕，那么程度切片意味着将千层蛋糕逐层合成，每个人只能吃到其中某一层的滋味。
在传统研发工作中，人们通常会依照职能和组织架构，将整个需要横向地拆分成「每个职能小组的工作」，且每局部工作只被对应档次的成员所了解。例如：
工作 1：创立新的数据库表格
工作 2：创立传输协定
工作 3：创立 DAL 以拜访存储过程
工作 4：构建 UI/UX 页面
02 垂直切片 Vertical Slice
需要的垂直切片则像是将大蛋糕纵向切分成一块块小蛋糕，每块小蛋糕都能尝到「千层」的残缺口感。
垂直切片要求将残缺需要分解成若干个小但有价值的、可独立交付的用户故事。 每个故事只交付需要中的局部价值，但须要每个切片始终蕴含残缺的开发架构，且能被小组的全体成员通晓和了解。
以「重构账户治理性能」为例，它能够被垂直切分成多个用户故事，交付多个价值：
故事 1：用户能够领有多个账户
故事 2：用户能够更换账户头像
故事 3：用户能够查看头像应用的历史记录
故事 4：用户能够增加邮箱作为联系方式
03 垂直切片更适宜麻利开发
在之前的文章中咱们说过，麻利开发更实用于需要多变的、性能耦合度低的、价值可继续叠加的我的项目，或迫切需要推动市场反馈和验证的产品。👉点击回顾：麻利之道 | 麻利开发真的过期了么？
程度切片将需要横向地拆分成了各个架构层中的开发工作。对软件团队来说看似清晰，但每个局部的工作并不能独立交付给客户，不同工作间存在很强的依赖性。
如果采纳这种不甚合乎 INVEST 准则的需要拆分形式，又想要试行麻利开发，就可能遇上许多问题：
- 难以对立工作指标：每个职能小组仅从本身具体工作登程推动工作，难以就「用户价值」认知达成对立，堆高团队沟通老本；
- 优先级排序难度加大：麻利办法的外围就是继续滚动的优先级评估和价值排序，但横向切片带来的高耦合度，使得各项工作不仅有时序依赖，还难以量化价值和优先级，进而导致团队的交付速度降落，甚至会重大影响企业的市场竞争力；
- 试错老本进步，项目风险不可控：因为程度切片的工作无奈独立交付，管理者和业务相干方很难在我的项目过程中依据已实现的工作判断推动方向的正确性，或者及时觉察架构中存在的问题。这不仅减少了开发团队的试错老本，更可能因为无奈响应市场的疾速变动，而承当更大的项目风险。
为了防止上述种种问题，做到指标对立、灵活应变、升高试错老本、晋升交付效率，麻利团队势必要采纳全新的办法，突破组织架构间的「隐形墙」，更快地向用户提供价值。
比方说：将残缺的性能需要拆分成多个可独立交付价值的用户故事。这正是麻利开发中的最佳实际——垂直拆分。
二、需要拆分第一招：SPIDR 框架
麻利教练兼 Scrum 联盟的联结创始人 Mike Cohn 指出：“简直所有需要都能够通过五种办法实现拆分”。他用首字母缩略词「SPIDR」总结了这五种办法。
01 Spikes 探针
Spike 探针，或称技术预研，通常指性能的小型原型实现，或是对新技术的调研和可行性评估。
探针法通常实用于需要不明确或太简单，团队须要更多信息以供决策的状况。通过技术预研充沛了解需要外延，疾速探知可能的技术计划，初步判断工作量，以反对需要的细化拆分。
02 Paths 门路
如果残缺需要存在多个实现门路或场景（通常由 和 / 等 / 或 等形容词体现），那么拆分时不用遍历所有状况，只须要选取局部门路并将它们编写成用户故事即可。
举个例子🌰：线上购物的用户能够应用银行卡或三方领取实现订单领取。
依据「或」的形容，能够将该需要拆分成两个场景「应用银行卡实现领取」、「应用三方渠道实现领取」。进一步细化会发现，三方渠道也有多个实现门路，比方间接对接支付宝、微信，或采纳聚合领取伎俩等等。
门路法指出，当需要存在多个实现门路时，无需遍历所有门路，只须要交付最有价值的局部门路即可。所以，假如咱们通过评估认为，率先反对微信领取，开发工作量小且带来的用户价值高，那么整个领取性能就能够作如下拆分：
03 Interfaces 接口
当残缺需要 横跨多种客户端或者数据交互接口 时，能够依据接口的多样性进行需要拆分。
例如，客户端能够分为挪动设施和浏览器两大类，挪动设施能够分为 iOS 零碎、Android 零碎等，而浏览器又能够分为 Chrome、Edge、Firefox 等等。为了防止工作量过于宏大和繁琐，在理论利用中更常见的做法是，依照「可反对」和「临时无奈反对」两类来布局此类故事。
第二种状况是 根据不同的数据操作接口进行拆分，例如在实现数据导入性能时，可能须要反对多种文件类型（Word，Excel，CSV）的导入，那么每一个不同的数据接口的实现都能够是一个独立的用户故事。
第三种状况 基于不同的界面交互方式，递增拆分需要。如下图所示，在后盾数据类型不变的状况下，依据工作工夫、工作紧急水平以及客户接受程度等判断条件，将「精美的操作界面」交付分为两个故事进行：
- 先交付「一个简略的 UI」，向客户提供「可用」的界面（如左图所示）；
- 补充一个继续优化的故事「使用户界面更加精美」，向客户提供更极致的 UI 与体验（如右图所示）。
图片出自 Bruce Wong 集体博客：https://brucetalk.com/2020/09…
04 Data 数据
根据不同的数据类型或者数据起源，拆分大型需要；通过专一于数据子集的性能实现，实现更简略的用户故事交付，是十分无效的形式。麻利团队能够在一个迭代周期内只专一于一种数据类型的实现，交付价值。
05 Rules 规定
一些业务逻辑中会带有很多规定限度，麻利团队能够依照业务规定和技术标准对用户故事进行拆分。
在工夫紧、工作重的状况下，逐渐实现对技术规范或业务规定的适应，是有意义的。这能够帮忙团队疾速试错、疾速交付、取得用户反馈，之后再基于反馈进行逐渐迭代，欠缺对应的业务规定，并达到相应技术标准。
三、Liga 总结
- 垂直切片更合乎麻利开发的要求。研发团队应该将大的需要纵向切分成多个小的、可独立交付价值的用户故事。
- 麻利需要拆分框架之一：SPIDR。通过应用探针法、门路法、接口法、数据法和规定法，能够将大的需要拆分成合乎 INVEST 准则的用户故事。
在下一篇文章中，Liga 将持续带来研发需要垂直拆分的第二招：用户故事切分流程图。请继续关注 LigaAI 动静。
理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品。
