这是敏捷开发用户故事系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）

优先级排序听起来是一个很简单的工作，一个字段无外乎“重要/一般……”，调整一下然后按排序，就出来了。

但其实里边有不少名堂：谁应该负责排序工作？谁最终拍板？研发因素要不要考虑？需求依赖关系导致的顺序如何处理？持续交付的考虑？商业决策的考虑？

以下知识与经验，来自于多个来源，主要是部分网上资料、实际项目的访谈，并在自己现在正在做的一个项目中得到验证。具体应用时，应灵活掌握。

谁负责排序？

Product Owner负责。

在产品研发环境中，一般是产品经理；在项目开发环境中，一般是项目经理。

作为产品或项目的掌舵人，这个人必须对产品或项目的概貌非常了解，从业务概貌到业务细节，都应该了解。从业务这一点上说，了解程度要超过研发团队本身。

有些团队把排序工作交给客户，非常不妥。客户任何时候都只是浅层参与，随时可能会懒散、不专心，因此不要尝试把主动权交给他们。即使此事必须通过客户，也要有内部相应的人加以把控，判断排序的真实性。

谁负责拍板？

要想既了解概貌，又了解细节，对产品经理（以下略去项目经理的情况）而言要求过高，这时候一般配备产品总监，以在更高的层面把控方向。

产品总监的工作更倾向于长远化、市场化、人性化。比如很多消费电子类产品的产品经理负责研究新潮的功能，而产品总监则负责研究“使用这些功能的新潮的人”。

研发因素的考虑

尽管一心一意希望按客户价值排序，但实际情况是往往制约于产品功能的技术实现和依赖关系，不得不做变通。

因此，应该考虑研发团队的介入。

什么？客户，产品经理，产品总监，研发团队……导致谁说了算？说对了，这时候一般需要“产品负责人团队”，即PO团队。

第一次听到这种团队，是看一个国外游戏团队的开发经验。他们的产品负责人团队，他们引入了自己公司的高层、策划人员（即需求开发和管理人员）、开发人员、发行商、热心玩家等等，最终工作由主策划（产品经理）汇总。

需求依赖的考虑

其实多数需求依赖都可以被避开，比如没有“删除功能”，在开发的初期，一样可以登录数据库直接暴力删除。

但是这个会带来以后的问题，比如要持续交付，这个让客户怎么用？更深入的问题，下面继续谈。

持续交付的考虑

上次在MPD做培训的时候，有人问到一个问题大致如下：“我们是持续交付了，但是刚开始的产品缺胳膊少腿，界面也不美观，客户看了直摇头，对我们印象很差，该怎么办？”忙了半天才做到持续交付，居然起到反作用。

这里边其实发生的最大的问题是：一定要从客户的角度理解可运行软件和持续交付，而不要从开发角度！

从开发角度看，上了持续集成系统，每天有一个EXE或DLL生成，就可运行了，可持续交付了，其实大错特错。

比如做一个敏捷开发管理软件，从第一分钟，就是可以运行的软件；但估计要做出可以填写、展示用户故事，无论如何也要到第二周；而要最后卖掉，怎么也得有“用户和权限”这些次要功能。把这些所谓“次要功能”做出来之前就给客户，而又未能向客户说明，极有可能适得其反。

当然一种做法是：把“登录功能”提前呗，不就从第一天就能真的给客户了？不。

商业决策的考虑

作为产品而言，永远应该把最体现差异化价值观的功能置于万事之前，也就是三个月内要决定产品是否值得做，六个月内决定产品的主要功能及投入多少人力，九个月到一年的时候，就发布了（这里边的时间点仅为举例，需灵活掌握）。因此千万不要把登录功能这类大路边的功能做在前面，会积压大量资金人力并大大推迟决策点。

比如某家游戏企业，为了能提前获知游戏是否好玩，以平台化的方法做出了很多基本的能登录、能玩、能买卖、有图片的游戏，新团队只需要在上面做出核心玩法，即可提供高层做出是否继续的判断。

提前做体现价值观的功能，或做出平台加速核心功能开发，都是为了更早给出决策。

项目开发的情况，本人遇到的比较少，但是显然不应该从在开始做那些路边的功能。

最佳实践：故事群

所谓故事群，是在观察一些团队及自己亲自实践的结果。

故事群接近史诗故事的概念，即将故事按照每个故事群交付后，客户可完整操作部分功能的方式，将若干个故事归入一群，并尝试在每个迭代中实现一群，交付或展示给客户。

比如如果做一个敏捷开发软件，则可能规划如下的群：

1. 用户故事相关群

2. 迭代计划相关群

3. 日常工作相关群

4. ……

这样的好处包括：

1. 每个群交付后，局部的功能比较齐全，客户可以较为完整地使用，从而可针对某类功能集中地给以反馈。

2. 由于这些功能整体在说一件事情，客户和开发人员的精力比较集中，能把一件事情想得比较透彻。

当然，这种方法对产品经理的工作能力还是有要求的，否则一个一个群之间很难衔接顺畅。

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》