敏捷开发用户故事的扩展-新的故事类别

敏捷开发 herman 1865浏览 0评论
公告:“业余草”微信公众号提供免费CSDN下载服务(只下Java资源),关注业余草微信公众号,添加作者微信:xttblog,发送下载链接帮助你免费下载!
本博客日IP超过1800,PV 2600 左右,急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包,请加博主新的微信号:xttblog,之前的微信号好友位已满,备注:返现
所有面试题(java、前端、数据库、springboot等)一网打尽,请关注文末小程序
视频教程免费领

用户故事自最早1998年诞生以来,由于其突出的优点,到现在得到了广泛的应用。从最开始的克莱斯勒C3项目,用户故事当中的用户一般是指软件系统的人类用户,这类用户故事一般涉及人机交互界面。 
而随着用户故事在多种场合扩展使用,慢慢衍生出另外两类故事。本文试图来整理下新的故事。

新的故事

1,系统故事 System Story 
2,赋能故事 Enabler Story,也称推动者故事,或者使能故事

为什么不用技术故事

技术故事,技术一词,含义广泛,因此技术故事有不同的理解。 
常见的例子有:

  1. 重构某个故事;

  2. 非人类的系统担当交互对象;

  3. 建设技术债务观测工具;

  4. 对某关键模块进行架构设计。 
    几乎除了用户故事之外的故事,都曾经被人称为技术故事,所以技术故事成为了一个含义广泛的词语。

系统故事

系统故事是指系统或者组件之间发生的交互。另外一个角度可以理解为非人类用户故事,与用例分析当中的非人类角色是相当的情况。 
对于复杂组合大应用,中间系统往往并不与人类用户直接交互,往往是与其它系统进行交互。而当前不少组织的分工是安装系统或者模块来划分的,不少组织当中的团队所处理的系统或者模块无论位于何处,都有与其它系统或者模块的交互。这时如果不能快速的重组团队,也就是团队所负责的范围没有变化的话,那么系统故事就是无奈的、必需的选择。 
一般的,系统故事所描述的仍然是系统的功能,当然有些情况下深入到系统内部的组件级别,这时描述的是系统内部的功能。

赋能故事

赋能故事,不是用来描述系统功能的,而是用来建设更好的开发测试方法、环境、架构、基础设施等等。 
其小类有:

  • 改进故事

  • 环境建设故事

  • 测试准备故事

  • 设计架构故事

  • 其它

识别多种类型故事的原因

有不少人认为没有必要识别其它类型故事,因为其它事务可以以任务的形态进入到迭代计划。 
那么原因就是在迭代计划当中,主要有如下2点:

  1. 从思考的角度讲,用户故事和任务是两个层次的事物,对于不同层次的事物对于工作量和优先级的思考是颇有麻烦的;

  2. 在电子工具使用的情况下,对于不同类型的条目难以混排在一起。当前流行的Rally和Jira缺省都是按故事来进入到迭代的backlog。

而识别了多种类型故事后,有如下好处:

  1. 开发测试系统本身的事物,以及辅助开发测试的事物,所有团队需要处理的事物放在相同层面,同场竞技,能够更好的全面考虑各类事物的优先级和安排;

  2. 故事点估算可以跨越不同类型事物,通过故事点可能更好的计划迭代,故事点超越了传统的用例点、功能点等等的范围;

  3. 绝大多数支持敏捷的电子工具都能管理单一层面的故事优先级排定。

参考

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)!可加QQ1群:135430763(2000人群已满),QQ2群:454796847(已满),QQ3群:187424846(已满)。QQ群进群密码:xttblog,想加微信群的朋友,之前的微信号好友已满,请加博主新的微信号:xttblog,备注:“xttblog”,添加博主微信拉你进群。备注错误不会同意好友申请。再次感谢您的关注!后续有精彩内容会第一时间发给您!原创文章投稿请发送至532009913@qq.com邮箱。商务合作可添加助理微信进行沟通!

本文原文出处:业余草: » 敏捷开发用户故事的扩展-新的故事类别