Scrum项目开发中如何做好任务细分

在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小时