这是敏捷开发用户故事系列的第五篇。
引子
在之一、之二、之三中，我们曾经提到了“作为一个……可以……以便……”的用户故事描述方式，还提到应该如何描述用户故事，才能更好地反映客户价值。
下面请尝试一下描述这两个故事：
1. 如果把“保存按钮”统一放在页面上端而非下面，有些屏幕上侧控件的修改，就无需滚屏即可保存。
2. 所有自定义字段，统一改为4000长度的nvarchar。
第一个勉强可以写为：“作为一个用户，可以方便地点击上端的保存按钮，以便在某些控件修改的时候无需滚屏即可保存”，但是这个故事颗粒度显得过小，开发可能只需要1小时，而在客户眼中，也不应该和“作为一个用户，可以对故事进行增删改查，以便……”放在一起。
第二个故事，则找不到“用户”的位置，因为它是我们自己要做的改进，客户完全可以不感知。
这类故事怎么办呢？
分类
有各种分类方法可以把用户故事重新组织一下，下面这种是我自己做的分类，不是一个成熟的方法。
所以在利用这些方法时，一定要理解其用意而不是方法，这样当自己有别的用意时，就能灵活修改。
我自己在开发一个不大的软件时发现，把所有用户故事罗列在一起显示显然极度混乱，于是做了一个相当大的树形结构来显示。
结果发现尽管屏幕利用率很高了，还是难以一眼看到产品的主要功能，原因就是大大小小的故事都挤在一起，有些是产品的卖点应该让客户看到的，有的是要做的重构只和开发团队有关，有些则介于其中，产品经理需要知道，但又不用告诉客户。
另外同样想给客户看的东西，也有大小差异，比如上面例子中的1，如果在“产品版本更新公告”里边，可以写上；但对新客户而言，就不需要，他们完全可以当作产品原来就是这个样子接受下来。
所以最后我的大致分类维度是：横坐标是向外界展现的程度，纵坐标是颗粒度。颗粒度在一定程度上是“有必要呈现的程度”，就是可以以简繁有别地显示产品功能。
| 颗粒度 | 客户可见 | 产品经理可见 | 开发团队可见 | ||
| 产品功能描述 | 数据级别 | 史诗 | |||
| 操作级别 | 功能 | ||||
| 版本发布描述 | 增强级别 | 增强 | 外部缺陷 | 内部缺陷 | 重构 债务 |
颗粒度维度
所谓文件，就是一组要操作的数据，比如一个要有用户管理的系统，就肯定有“用户，角色，权限……”这些要操作的数据。其特点是文件是系统的使用者能理解的数据，文件都是名词。
所谓操作，就是对某组或多组数据的操作，对一组数据的操作入手“创建角色”“删除用户”，对多组数据的操作如”为用户分配角色“，其特点是操作是系统使用者的业务操作（就是”干活“的操作），操作都是一个动词。
所谓增强，就是此外的用来做定语、状语、补语的内容了。比如开始引子里边的案例1，就是为了用户方便做的东西，既不是用户要管理的数据，也不是用户平时工作的操作。
这个维度，在”客户可见“的层面上理解，非常方便。
比如描述产品有何功能的时候，只需要展示客户可见的史诗和功能。
比如描述产品版本发布描述（升级公告）时，则应该展示发生变化的史诗、功能、增强三者。（缺陷后面谈）
关于这个维度，请参考：http://blog.csdn.net/cheny_com/article/details/6723715
展现程度维度
除了给客户看的东西，有些东西需要产品经理、开发团队自己知道就可以了。他们所知的范围，向前包括，意思就是说客户能看的，产品经理都能看，产品经理能看的，开发团队都能看。
缺陷有两种，客户提出的，自己发现的。前者要向客户展示（在产品升级公告里边），后者产品经理知道就可以了。
重构则是因为开发的方便性、可维护性、性能、功能的实现方法重新设计等原因引起的内部工作，无需向客户及产品经理透露即可。
债务是开发人员“走捷径”留下的可能出问题的地方。这种“可能出问题”，是指未来的功能、结构发生变化后可能出问题，而不是当前的做每种操作可能出问题（那就应该称为缺陷了）。因此既不需要现在就要改正，也需要留下一个记号日后好查。
实际使用情况
在实际项目里边，我发现这种分类可能会因为项目的不同而不同。比如最近我们想增加三种内部史诗、内部功能、内部增强，因为有些功能是为了内部开发方便做的，而且也有文件、操作、增强的区别。
我们还为不同的故事设置了类似“作为一个……，可以……以便……”的描述模板，但还不是很成熟，日后会分享给大家。
所以，在具体管理中本人也会常常改变分类方法，因此本文的内容日后会发生变化；而大家也应该在每个项目中重新思考以往的分类是否合适。
作者：陈勇
本专栏经作者授权开设，专栏文章未经许可不得转载
