我们为什么要拆分用户故事

    拆分用户故事有两个层面,一是史诗级故事拆分成小故事,二是将小故事拆分成任务。

    一个好的用户故事除了要有其明确的三要素外,还要具有“独立、完整地交付一个用户价值”的特点,以及“规模适中”以确保能在一个迭代内完成。

    继续以“手机导航能进行语音播报”这个用户故事举例。

    从其是否“独立、完整地交付一个用户价值”来看。语音播报可播报的内容很多,比如方向指示、超速提醒、红绿灯提醒等等,这些不同的内容提供给用户的价值都不一样。

    从其规模是否“足够小”来看,语音播报首先要有一个从语音识别引擎,这个需要从第三方引进,进度可控性不高其次,越多的提醒内容需要越多的工作量,开发时间越长,基本上不可能在一个迭代内完成。

    尝试其拆分成如下几个故事(一个技术故事、三个用户故事):

技术故事:集成语音识别引擎,为手机导航提供文字向语音转换的接口。

用户故事1:作为一个驾驶员,我希望手机导航能用语音播放方向指示,以便在交叉路口更安全地通过手机导航了解下一步行驶方向。

用户故事2:作为一个驾驶员,我希望手机导航能用语音提醒超速,以便通过导航即时、安全地了解是否超速。

用户故事3:作为一个驾驶员,我希望手机导航能用语音进行红绿灯提醒,以便我在通过红绿灯时提前减速。

    如上拆解之后,故事规模明显变小,同时每个故事都提供了不同价值,甚至能更清晰地分辨出不同的语音提醒需要在不同的时机进行提醒。史诗级故事拆解成小故事除了能通过“小规模化故事”防止小瀑布,同时也有助于识别出需求的某些细节信息

    经典瀑布式开发中有明确的详细设计阶段,通过这个阶段的活动完成框架、算法、流程、数据结构等设计,为软件编码提供一个最优方案。敏捷开发中没有这个阶段,那敏捷开发是不是就不用做详细设计了?任何形式的软件开发都要做详细设计,敏捷开发也不例外,只是不要求如同瀑布式开发一样输出标准的详细设计文档,敏捷开发可以通过任务分解的方式完成详细设计

    所谓任务分解就是将要开发的用户故事拆分成多个任务,每个任务都能在较短的时间内(不超过一天)完成,完成所有任务后能达到高质量实现用户故事的目的。部分人认为任务很难拆分,甚至觉得没有必要拆分,存在这种思想的人就如同在瀑布式开发中任务不做详细设计一般,设计思路还没有理清就扑入代码的海洋,这种做法写出来的代码质量是可想而知的。

    任务分解除了发挥详细设计的作用,也可用于制定工作计划。分解出来的任务就是在实现故事的过程中要做的事情,每个任务需要的时间就是做这些事情分别需要的时间。从这个角度来看,如果我们无法很好地将故事分解成任务,那我们如何评估故事的规模?大致都是拍脑袋拍出来的,我想这也是我们没法做好迭代计划的原因之一吧。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值