在Scrum中,任务细分有几个必须要遵守的基本原则:
1、 子任务必须小于5小时
主要是为了每天都能看到进展。
2、 子任务必须是可检视的
对所有人都要可检视,包括不懂开发的人。
3、 子任务间必须相对完整独立
即完成1个后,可以选择延期或放弃下1个任务;完成的步骤是逐个逐个完成的。
4、 多个子任务要进行排序,要区分轻重缓急
先做必需的功能特性,然后再做其他高级特性
基本原则看起来很就简单,但是很多开发人员细分任务时,还是很难准确把握。1、4两个原则很容易懂,不用过多解释。对于难于把握2、3两个基本原则,本文将逐个来分析,帮助大家很好的理解它们、运用它们。
一、如何做到任务可检视
开发人员习惯于从开发的视角细分任务,很多时候会出现细分后的任务是不可检视的。
类似下列的任务,不懂技术的人基本无法检视。就算是开发人员,如果没有详细阅读代码,也不知道到底完成没有。这种情况应该尽量避免:
1) 完成xx框架
2) 完成xx公共类
3) 完成xx逻辑
举例说明:任务细分实例1
“报损单逻辑”这个任务项,明显是不可检视的。你说你做完了,如何展现,我从哪里看的出来,又怎么检查?
按照对最终用户可见的功能或功能特性来划分来看能否解决问题:
报损单统计基本查询(条件,查询结果) 4小时
报损单统计列表功能 2小时
报损单统计明细账本功能 1小时
报溢单统计 1小时
调拨单统计基本查询 4小时
调拨单统计列表功能 2小时
调拨单统计明细账本功能 1小时
这样的划分的好处,所有人都知道子任务的实现目标,也很好验证你是否完成了。
特别提醒一点:因为使用的是业务上的通用语言,不管是开发、还是测试,甚至客户都能很好的沟通。
二、为什么要做到任务相对完整独立、如何做到
任务相对完整独立的好处分析
1、就拿修改后的实例1做法来说,各个任务相对独立,我们随时都有一个接近交付的程序。因为如果有时间问题,我们完全可以在本次发版中舍弃高级功能,马上就能进入测试。
2、如果子任务间无法做到相对独立就不可能做到这一点,比如必须完成3个子任务,才能拼成一个可交付的功能。除了不能灵活的放弃某些高级功能外,还需要面对的是很长时间都看不到实际可运行的结果,这样会加大出现偏差的风险。
在实例1中,界面和逻辑的细分法,实际上就是没有做到相对完整独立。它们各自不是完整功能,更谈不上独立。按照功能特性重新细分后,就满足了相对完整独立的要求。比如,我们做完报损单的基本查询后,发现没有时间了,这时完全可以不做后面的。
这个例子中没有做到完整独立很清楚,但是实际上还有另外一种形式也会影响任务的完整独立性:
一个人手中有多个任务,任务的划分也很合理(可检视、相对完整独立、有排序、小于5小时),但是他在开发的时候因为几个任务都是改同一个模块,就把几个任务同时进行了。这种情况实际上是实现层面上的没有分开,开发人员把它们当做是一个任务了。既然没分开,那么上面的好处自然就没有了。
几个任务同时进行的实例:
三、从上面分析中抽出三个附加执行原则
1、按照对最终用户可见的功能或功能特性来细分
2、使用业务通用性语言来描述,便于沟通
3、一个人同一时间只进行一个任务。
目标就是要达到:可检视、相对完整独立、有排序、小于5小时