标签存档: 用户故事

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

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

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

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

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

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

这个前不是一般的前，最好能用几张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%；尚没有任何用户故事的定义能达到如此一致性。

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

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

 

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

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

 

作者：陈勇

本专栏经作者授权开设，专栏文章未经许可不得转载

 

这是敏捷开发用户故事系列的第四篇。

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

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

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

谁负责排序？
Product Owner负责。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 用户故事相关群

2. 迭代计划相关群

3. 日常工作相关群

4. ……

这样的好处包括：

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

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

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

 

作者:陈勇

本专栏经作者授权开设，专栏文章未经许可不得转载