《火星人开发纪实：敏捷开发一千零一夜》第四个月：用户故事的分类（下）

尝试分类

有各种分类方法可以把用户故事重新组织一下，下面这种是我自己做的分类，不是一个成熟的方法。在利用这些方法时，一定要理解其用意而不是方法，这样当自己有别的用意时，就能灵活修改。

颗粒度	客户可见	产品经理可见	开发团队可见
产品功能描述	数据级别	史诗	重构 债务
操作级别	功能
版本发布描述	增强级别	增强	外部缺陷	内部缺陷

颗粒度维度

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

所谓操作，就是对某组或多组数据的业务操作，对一组数据的操作入手“创建角色”“删除用户”，对多组数据的操作如“为用户分配角色”，其特点是操作是系统使用者的业务操作（就是“平时干活”的操作；像之前提到的“把按钮挪到屏幕上方”就不是用户的业务操作）。操作都是一个动词。

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

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

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

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

展现程度维度

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

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

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

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

实际使用情况

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

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

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

附：不同类型故事的语法模板

在大约一个月前，我们在编写火星人的帮助文档时，一点点总结了不同类型用户故事的语法模板。

一个月内将发布火星人安装包，请在案例站点用cheny登录，访问产品“火星人”，鼠标悬停在帮助按钮上面时，可以看到不同不同用户故事的解释、例子、语法说明。