使用MoSCoW法则排定Sprint Backlog的优先级 | IDCF

咱们在敏捷开发中一直强调要将Backlog按优先级排序，迭代的时候也严格按照这个优先级来开发，这样就能够保证咱们当下是在交付最高价值的用户故事（User Story，如下简称US）了，就像下图这样，最高优先级的故事最早被完成：

可是咱们不少团队实际的迭代过程倒是下图这样的，高优先级的故事未被完成甚至并未开始，可是低优先级的故事已经开始甚至已经完成了：

那咱们应该怎样对Sprint Backlog进行排序，才能让高优先级的故事最早被完成呢？本文将介绍一个优先级排序工具：MoSCoW法则，来帮助你们对Sprint Backlog作出一份合理的优先级排序。

1、什么是MoSCoW法则

1.1 MoSCoW中的四个大写字母

MoSCoW的四个大写字母，M、S、C、W分别对应如下四个词汇的首字母：

• Must have：必须有。

若是不包含，则产品不可行。Must have的功能，一般就是最小可行产品（MVP）的功能。

• Should have：应该有。

这些功能很重要，但不是必需的。虽然“应该有”的要求与“必须有”同样重要，但它们一般能够用另外一种方式来代替，去知足客户要求。

• Could have：可能有。

这些要求是客户指望的，但不是必需的，而且能够以不多的成本改善用户体验，或提升客户满意度。若是时间充足，资源容许，一般会包括这些功能。但若是交付时间紧张，一般现阶段不会作，会挪到下一阶段作。

• Won’t have（this time）：（此次）不会有。

最不重要，最低回报的项目，或在当下是不适合的要求。不会被计划到当前交付计划中。“（此次）不会有”的需求会被删除，或被放入Product Backlog以便之后的Sprint从新考虑（注意：有些地方会使用Would like to have这个术语，可是这种用法是不正确的，由于最后这个优先级清楚地代表有些需求超出了本次交付的范围）。

1.2 MoSCoW中的两个小写字母

MoSCoW法则中，除了上述四个词汇的首字母外，还有两个o，这两个o是作什么的？
其实莫斯科法则的全称是：

Must or Should, Could or Won't.

为何Must和Should中间有一个or，Could和Won't中间也有一个or，而Should和Could中间却没有？是否是老外为了读起来有朗朗上口的感受，特意这么设计的？

其实不是的，真实缘由是由于要区分一个US是Should have仍是Could have是很容易的，可是要区分一个US是Must have仍是Should have，或者是Could have仍是Won't have的时候，不一样的人会有不一样的见解，即便是同一我的，不一样时间、不一样环境下看同一个US，也可能会得出不同的结论。这段描述是否是看得有点头晕？不要紧，举个例子你应该就明白了：

假设一个电商APP有如下2个US：

1.做为一个电商APP的用户，我想注册一个帐号，以即可以买到我心仪的商品。（如下简称注册帐号）

2.做为一个电商APP的用户，我想编辑个人我的资料，以即可以个性化个人我的信息。（如下简称编辑资料）

若是从Should have仍是Could have的角度来划分以上2个US，大家会得出怎样的判断？

我在公司组织过一个10人的小组投票，结果以下：

投票结果几乎是一边倒，注册帐号是应该作的（Should have），编辑资料是能够作的（Could have）。

而后我又问了如下两个问题：

注册帐号是必须作的（Must have），仍是应该作的（Should have）？

编辑资料是可能作的（Could have），仍是可能不作的（Won't have）？

而后你们就吵起来了。

好比关于注册帐号的争论以下：

甲：没有注册功能，我怎么知道是哪一个用户下的单呢？因此我以为是Must have。

乙：干吗非要有个注册功能呢？用户能够用三方帐号受权登陆啊，好比微信或微博受权登陆不就能够了吗？因此我以为注册功能不是Must have，应该是Should have。

甲：登陆功能强依赖第三方APP，会被App Store拒绝上架的。

乙：那能够接入苹果帐号的受权登陆啊！

甲：那Android和网页版怎么办呢？

乙：那能够用微信受权登陆啊！

甲：那工做量岂不是比开发一个注册功能还要大！

……

一样，编辑资料这个US也是各有各的理解，可是谁也不能说服对方。

各位同窗看到这，应该就明白了MoSCoW法则中的那两个o的做用了吧，四个字归纳就是：

求同存异

一个US，只要肯定它是Must or Should仍是Could or Won't，而不用细化到Must、Should、Could仍是Won't。

这里插个题外话，以前一个咨询公司的副总在给咱们最敏捷导入培训的时候，谈起敏捷宣言的诞生过程，他说了这么一个小故事（不知道真假，你们看看就好）：

当年那17位敏捷大师在犹他州的滑雪场聚会的时候，他们一开始是想定一个你们都承认的实践方案的（好比相似Scrum、Kanban、XP等），可是发现分歧实在太大了，每一个人都认为本身的实践方案是最优的，后来你们实在谈不下去了，因而就退而求其次，你们发现每种实践方案的指导思想基本都是一致的，因此就抽象出了一份《敏捷宣言》。

MoSCoW法则其实有点相似《敏捷宣言》的诞生过程，既然细节处没法达成统一，那咱们就再向上抽象一层吧。

2、Sprint Backlog优先级的肯定

2.1 PO使用MoSCoW法则对Sprint Backlog排定优先级

在对Product Backlog的高优先级的故事进行梳理和估算以后，PO须要在Sprint计划会以前再对这份潜在的Sprint Backlog作一次优先级的排序，排序的原则就是MoSCoW法则。PO在实际使用这个法则的时候，其实不须要刻板的拿Must or Should仍是Could or Won't这个概念往上套，而是问本身这么一个问题：

这个US若是本次Sprint作不完，我（以及我所表明的利益相关者）能够接受吗？

若是能够接受，那就把这个US放到Could or Won't，不然就放到Must or Should。
假设Sprint Backlog总共有20个US，通过PO的排序后，其中10个被划分到了Must or Should级别（意味着必须作完），10个被划分到了Could or Won't级别（意味着能够作不完），PO排序完的Backlog相似这样：

表1 PO排序后的用户故事列表

至此，PO对优先级排序的主要工做就结束了，可是，这样就算完成了吗？

2.2 开发团队对Sprint Backlog排定优先级

此时PO已经使用MoSCoW法则对Sprint Backlog作了优先级的排序，可是这个排序是PO是从“必须作完”和“能够作不完”的角度给的（准确的说，只能算是个分类），大部分状况下，研发团队并不能严格按照这个顺序来开发，举个常见的例子：

咱们研发的大部分的功能模块，可能都会涉及“增删改查”的功能，作过开发的同窗都知道，这几个功能的研发顺序，通常都是听从增→查→删/改的顺序来进行的，不作增，是无法查的；不作查，是无法删/改的（手动操做数据库除外）。

由于大部分PO不懂技术，因此他/她可能会把增/查放到“能够作不完”的分类中，而把删/改放到“必须作完”的分类中；或者把删/改的优先级放到增/查前面，这就致使若是按照这个优先级的排序来开发，会致使研发的同窗进行不下去的。

这里再插个题外话：

程序员跟产品经理常常互怼，本质上是由于这两个群体的思惟方式彻底不同：在拿到一个需求以后，技术思惟想的是：这个需求好实现么? 实现起来须要多长时间？这样操做会不会有性能问题，之前的代码支持这个功能可能须要重构，那咱们赶忙团结起来，把这个需求怼回去。

而产品思惟是这样的：这个需求是用户须要的么？解决了用户的什么痛点？能带给用户什么样的价值？功能上线后会给咱们带来多少商业利益？我思考了这么多问题才设计出来这么优秀的产品方案，大家一帮程序员赶忙给我作出来，不要跟我哔哔什么技术细节！

总之一句话，技术思惟可能是以自我为中心的，而产品思惟是以用户为中心的。这一点致使在Backlog优先级的划分上，两边也会存在分歧。而Sprint计划会，正是解决这个分歧的最佳时机，而促成解决这个分歧的人，就是SM。

因此在PO按照MoSCoW法则作好优先级的分类后，SM要引导开发团队对这个分类再作一次评审，通常咱们是按照如下几个点来检查的：

• 实现依赖

好比上面提到的增删改查的技术依赖，被依赖的功能要排在高优先级。

• 团队依赖

若是还有其余团队对咱们即将要作的US有依赖，通常这种需求要放在最高优先级。

• 技能依赖

这点在成熟的敏捷团队可能影响会比较小，可是若是团队里大部分红员还达不到一专多能的要求，你们还都是只会一门技术，好比J2EE、Android、iOS、Web等，那在排定优先级的时候，也要考虑一下技能的依赖，好比一个团队有2个Web研发，1组APP研发（Android+iOS）（注意，Scrum中的研发团队是没有严格的职位区分的，我这里说的是早期的敏捷团队，他们刚从传统的职能部门转成跨职能团队，不少人早期都只会一门技术），那在排定Backlog优先级的时候，最好是按照2个Web故事→1个APP故事→2个Web故事→1个APP故事……这样的顺序来排定。

• 其余

有时也须要考虑一下特殊状况，好比有人会请假、某个故事难度比较大（也就是估点较多）等。

有一点请注意：研发团队的排序前提，是在PO给定的2个大的分类范围内进行的，原则上只能将低优先级的故事提到高优先级上（从“能够作不完”提高到“必须作完”），若是要将一个“必须作完”的故事下降到“能够作不完”，须要征得PO的赞成。

通过研发团队和PO共同排序后，US的顺序可能会大变样，并且“必须作完”和“能够作不完”的US数量也会有所变化，相似这样（注意和表1对比）：

表2 PO和研发团队共同排定的优先级顺序

至此，Sprint Backlog的优先级排序工做所有完成。

3、一些特殊状况的补充说明

每一个敏捷团队的人员组成都是不同的，技能也是不同的，作的事情也是不同的，因此上面的方法可能也不是适用于每一个团队，可是有些特殊状况，仍是有些应对方式的。

3.1 项目要求和研发技能不匹配

这是咱们常常遇到的一个问题，就是咱们要作的事情，可能以咱们团队目前的人员配置，并非最合适的，好比咱们团队有2个很厉害的APP研发，可是咱们要作的项目并无APP的任务，那怎么办呢？

个人作法是鼓励你们再学习一门新的知识，在一个氛围良好、沟通顺畅、充满心理安全感的团队中，团队成员是不排斥、也不害怕学习新知识的。（关于如何创建团队的心理安全感，之后我会单独写一篇文章介绍的。）

那一个研发人员，须要学习多长时间才能上手一门新技术呢？

这个问题没有明确的答案，小程序可能一周就上手，Android转Java可能也就一、2周，可是这个也要看这个研发同窗以前的经验如何，若是是个大神，可能上手更快，若是是个菜鸟，那可能时间要翻倍，甚至更多。可是无论怎样，有一点SM必定要注意：

全部的学习任务，都要当作“学习型”US，放到Sprint Backlog中，而且设置明确的验收标准（AC），好比：

做为研发人员，我想看完《XXX从入门到放弃》，以便掌握XXX的基础知识。

做为研发人员，我想使用X编程语言模仿Y作一个Y demo，以便促进我更好的掌握X的知识。

学习型US，也同样贴到Scrum板，每日站会的时候跟踪进度。以我我的的经验，即便是学习一项全新的知识，2个迭代（4周）基本也就能上手了。

3.2 每一个迭代开始前，都要从新评估Poduct Backlog中全部US的优先级

我在文章开始的时候举了个例子：

做为一个电商APP的用户，我想编辑个人我的资料，以即可以个性化个人我的信息。（如下简称编辑资料）

这个US大部分人都选了Could or Won't的优先级，也就是这条是“能够作不完”的，可是咱们能够看下淘宝、京东等主流的电商APP，他们都是有编辑资料这个功能的，并且功能作得还都特别完善。那为何我当时调研的人大都选择了“能够作不完”，而淘宝、京东他们却不约而同的都作了个这么尽善尽美的编辑资料功能呢？难道是咱们的判断标准跟他们不一致？

其实不是判断标准不同，而是编辑资料这个功能对于一个刚起步的电商软件和一个成熟的电商软件的价值不同：

假设电商APP的用户中有1%的人想要用这个功能，那在项目早期，可能日活（DAU）也就几10、上百人，即便发展到成千上万人，可能也不会影响到多少用户。可是若是咱们项目的DAU达到十万、数十万甚至百万级别了，那影响到的用户可能就要达到几千甚至上万人了，到了这个时候，编辑资料这个US的价值就大大提高了，若是到那时这个需求尚未作，PO就要在合适的时间点，将这个US挪到“必须作完”这个级别了。

关于产品不一样时期的用户需求的区别，你们能够看下《精益创业》中关于种子用户、主流用户的描述，以及《跨越鸿沟》里的创新者、早期使用者、早期大众、末期大众和滞后者模型，可能会对PO的决策有所帮助。

3.3 其余

因为每一个人的从事的工做不一样、所在的团队不一样、团队成员的水平也不一样，因此可能还有一些个性化的状况没有谈到，你们若是有问题，能够留言一块儿讨论下。

最后但愿你们带领的每一个团队都能有一个完美的迭代过程！

来源：小船哥说敏捷

做者：adoudou

声明：文章得到做者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原做者有其余考虑请联系小编删除，致谢。

IDCF DevOps黑客马拉松，首创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合，2021年仅有的3场公开课，数千人参与并一致五星推荐的金牌训练营，追求卓越的你必定不能错过！关注公众号回复“黑马”便可报名

北京：7月24-25日上海：9月11-12日深圳：11月20-21日