敏捷开发里边有很多地方需要多次进行优先级排序，本文将探讨其不同的应用场景，及其关系。
值得注意的一点是，敏捷开发中有无数的“自相似性”，比如估算，每年、每月乃至每天人们都在潜移默化地估计自己的任务；又如计划，也是每年每月每天都有成文或不成文的计划；而发布，也是每个故事自成单元，而又与其他的故事构成每月的交付，进而形成几个月的大版本交付……
由于这些自相似的活动颗粒度不同，一定不要认为只要做一次就可以了，也不要认为用一种方法做就可以了。要就具体活动思考这一活动的目标是什么，以及如何才能更好地达成这一目标。
方案
产品路线图级别的版本优先级排序
这个是最高级别的优先级排序，排序的预见性大约在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）
