咱们在麻利开发中始终强调要将Backlog按优先级排序，迭代的时候也严格依照这个优先级来开发，这样就能够保障咱们当下是在交付最高价值的用户故事（User Story，以下简称US）了，就像下图这样，最高优先级的故事最先被实现：

然而咱们很多团队理论的迭代过程却是下图这样的，高优先级的故事未被实现甚至并未开始，然而低优先级的故事曾经开始甚至曾经实现了：

那咱们应该怎么对Sprint Backlog进行排序，能力让高优先级的故事最先被实现呢？本文将介绍一个优先级排序工具：MoSCoW法令，来帮忙大家对Sprint Backlog做出一份正当的优先级排序。

一、什么是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法令其实有点相似《麻利宣言》的诞生过程，既然细节处无奈达成对立，那咱们就再向上形象一层吧。

二、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.1 我的项目要求和研发技能不匹配

这是咱们常常遇到的一个问题，就是咱们要做的事件，可能以咱们团队目前的人员配置，并不是最合适的，比方咱们团队有2个很厉害的APP研发，然而咱们要做的我的项目并没有APP的工作，那怎么办呢？

我的做法是激励大家再学习一门新的常识，在一个气氛良好、沟通顺畅、充斥心理安全感的团队中，团队成员是不排挤、也不害怕学习新常识的。（对于如何建设团队的心理安全感，当前我会独自写一篇文章介绍的。）

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

这个问题没有明确的答案，小程序可能一周就上手，Android转Java可能也就1、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）也就几十、上百人，即便倒退到成千上万人，可能也不会影响到多少用户。然而如果咱们我的项目的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日