用户故事拆分终结者 | 第14期

2023-05-25 09:25:52
践行者
原创
437
摘要：打破拆分用户故事时左右为难的困境！


你真的会拆分用户故事吗？用户故事拆分的原则是什么？不同场景下的用户故事又该如何拆分？本期《践行者》，我们非常荣幸邀请到了资深敏捷教练苗再青老师，帮助大家打破拆分用户故事时左右为难的困境！


一、用户故事拆分终结者


用户故事如何拆分？苗老师先介绍了基本原则及需要注意的点：

用户故事切分的重要原则是要做纵向切分，而不是横向切分。以汉堡为例，如果做纵向切分（从上到下切），每一块吃着还是汉堡；如果做横向切分，就只能分成一层牛肉、一层生菜、一层酸黄瓜等等，这种切分对用户来说毫无意义。在实际工作场景中，像“把页面划分成一个用户故事、数据库存储划分为一个用户故事”这种切分就属于横向切分，也是我们常犯的错误。

具体的用户故事拆分流程可以遵循以下流程：

用户故事拆分流程
遇到具体的用户故事，苗老师也给出了用户故事拆分的十三把刀：


  1. 按流程拆分：当用户故事描述一个流程时，先完成流程的头尾部分，再添加中间步骤来完善用户故事。也就是先通过最简单的方式实现流程，后续逐步完善。
  2. 按操作拆分：如增删改查，按不同操作切分成独立的用户故事。
  3. 按不同的业务规则拆分：比如在购物网站下单，VIP客户与普通客户有不同的下单或满减规则，这时就需要划分成两个用户故事，即VIP客户下单与普通客户下单。
  4. 按开发平台拆分：根据实际情况，可以切分成安卓、iOS、Web等不同的用户故事。
  5. 按不同数据源/数据类型拆分：在采用不同的数据源完成相同的事情时，可以将每种数据源切分成独立的用户故事，比如MySQL、Oracle等。
  6. 按功能/非功能需求拆分：比如用户提出来需要搜索功能，且搜索速度要快时，可以将功能需求（搜索功能）和性能需求（搜索速度要快）划分成不同的用户故事。
  7. 按简单/复杂拆分：将简单核心的功能切分成独立用户故事，后续的用户故事再增加功能。这种方法是将一个复杂用户故事切分成几个相对简单的用户故事，通过迭代完成一个复杂的用户故事。比如要做搜索功能，前期可以先做按名称搜索或模糊搜索，后续再进行完善。
  8. 按界面拆分：多个界面获得相同数据的情况下，可以将每个界面划分成独立的用户故事。
  9. 按业务/技术类型拆分：将技术类工作划分为独立的用户故事，例如某个用户故事的完成需要对架构进行调整 ，则这个架构调整可以拆分出了，成为一个独立的技术类用户故事。
  10. 按故事不同的展现形式拆分：同样的信息用不同的形式展现，比如订单完成后，可以通过短信、微信、电话联系等方式进行通知。
  11. 按工作类型拆分：当需求很琐碎时，可以将同类需求划分为一个用户故事，比如修改1000个页面的logo。
  12. 拆分出一个探针：当需求信息不足无法拆分时，可以找到能够理解的部分写一个探针，将每个探针划分为一个用户故事。
  13. 用户故事的合并：如果拆分后，发现有一些用户故事太小，可以将小的用户故事合并为一个用户故事。
除此之外，苗老师还带来了进阶版的用户故事拆分的内容，还意犹未尽的伙伴们可以查看上方直播回放！

PPT资料分享：

点击文章底部附件，即可获得本期直播PPT资料~

二、问答实录

1、怎么定义用户故事有价值呢？

用户故事的价值可以通过3W模板清晰地体现，包括Who（角色）、What（想要干什么）和Why（价值的体现）。如果一个用户故事的Why无法清晰地表达，那么它就没有价值。价值可以从以下七个方面体现：为公司创造GMV、利润、效率提升、成本降低、用户体验增强、合规和安全等。如果符合这七个方面中的一个或多个，那么用户故事就是有价值的。3W模板可能有些繁琐，在实际操作中可以只写who和what，但是Why在心里一定要清晰明了。

我们要避免用户故事出现为了Why而Why的情况。例如，作为一个用户，我想要查看订单状态，以便我可以看到订单状态。这种描述应该被修改为我想要查看订单状态，以便于及时了解订单进展，提升用户体验，增强用户粘性，这才是真正的价值。


2、硬件生产研发的故事如何拆解，比如扫地机器人的用户故事涉及到硬件、软件、机械设计等。

有些工作尽管不是软件类型，但也可以视为用户故事进行处理。例如汽车、飞机、火箭、冰箱、电视和洗衣机等硬件类；基金管理类，基金管理有一定的流程，包括募集资金、资金申请和资金发放等工作；新闻工作类，有消息收集、采访、写作和发稿等部分。

下面稍微细说一下硬件如何拆分用户故事呢？以冰箱研发为例，整个冰箱的价值流从设计、计划、原料采购、生产到物流配送等整个生产流程比较复杂，今天就不全面展开了，仅从设计这一个环节说一下硬件如何拆分用户故事。关键点还是我们从用户的视角入手，而非从技术视角。第一层用户故事可以是冰箱可以冷藏，冰箱可以冷冻，冰箱可以除霜，冰箱节能省电，用户可以手动调节冷藏和冷冻温度等。在冰箱的一级用户故事全部列出后，产品经理和技术人员需进一步拆分第二层级用户故事，如制冷功能有氟利昂、半导体等多种方式。像压缩机这种零部件，在设计中是外部整体采购，就不需要再对其进行用户故事的拆分。

在硬件方面，需要避免第一层级用户故事是从技术视角进行拆分，例如冰箱第一层级的用户故事为冰箱有压缩机、冰箱有两个门等等，这样很明显不是用户视角。

3、用户故事拆分的目的是实现快速迭代，硬件的拆分方法是否也能实现这个目的呢？

如果对用户故事的拆分达到了精通的程度，实际上用户故事是不分软件和硬件的。无论是软件还是硬件，都只是用户需求的不同表现形式，因此用户故事是跨平台的。以扫地机器人研发为例，那么一级用户故事可以如下：
  • 机器人可以自动寻航扫地
  • 机器人可以自动充电
  • 主人可以控制机器人
  • 机器人具有安全性（不能撞击物品）
  • 机器人可以提供叫床服务
  • 机器适合于一般家庭使用（形状，大小，材质等）
然后再进行二、三级……用户故事拆分。


当然也可以用启动、使用、维护这种流程的方式来组织用户故事。

4、用户故事应该由谁拆分？

拆分用户故事的主角是PO，具体还需要谁参与用户故事拆分工作，由PO决定。一般来说，技术骨干和测试骨干，业务方最好也要参加。由于业务方还有自己的工作，有可能没有时间参加用户故事拆分，PO事后要找时间与业务方做好对齐工作。

5、技术性用户故事应该由谁拆分？

技术性用户故事由架构师和技术人员拆分。实际上，拆分用户故事需要项目或团队的技术骨干、架构师参与。架构师对业务比较熟，也可以提出一些业务类用户故事。产品经理在拆分业务类用户故事过程中，架构师，技术骨干等技术人员会思考其对架构或技术的影响并提出必要的技术类用户故事。例如，产品经理提出一个【增加视频播放】的需求，但架构师发现现有技术架构无法支持，便会提出增加一个技术类用户故事：【对现有架构进行优化】。

6、需求分业务需求、产品需求，这里用户故事拆分的是什么需求？

拆分的是业务需求。用户故事应从用户角度出发，因此需要注意不要将用户故事拆的过于细化。例如，在某某界面中添加一个新增按钮，这是一个产品需求，而不是用户需求。业务部门可能并不了解为什么要在该页面中添加按钮，而不在其他页面中添加。一旦确定了用户需求，后面讨论如何在页面中添加按钮，类似于业务需求的实践方案，这是产品需求。用户故事的拆分应该关注业务需求，这一点非常明确。

7、对于大数据表的拆分，如果字段之间存在关联关系，如何保证在拆分和独立可测试之间取得平衡？

这种情况，我们一般是将有关联关系的字段放置在同一个用户故事中，这样可以保证测试的独立性。如果将有关联关系的字段放在同一个用户故事中，会造成用户故事太大，则可以拆分成两个或多个用户故事。当然这样就会造成用户故事之间有依赖关系。根据INVEST原则，这种情况要尽量减少，同时在开发用户故事时要调整好先后顺序。例如B用户故事中的字段依赖于A用户故事，则要先做A用户故事，再做B用户故事。 

8、算法应该如何拆解？

对于算法的开发，我们可以分成多个迭代实现，先从一个最简化的版本开始。例如，为了确保人脸识别的有效性，我们需要达到97%以上的准确率。如果要想一次性达到97%的准确率，可能需要几个月的时间，无法在一个迭代内完成。可以先实现60%的识别率，这个非常容易，可以在一个迭代内完成。然后再逐步提高准确率，将实现70%、80%、90%等不同的目标分别作为独立的用户故事，直至达到97%以上的准确率。

9、 产品经理拆分故事为什么会评估5天？一个用户故事可能涉及多端，例如涉及APP、PC端、第三方系统多端？

（1）产品经理在拆分用户故事时，一定是有技术骨干（包括开发和测试）参加的，因此评估5人天并不是产品经理评估，而是技术人员评估。当然，这时候的评估不需要太精确，更不要做过多的争论；
（2）一个用户故事如果涉及多端，则每一端可以拆分成一个单独的用户故事。

10、功能性和技术类的是统一排还是各自排优先级呢？统一排谁说了算，分开排时间盒怎么说？

（1）功能性和技术类的用户故事优先级要统一排，不要分开排。原则还是一样的，即由PO和技术人员协商决定最终优先级，但最终决策权还是PO；
（2）优先级出来了，时间盒自然就出来了。例如，一个系统原先不支持视频播放，现在要支持，于是这个需求拆分成两个用户故事，一个是功能类用户故事【用户可以选择视频进行播放】，另一个是技术类用户故事【对架构进行优化，支持视频】。这个肯定要先做技术类用户故事，再做功能类用户故事。

11、解耦的故事具备业务价值吗？

是的，每个用户故事都要有业务价值。如果实在想不出价值的话，那就反问：如果这个用户故事不做会怎么样？如果觉得不做也可以，那就不做。敏捷的原则是能不做就不做，能少做就少做。阿米巴理论中提到“擒贼搓绳”，抓住了贼再搓绳子把贼捆起来，搓早了就是浪费，我认为很符合敏捷原则。

12、长业务链还能定义价值吗？感觉做集成测试验证就可以了。

（1）有一个统计数据表明，一个系统中，实际上有80%的功能是很少用到的，甚至有30%以上的功能是用户从来不用的，如Excel功能千千万，我们实际用到的却很少。因此，我们要确认用户故事的价值。
（2）在实际工作中，也可能出现这种情况：开发团队某个时间段有空闲，而为了充分利用这段时间，团队可能会去完成一些看似有价值但实际上并不重要的需求。如果发生这种情况，就需要追究PO同学的责任了。
（3）“感觉可以集成测试验证就可以了”，这是在日常开发中常出现的一种心态。技术人员认为自己一直在忙，只要一直忙下去就行，不必考虑需求的价值。虽然用户故事价值问题的主要责任人是PO，但在转向敏捷模式后，技术人员也应该具备团队意识和全栈思维。如果大家所做的需求不能对业务产生正向促进作用，那么大家的工作前景就不容乐观了。因此，用户故事的价值导向不仅是对业务负责，也是对员工负责。技术人员虽然没有闲着，但有可能在做无用功。用户故事的价值属性可以让每个人的工作都具有价值。

13、如何管理拆出的零散用户故事？

采用用户故事地图进行管理，像禅道等市面上的工具中都有相关功能。用户故事地图是一个产品的全景图，可以对用户故事进行可视化管理，可以用不同的颜色标注不同的状态。

14、从瀑布研发模块化开发到敏捷按照Story开发独立交付，对于技术团队的适应和思维方法有什么好建议吗？

这是个很好的问题。这需要敏捷教练对团队进行培训和深入沟通，总结起来就是要让技术团队明白：
（1）采用敏捷模式对于公司有什么好处。
（2）采用敏捷模式对于个人有什么好处。根据我的经验，实际这个更重要。如果技术人员认为转变工作模式对自己没有好处，那他很难长时间保持参与热情。这个需要敏捷教练准备好充分的话术，不要拿大帽子压人，也不要灌过多的心灵鸡汤，就从技术人员的切身利益出发来准备话术。具体哪些是技术人员的切身利益，需要沟通后才能知道，因为每个人的背景不一样，就像富二代和寒门子弟关心的内容大不相同。

送给大家一句话：

用户故事的拆分对于敏捷的推行至关重要，希望大家把用户故事拆分做扎实，如果遇到问题，也欢迎大家通过融平台来“骚扰”我！
发表评论
通过审核后显示您的意见