敏捷项目中的24种用户故事拆分方法

所谓的故事,是针对某一项或几项要实现功能的详细描述,什么人,什么时候,做什么事,期待的结果是什么,这个描述清楚了,把里面的所有动词都提炼出来,这就是一个个的“用户故事”。


用户故事拆分是敏捷实施的入门实践,没有用户故事拆分,就没办法做到快速迭代、快速反馈、快速学习和快速价值交付,但故事拆分并不容易,不过没关系,对于用户故事的拆分也是有方法可寻,总结了用户故事拆分的24种方法,希望能给大家带来帮助。


01、根据场景/流程步骤

识别出用户为完成具体工作流采取的特定步骤,然后通过一些增量阶段实现工作流。如果已经能画出具体场景的流程,则可以先从工作流程拆分。该方法也叫作最简路径法,即先拆出最简路径,再基于最简路径添加步骤,直到覆盖完整路径。


例如:作为淘宝用户,我可以在网上买书,这样我就可以在任何地方买书。

• 作为淘宝用户,我可以搜索一本书,以便购买它。

• 作为淘宝用户,我可以挑选书籍加入购物车,以便以后可以付款。

• 作为淘宝用户,我可以查看我的购物车,以便改变主意。

• 作为淘宝用户,我可以查看购物车,以便可以付款。

.......


02、根据不同的业务操作

有些用户故事使用了“管理”、“控制”等词汇,它掩盖了对故事执行的多种操作,大的用户故事可以基于不同类型的操作进行故事拆分。


例如:作为用户,我可以管理我的帐户。

• 我可以注册一个帐户。

• 我可以编辑我的帐户设置。

• 我可以修改我的账户设置。

• 我可以取消我的帐户。

……


03、根据业务规则多样性

考虑用户故事是否存在不同的业务规则,例如,用户故事里是否有像“推荐内容的业务,可以通过不同规则实现,可以先拆分用户故事满足其中一组规则,后续再完善其他规则。


例如:作为有爱心的中国人,我可以购买三十万个口罩捐赠给武汉。

• 作为有爱心的中国人,我可以购买三十万个最贵的口罩捐赠给武汉。

• 作为有爱心的中国人,我可以购买三十万个口罩捐赠给武汉,不区分口罩种类。

• 作为有爱心的中国人,我可以购买三十万个口罩捐赠给武汉,只要N95和KN95级别的。

……


04、根据数据多样性

考虑用户故事是否是针对不同类型数据完成一样的事情,可以先拆分处理一种数据类型,后续再完善其他类型数据。


例如:作为网上银行用户,我想转移我的钱,这样我就可以在任何地方进行交易

• 作为网上银行用户,我可以将钱转入我自己的帐户。

• 作为网上银行用户,我可以将钱转入其他银行账户。

• 作为网上银行用户,我可以进行转账。

• 作为网上银行用户,我可以支付账单。

......


05、根据界面入口多样性

考虑这些用户故事是否有复杂的界面入口,通过不同界面入口获得同一种数据,可以先做一个简单的版本,实现先从一种界面入口获得数据,后续再完善其他的。


例如:作为微信用户,我可以添加好友以便扩大朋友圈。

• 我可以通过摇一摇方式添加好友。

• 我可以通过扫二维码方式添加好友。

• 我可以通过手写输入方式添加好友。

……


06、拆出主要工作

根据主要主要投入或工作量来拆分故事。有时一个故事可以分为几部分,大部分的工作将用于实现第一个故事。


07、简单/复杂

这个故事是否有最简单核心的版本,可以实现大多数用户的价值。可以拆分这个用户故事,先实现最简单核心的版本,再通过其他用户故事来完善功能。


例如:作为有爱心的中国人,我可以购买口罩捐赠给武汉。

简单一句话,涉及的业务可以是购买何种口罩,如何捐赠,给什么机构等,明显不能作为一个故事进行交付,需要拆分。但是业务太复杂,一开始无法全都想清楚,可以先做最基本的,然后再根据方法四的业务规则分类进行扩展。

• (简单)作为有爱心的中国人,我可以购买口罩捐赠给武汉。

• (复杂)在XXX日期购买。

• (复杂)通过不同的运输通道送到武汉。

• (复杂)捐赠给XXX不同的医院。


08、推迟性能实现

是否可以拆分用户故事,先让用户故事基本跑起来,再满足性能方面的需求,如安全性、易用性、可维护性、可靠性等非功能性需求。


例如:作为用户,我希望能能够在1秒内获得查询结果。

• 作为用户,我希望获得查询结果。

• 作为用户,我希望查询结果能够在1秒内获取。


把故事1放入早期迭代,故事2可以尽量晚些,在交付完成前,以排除其他模块可能带来的影响。


09、突破一个尖峰

一个故事比较大不一定因为它复杂,而是由于我们知道的太少。在这种情况下,再多的讨论也不能让我们指导如何拆分它。可以在一定时间内针对怎么实施,先做个探针实验,实验过后,知道了深浅,揭开了面纱,我们往往就知道如何拆分它了。


10、按照用户类型拆分

一些故事服务于多样化的用户社群,可以根据不同的用户角色来进行拆分。


11、按接口来拆分

当用户故事涉及到众多接口,如横跨多种用户交互接口、数据交互接口或者设备接口的时候可以根据这种多样性来进行拆分。


12、通过技术约束来进行拆分。


13、通过关注一个简化的算法来提取一个更小的故事。


14、通过购买一些组件而不是自己构建所有组件来提取一个更小的故事。


15、其他时候,“现成的”解决方案与您的实际情况并不匹配,您花在定制它上的时间可能不如花在开发自己的解决方案上,此时可以通过构建组件来提取一个更小的故事。


16、通过丢弃那些增加麻烦、依赖和供应商锁的技术来提取一个更小的故事。


17、通过用一些手工过程代替完全自动化来提取一个更小的故事。


18、通过将批处理替换为在线处理,提取一个更小的故事。


19、通过用通用名替换custom来提取一个更小的故事。


20、通过减少支持的硬件/操作系统/客户端平台来提取更小的故事。


21、从另一个故事的接受标准中提取一个较小的故事。


22、用“1”代替“all”,提炼出一个更小的故事。


23、通过扫描关键字(如“和”、“或”、“句点”和其他类型的分隔符)来提取一个较小的故事。


24、根据“共性-个性”原则进行拆分

拆分用户故事不仅是要使故事变小,而是将高价值的部分与低价值的部分分开,这样就可以把时间花在有价值部分上。总结一下,用户故事的拆分要遵循两个原则:第一:从上到下,从粗到细;第二:坚持以“用户”的视角看(注:用户可以指一个真实的人类用户,也可以是一个系统,或系统中的一个模块),当然最重要的还有一点,就是一定要讲好“故事”,否则就拆不好。


拆分用户故事很难,好在有方法可用的,这些拆分方法还需多练多用,以致熟能生巧,在面对复杂的用户故事时,可以综合使用多种方法,才能达到事半功倍的效果。


更多内容请关注微信公众号“赛希咨询”

发表评论
留言与评论(共有 0 条评论) “”
   
验证码:

相关文章

推荐文章