用户故事 | 排定优先级_moscow原则-CSDN博客

本文链接：https://blog.csdn.net/qq_30215957/article/details/103633462

什么是MoSCoW法则

MoSCoW法则是敏捷中一种比较知名的优先级排序法则，其全称是：Must or Should， Could or Would not。

Musthave（Musthave requirement）：必须有。如果不包含，则产品不可行。Must Have的功能，通常就是最小可行产品（MVP）的功能。比如微信的聊天信息、通讯录、朋友圈。
Should have（should have if at all possible）: 应该有。这些功能很重要，但不是必需的。虽然“应该有”的要求与“必须有”一样重要，但它们通常可以用另一种方式来代替，去满足客户要求。
Could have（could have but not critical）：可以有。这些要求是客户期望的，但不是必需的。可以提高用户体验，或提高客户满意度。如果时间充足，资源允许，通常会包括这些功能。但如果交货时间紧张，通常现阶段不会做，会挪到下一阶段做。
Won’t have（would be good to have“wont have the time to do it now，but maybe later”）
：这次不会有。最不重要，最低回报项目，或在当下是不适合的要求。不会被计划到当前交货计划中。总的来说，“这次不会有”在项目讨论阶段，就会被去除。

PO对用户故事优先级的排定

Sprint Backlog在计划会上被确定后，PO要再对这份Backlog做一次排序的确认，排序的原则就是MoSCoW法则，但是PO在实际使用的时候，不需要刻板的拿Must or Should还是Could or Won’t这个概念往上套，而是问自己这么一个问题：

这个用户故事如果这个Sprint做不完，我（以及我所代表的所有stackholder）可以接受吗？

如果可以接受，那就把这个用户故事放到Could or Won’t，否则就放到Must or Should。

假设Sprint Backlog总共有20个用户故事，经过PO的排序后，其中10个被划分到了Must or Should级别（意味着必须做完），10个被划分到了Could or Won’t级别（意味着可以做不完），PO排序完的Backlog类似这样：

类别	用户故事
Must or Should	1、2、3……10等10个必须做完的用户故事
Could or Won’t	11、12、13……20等10个可以不做完的用户故事

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

开发团队对用户故事优先级的排定

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

我们研发的大部分的功能模块，可能都会涉及“增删改查”的功能，做过开发的同学都知道，这几个功能的顺序，一般都是遵从增→查→删/改的顺序来进行的，不做增，是没法查的；不做查，是没法删/改的

因为大部分PO不懂技术，所以他可能会把增或查放到Could or Won’t级别，或者把删/改的优先级放到增/查前面，这就导致如果按照这个优先级的排序来开发，会进行不下去的。

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

所以在PO按照MoSCoW法则排定好他的优先级后（更深层次一点说，应该是按照商业价值来排定的），SM要引导开发团队对这个排序做一次评审，一般我们是按照以下几个点来检查的：

实现依赖

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

团队依赖

如果还有其他团队对我们即将要做的用户故事有依赖，一般这种需求要放在最高优先级。

技能依赖

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

其他

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

但是研发团队的排序前提，是在PO给定的2个大的优先级范围内进行的，原则上只能将低优先级的故事向上提（从Could or Won’t提升到Must or Should），如果要将一个Must or Should的故事降低到Could or Won’t，需要征得PO的同意。

经过研发团队和PO共同排序后，用户故事的顺序可能会大变样，而且Must or Should和Could or Won’t的用户故事数量也会有所变化，类似这样：