尝试分类
有各种分类方法可以把用户故事重新组织一下,下面这种是我自己做的分类,不是一个成熟的方法。在利用这些方法时,一定要理解其用意而不是方法,这样当自己有别的用意时,就能灵活修改。
颗粒度 |
客户可见 |
产品经理可见 |
开发团队可见 |
||
产品功能描述 |
数据级别 |
史诗 |
重构 债务 |
||
操作级别 |
功能 |
||||
版本发布描述 |
增强级别 |
增强 |
外部缺陷 |
内部缺陷 |
颗粒度维度
所谓数据,就是一组用户要操作的业务数据,比如一个要有用户管理的系统,就肯定有“用户,角色,权限……”这些要操作的数据。其特点是文件是系统的使用者能理解的“业务”数据,而非技术数据(比如数据库表)。数据都是名词。
所谓操作,就是对某组或多组数据的业务操作,对一组数据的操作入手“创建角色”“删除用户”,对多组数据的操作如“为用户分配角色”,其特点是操作是系统使用者的业务操作(就是“平时干活”的操作;像之前提到的“把按钮挪到屏幕上方”就不是用户的业务操作)。操作都是一个动词。
所谓增强,就是此外的用来做定语、状语、补语的内容了。比如开始引子里边的案例1,就是为了用户方便做的东西,既不是用户要管理的数据,也不是用户平时工作的操作。
这个维度,在“客户可见”的层面上理解,非常方便。
比如描述产品有何功能的时候,只需要展示客户可见的史诗和功能。
比如描述产品版本发布描述(升级公告)时,则应该展示发生变化的史诗、功能、增强三者。
展现程度维度
除了给客户看的东西,有些东西需要产品经理、开发团队自己知道就可以了。他们所知的范围,向前包括,意思就是说客户能看的,产品经理都能看,产品经理能看的,开发团队都能看。
缺陷有两种,客户提出的,自己发现的。前者要向客户展示(在产品升级公告里边),后者产品经理知道就可以了。
重构则是因为开发的方便性、可维护性、性能、功能的实现方法重新设计等原因引起的内部工作,无需向客户及产品经理透露(虽然产品经理往往知道)。
债务是开发人员“走捷径”留下的可能出问题的地方。这种“可能出问题”,是指未来的功能、结构发生变化后可能出问题,而不是当前的做每种操作可能出问题(那就应该称为缺陷了)。因此既不需要现在就要改正,但也需要留下一个记号日后好查。
实际使用情况
在实际项目里边,我发现这种分类可能会因为项目的不同而不同。比如最近我们想增加三种内部史诗、内部功能、内部增强,因为有些功能是为了内部开发方便做的,而且也有文件、操作、增强的区别。
我们还为不同的故事设置了类似“作为一个……,可以……,以便……”的描述模板,但还不是很成熟,日后会分享给大家。
所以,在具体管理中本人也会常常改变分类方法,因此本文的内容日后会发生变化;而大家也应该在每个项目中重新思考以往的分类是否合适。
附:不同类型故事的语法模板
在大约一个月前,我们在编写火星人的帮助文档时,一点点总结了不同类型用户故事的语法模板。
一个月内将发布火星人安装包,请在案例站点用cheny登录,访问产品“火星人”,鼠标悬停在帮助按钮上面时,可以看到不同不同用户故事的解释、例子、语法说明。