本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
用户故事自最早1998年诞生以来，由于其突出的优点，到现在得到了广泛的应用。从最开始的克莱斯勒C3项目，用户故事当中的用户一般是指软件系统的人类用户，这类用户故事一般涉及人机交互界面。
而随着用户故事在多种场合扩展使用，慢慢衍生出另外两类故事。本文试图来整理下新的故事。
新的故事
1，系统故事 System Story
2，赋能故事 Enabler Story，也称推动者故事，或者使能故事
为什么不用技术故事
技术故事，技术一词，含义广泛，因此技术故事有不同的理解。
常见的例子有：
-
重构某个故事；
-
非人类的系统担当交互对象；
-
建设技术债务观测工具；
-
对某关键模块进行架构设计。
几乎除了用户故事之外的故事，都曾经被人称为技术故事，所以技术故事成为了一个含义广泛的词语。
系统故事
系统故事是指系统或者组件之间发生的交互。另外一个角度可以理解为非人类用户故事，与用例分析当中的非人类角色是相当的情况。
对于复杂组合大应用，中间系统往往并不与人类用户直接交互，往往是与其它系统进行交互。而当前不少组织的分工是安装系统或者模块来划分的，不少组织当中的团队所处理的系统或者模块无论位于何处，都有与其它系统或者模块的交互。这时如果不能快速的重组团队，也就是团队所负责的范围没有变化的话，那么系统故事就是无奈的、必需的选择。
一般的，系统故事所描述的仍然是系统的功能，当然有些情况下深入到系统内部的组件级别，这时描述的是系统内部的功能。
赋能故事
赋能故事，不是用来描述系统功能的，而是用来建设更好的开发测试方法、环境、架构、基础设施等等。
其小类有：
-
改进故事
-
环境建设故事
-
测试准备故事
-
设计架构故事
-
其它
识别多种类型故事的原因
有不少人认为没有必要识别其它类型故事，因为其它事务可以以任务的形态进入到迭代计划。
那么原因就是在迭代计划当中，主要有如下2点：
-
从思考的角度讲，用户故事和任务是两个层次的事物，对于不同层次的事物对于工作量和优先级的思考是颇有麻烦的；
-
在电子工具使用的情况下，对于不同类型的条目难以混排在一起。当前流行的Rally和Jira缺省都是按故事来进入到迭代的backlog。
而识别了多种类型故事后，有如下好处：
-
开发测试系统本身的事物，以及辅助开发测试的事物，所有团队需要处理的事物放在相同层面，同场竞技，能够更好的全面考虑各类事物的优先级和安排；
-
故事点估算可以跨越不同类型事物，通过故事点可能更好的计划迭代，故事点超越了传统的用例点、功能点等等的范围；
-
绝大多数支持敏捷的电子工具都能管理单一层面的故事优先级排定。
参考
http://www.stephen-smith.co.uk/treat-technical-stories-as-user-stories/
http://ronjeffries.com/xprog/articles/technical-stories-we-dont-need-em/
http://stackoverflow.com/questions/1828057/system-stories-for-agile-architecture
版权声明：本文为博主原创文章，未经博主允许不得转载。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » 敏捷开发用户故事的扩展-新的故事类别