如何进行优先级排序

敏捷开发里边有很多地方需要多次进行优先级排序,本文将探讨其不同的应用场景,及其关系。

值得注意的一点是,敏捷开发中有无数的“自相似性”,比如估算,每年、每月乃至每天人们都在潜移默化地估计自己的任务;又如计划,也是每年每月每天都有成文或不成文的计划;而发布,也是每个故事自成单元,而又与其他的故事构成每月的交付,进而形成几个月的大版本交付……

由于这些自相似的活动颗粒度不同,一定不要认为只要做一次就可以了,也不要认为用一种方法做就可以了。要就具体活动思考这一活动的目标是什么,以及如何才能更好地达成这一目标。

方案

产品路线图级别的版本优先级排序

这个是最高级别的优先级排序,排序的预见性大约在3~5年左右;排序者一般是产品总监等高级管理者;其排序的对象一般不是用户故事,甚至不是功能模块,而是产品线和产品。

排序思路大致是:不同的用户群需要不同的功能 > 因此导致产品应该面向客户群开发 > 识别出当前最重要的客户群规划下一个产品 >  即使相同的客户群也需要逐步为其提供服务 > 根据客户的业务计划或用户的消费习惯制定产品的版本方案。

如果对此特别感兴趣,请参考文末的链接。

应该注意的是,往往公司缺少产品总监的职位,或者虽然有但是极少对中长期的产品规划进行计划,所以很多时候中层的产品经理也需要思考这个问题。

版本内部的迭代优先级排序

这个是中等级别的排序,排序的预见性大约在6~10个月左右;排序者一般是产品总监和产品经理;其排序的对象大约是模块及史诗故事级别。

史诗故事

先说说什么是史诗故事。敏捷开发里边定义史诗故事是一些“比较大”的故事,但没有定义其绝对的尺度。火星人认为,“业务数据”是一种很好的史诗故事尺度,比如我们说:一个产品(假设就是敏捷开发管理工具)要管理下面的数据,请问在半年的开发周期中,应该先开发哪些?

用户故事,优先级,用户故事树……迭代开发Sprint Backlog,迭代计划会……人员,角色,权限……部门,团队,小组……

我们就可以说,这样规划吧:

第一个月:用户故事,优先级,用户故事树……

第二个月:迭代开发Sprint Backlog,迭代计划会,任务分配Assignment……

第三个月:人员,角色,权限……

第四个月:部门,团队,小组……

……

第N个月:整合并发布一个版本

注意在这个尺度上,我们几乎不讨论具体的操作(比如对“用户”,应该有增删改查等操作),而只会讨论对哪些业务数据进行操作,这非常符合人们的工作习惯。

这种名词性质的业务数据,就可以当作合理的史诗故事来看待。

模块

而如果观察每个月的内容,会发现他们比较相关,比如“人员,角色,权限”这三个功能,如果把它们分散到不同的迭代中,很难单独开发。

这类强烈相关的业务数据,就可以称之为“模块”,划分的依据仍然是业务。

尽管很难让每个Sprint与一个模块一一对应,但应该建立这种意识,即每个迭代应该开发相对集中的一个或多个模块。

迭代排序依据

也就是怎么决定哪个模块或史诗故事优先开发。人们习惯性地会根据依赖关系来开发,但这不是一个好习惯。

比如,有人认为若系统连登录都不能,谈何继续工作,于是就是把“人员,角色,权限”放到首位,然后很可能会是“部门,团队,小组”,这样万事俱备之后,就能很好地开发用户故事、任务分配这些功能了。其实这种做法十分不妥。

第一个可能出现的问题是:由于还没有开发业务,所以其实很难说清楚需要什么样的人员、角色、权限管理办法才能支撑业务。

第二个问题更为突出:在第二个月完成的时候,其实我们针对业务什么都还没做,造成高层领导很难理解我们的进度,在投资、招人这些事情上会犹豫不决,因为我们已经完成的功能很难帮助他下结论。

在新产品研发的过程中第二个问题尤为突出,高层心急如焚急需知道产品的竞争力,而我们正不紧不慢地搭建底层架构。

所以正确的做法是:先从核心业务入手,进行优先级排序。

没有人员、角色、权限,那就大可让每个人无需登录就可以管理用户故事、优先级、用户故事树等;没有部门、团队,那就大可先认为只有一个团队,日后再支撑多团队。

总之,先把核心业务做出来,判断产品优劣之后再说。

迭代内的用户故事排序

这个是具体开发级别的优先级排序方法,排序对象是敏捷开发的用户故事;排序人员是产品经理(PO);排序依据是“此功能在此版本中完成的必要性”。

排序依据

值得注意的一点是:此功能很重要,不等于此功能必须在这个迭代中完成,它很可能只要在版本发布前完成开发就可以了(当然,越重要就越要在早一点的迭代中实现)。那么到底依据什么排序呢?

还是““此功能在此版本中完成的必要性””。这句话看起来很抽象,但是举一个例子就比较清楚了。

假设这个迭代做“用户,角色,权限”,那么应该先做哪些用户故事?注意这里要探讨具体的用户故事了,而非这三个史诗故事。

多半有这么几个用户故事:

增加用户,删除用户(不小心写错了用户名,而又不能修改),编辑用户(的邮件),批量增加用户,冻结用户(保留记录但禁止登录)……

增加角色,分配角色到用户,编辑角色(编辑角色的名字但不修改其权限),删除角色……

增加权限,分配权限到角色(透过角色进而分配到用户),分配权限到用户,删除权限……

可以看出有几个操作几乎是必需的:增加用户,批量增加用户,冻结用户,分配角色到用户,分配权限到角色。

而另外几个可能不太需要,比如:增加角色(可以先写死几种常见的角色),编辑角色(先写死日后再提供修改功能),增加权限……

还有几个几乎可以在早期版本中不要,比如:删除角色,删除权限(这个是基于火星人产品的实际情况分析的,读者的产品或许不同),虽然有了更好。

MoSCoW

有了大致的概念,MoSCoW是一种具体的操作方法来帮助我们实现。它是这几个词的缩写:

Must:这个迭代一定要做的。比如前面提到的“必需”的功能。

Should:应该做,但若没时间就算了。比如前面提到的“不太需要的”功能。

Could:不太需要的,但有了更好。比如前面提到的“几乎早期版本中不要”的功能。

这样,所有人就知道这个迭代中应该先做什么了。不过,这和大家真的会这样做还有点距离,经常需要一些技术手段,比如在故事板上,把TODO的任务按MoSCoW写在不同底色的故事卡片上,在真正完成M和S之前,不准开工W的任务。

值得注意的一点是,MoSCoW可以认为是一种思维方式,可以处理所有自相似的优先级排序问题,未必只是迭代内的(尽管它的设计初衷是)。

处理灰色地带

“如果我真的有时间,应该做那些Could的任务,还是干脆做下一个迭代的Must的任务?”这真是一个问题。

理论上说,下一个迭代Must的任务比这个迭代的Could任务更重要。但本人比较倾向于每个迭代集中注意力处理一类功能,而不要零星地掺杂日后的所谓重要的功能。这样可以有效地防止注意力分散导致的生产率下降。

如果你不太喜欢这个结论,其实更应该尝试一下流开发(日后会有详细描述)。流开发需要的管理模式对人的要求更高,但用好了可以应对很多这类问题。实际上火星人采用的就是流开发,而非迭代式开发。

不同优先级之间的继承关系及处理优先级变更

是否因为“用户”比“部门”优先级更高,而导致“增加用户”比“增加部门”更高,以及“删除用户”比“增加部门”也更高?(注意不是“删除部门”)
我们自己尝试的结果是:不一定。

尽管继承关系大致存在,但用户故事很难干净地从史诗故事继承优先级;而迭代也很难从版本直接继承。

所以要把精力放在实际业务上,而不要尝试找到万能方法。

另外,我们经常在几个月后发现原来一个本来认为不太重要的功能,还是必要的。为了处理这种不断的问题,我们会定期安排一个迭代,称之为“优化……”或“重构……”迭代,其中包含了处理遗漏的功能,还包括性能优化等其他事务。

有了这个迭代,就不是太担心偶然出现的优先级错误。另外也不必太担心这个迭代中处理的事情太杂乱而无从下手:是的,前面说过尽量只做几个有限的史诗故事来保证注意力集中,那是因为刚开始做版本的时候,大家不可能对所有故事都熟悉,同开始太多的事情会让大家更加混乱;但在版本的末期,所有事情都相对熟悉了,这种内容发散的迭代影响不大,反而能帮助大家重新整合和整体思考一下不同的功能。

作者:陈勇

(本文来自于陈勇的博客,原文地址:http://blog.csdn.net/cheny_com/article/details/8046966