敏捷开发用户故事系列之四：优先级排序

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

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

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

谁负责排序？

Product Owner负责。

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

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

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

谁负责拍板？

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

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

研发因素的考虑

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

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

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

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

需求依赖的考虑

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

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

持续交付的考虑

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

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

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

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

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

商业决策的考虑

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

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

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

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

最佳实践：故事群

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

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

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

1. 用户故事相关群

2. 迭代计划相关群

3. 日常工作相关群

4. ……

这样的好处包括：

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

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

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

敏捷开发用户故事系列之五：用户故事的分类

引子

在之一、之二、之三中，我们曾经提到了“作为一个……可以……以便……”的用户故事描述方式，还提到应该如何描述用户故事，才能更好地反映客户价值。

下面请尝试一下描述这两个故事：

1. 如果把“保存按钮”统一放在页面上端而非下面，有些屏幕上侧控件的修改，就无需滚屏即可保存。

2. 所有自定义字段，统一改为4000长度的nvarchar。

第一个勉强可以写为：“作为一个用户，可以方便地点击上端的保存按钮，以便在某些控件修改的时候无需滚屏即可保存”，但是这个故事颗粒度显得过小，开发可能只需要1小时，而在客户眼中，也不应该和“作为一个用户，可以对故事进行增删改查，以便……”放在一起。

第二个故事，则找不到“用户”的位置，因为它是我们自己要做的改进，客户完全可以不感知。

这类故事怎么办呢？

分类

有各种分类方法可以把用户故事重新组织一下，下面这种是我自己做的分类，不是一个成熟的方法。

所以在利用这些方法时，一定要理解其用意而不是方法，这样当自己有别的用意时，就能灵活修改。

我自己在开发一个不大的软件时发现，把所有用户故事罗列在一起显示显然极度混乱，于是做了一个相当大的树形结构来显示。

结果发现尽管屏幕利用率很高了，还是难以一眼看到产品的主要功能，原因就是大大小小的故事都挤在一起，有些是产品的卖点应该让客户看到的，有的是要做的重构只和开发团队有关，有些则介于其中，产品经理需要知道，但又不用告诉客户。

另外同样想给客户看的东西，也有大小差异，比如上面例子中的1，如果在“产品版本更新公告”里边，可以写上；但对新客户而言，就不需要，他们完全可以当作产品原来就是这个样子接受下来。

所以最后我的大致分类维度是：横坐标是向外界展现的程度，纵坐标是颗粒度。颗粒度在一定程度上是“有必要呈现的程度”，就是可以以简繁有别地显示产品功能。

颗粒度维度

所谓文件，就是一组要操作的数据，比如一个要有用户管理的系统，就肯定有“用户，角色，权限……”这些要操作的数据。其特点是文件是系统的使用者能理解的数据，文件都是名词。

所谓操作，就是对某组或多组数据的操作，对一组数据的操作入手“创建角色”“删除用户”，对多组数据的操作如”为用户分配角色“，其特点是操作是系统使用者的业务操作（就是”干活“的操作），操作都是一个动词。

所谓增强，就是此外的用来做定语、状语、补语的内容了。比如开始引子里边的案例1，就是为了用户方便做的东西，既不是用户要管理的数据，也不是用户平时工作的操作。

这个维度，在”客户可见“的层面上理解，非常方便。

比如描述产品有何功能的时候，只需要展示客户可见的史诗和功能。

比如描述产品版本发布描述（升级公告）时，则应该展示发生变化的史诗、功能、增强三者。（缺陷后面谈）

关于这个维度，请参考：http://blog.csdn.net/cheny_com/article/details/6723715。

展现程度维度

除了给客户看的东西，有些东西需要产品经理、开发团队自己知道就可以了。他们所知的范围，向前包括，意思就是说客户能看的，产品经理都能看，产品经理能看的，开发团队都能看。

缺陷有两种，客户提出的，自己发现的。前者要向客户展示（在产品升级公告里边），后者产品经理知道就可以了。

重构则是因为开发的方便性、可维护性、性能、功能的实现方法重新设计等原因引起的内部工作，无需向客户及产品经理透露即可。

债务是开发人员“走捷径”留下的可能出问题的地方。这种“可能出问题”，是指未来的功能、结构发生变化后可能出问题，而不是当前的做每种操作可能出问题（那就应该称为缺陷了）。因此既不需要现在就要改正，也需要留下一个记号日后好查。

实际使用情况

在实际项目里边，我发现这种分类可能会因为项目的不同而不同。比如最近我们想增加三种内部史诗、内部功能、内部增强，因为有些功能是为了内部开发方便做的，而且也有文件、操作、增强的区别。

我们还为不同的故事设置了类似“作为一个……，可以……以便……”的描述模板，但还不是很成熟，日后会分享给大家。

所以，在具体管理中本人也会常常改变分类方法，因此本文的内容日后会发生变化；而大家也应该在每个项目中重新思考以往的分类是否合适。

敏捷开发用户故事系列之六：用户故事的产生与组织结构

一条需求敢跳出来，基本上就能被化成一条用户故事，看完一二三四五，上山打老虎都不怕，这个似乎已经不太难了。

难的是，项目或产品的第一天，给一张白纸：“请列出有哪些故事”。那个时候其实不是大脑空空，而是有千言万语就是说不出。

前年做另外一件事情的时候偶然得到一种方法，去年到今年用在一个敏捷项目上，果然很舒服地列出了大量故事，后来的开发过程证实它们都满足独立交付、可测试、耦合低等特点，属于好故事之列。

引子

这件事情其实在之前的博客中已经多次提到了，就是软件项目的造价管理。注意这里提到的是项目，而非产品研发。项目就是那种一手交钱一手交货的甲乙方项目。

之前曾经提到过：无论有多少种方法对优先级进行排序，作为产品而言，都永远应该把最体现差异化价值观的功能置于万事之前。

这里要说的则是：无论有多少管理方法，作为项目而言，都永远应该把造价估算置于万事之前。

这个前不是一般的前，最好能用几张A4纸的篇幅就搞定，因为一般老板刚去签订合同的时候，手里没有需求，没有设计，没有故事，就这么几张纸。当然另一个尴尬的事情则是：即使有很厚的需求文档了，也仍然没有方法知道要多久才能完成项目，真的很愁人。

其实这两件事说的是一件事：如何在早期列出具有某种表征意义的需求列表。

甚早期的用户故事生成方法

在之前的博客详细描述过了，这里只从产生和组织用户故事的角度谈谈，详情请看文末的链接。

在我们的开发工作中一共有两类东西要开发，一种是数据，一种是操作。

所谓数据，就是比如要编写一个CRM，其中有“用户、角色、权限”这三种东西，就是要管理的数据，这里权且记下用户有“3个史诗故事”要管理。

所谓操作，就是对用户，应该有增、删、改、查、加入角色……这些称之为操作，这里权且记下对用户，用户会有“5个用户故事”。

下面是我们的实际项目的局部截图，课本是史诗，蓝色是故事带括号和加号的是两个合并的故事，箭头是增强请参考上篇故事分类：

史诗都是名词，都是要被管理的核心信息，而且是用户可以理解的信息；

故事都是动词，都是用户平日里使用软件产品所进行的业务操作；

最后一个小贴士是每个史诗故事平均有7个左右的故事，少于4个要怀疑是不是史诗，多于10个要怀疑是不是应该拆分新的史诗了。

最后这条是NESMA 20年来的经验数据，很值得参考但莫较真。比如上面例子分为用户/角色/权限3个史诗对19个故事（平均6.3个），你可以试试再拆拆或合合，效果肯定不如这三个干净。只能说他们20年真没白干。

这个方法听起来很水很模糊，但因为开过几次造价估算培训课，在我经手的3次培训中，通过短短1天培训后，4～5个小组的（最大-最小）/平均 误差只有正负12%，而误差的很大来源，是一个模拟问答环节总是比较嘈杂，很多团队没有注意听答案！@￥#…%！核对需求后，误差可迅速降低到大约一半。课堂练习只有一张A4纸，里边很模糊地隐含了多达90多个用户故事，练习时间只有1小时，能达到如此的一致性已经很满意了。

大尺度上用户故事的组织结构

最早我们在史诗之上，就是无意义的层级式目录结构了，但就像太阳系外有银河系，银河系外有超星系，超星系外有超星系团一样，事情还没有完。

本来以为在史诗之上没有有实际逻辑意义的结构了，但发现“用户角色权限”这三个故事的距离，远远近于其他故事，应该还有一种具有逻辑意义的东西来描述；其他一些史诗故事也发现了这种内聚性，但尚无合理的划分方法将其定义下来。

笔者暂时创造了“故事群”这个概念来描述他们，但没有找到合理的定义，让不同的人可以一致性地划分故事群。

之所以借用功能点分析的概念来产生和组织用户故事，是因为关于用户故事，一直没有非常标准的颗粒度和组织方法；而对于数据、操作，则在接近40年前就开始尝试标准化定义，当前有5个国际标准之多，中国的国家标准也马上出来了。在接受这些标准培训后，不同个体对数据和操作的计数差异，只有不到10%；尚没有任何用户故事的定义能达到如此一致性。

敏捷世界一向有封闭的特性，比如CMMI在尝试拥抱敏捷，但从来没听过敏捷拥抱CMMI的。

不否认创造和使用敏捷开发的一线员工在定义需求、制定计划、每日跟踪中的经验和权威性，但在大尺度上掌握用户故事的组织结构，以及在甚早期判断项目范围的方面，则正是这一人群的弱项。

敏捷方法需要借鉴已有的外界方法。

为什么不用UML方法？因为本人很不熟悉UML。UML比较适合在大尺度上组织用户故事，但很难在甚早期开展（一张A4，隐含90个故事，1小时估完）。

当然这不会抹杀UML在分析用户故事中的作用，日后或许会请另外一位老师写篇文章《用户故事与UML》，我转发过来作为其中一篇，以求完整。