敏捷开发一千零一问系列之二十六:如何进行优先级排序?-创新互联


成都创新互联坚持“要么做到,要么别承诺”的工作理念,服务领域包括:成都网站建设、网站建设、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的河西网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!

问题

如何进行优先级排序?具体故事的优先级,和版本规划的优先级之间有何关系?

分析

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

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

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

方案

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

这个是最高级别的优先级排序,排序的预见性大约在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任务更重要。但本人比较倾向于每个迭代集中注意力处理一类功能,而不要零星地掺杂日后的所谓重要的功能。这样可以有效地防止注意力分散导致的生产率下降。

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

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

是否因为“用户”比“部门”优先级更高,而导致“增加用户”比“增加部门”更高,以及“删除用户”比“增加部门”也更高?(注意不是“删除部门”)

另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。


网站题目:敏捷开发一千零一问系列之二十六:如何进行优先级排序?-创新互联
本文网址:http://lszwz.com/article/cshpsj.html

其他资讯

售后响应及时

7×24小时客服热线

数据备份

更安全、更高效、更稳定

价格公道精准

项目经理精准报价不弄虚作假

合作无风险

重合同讲信誉,无效全额退款