是否应该为技术债创建用户故事?

标签: 技术 用户故事 | 发表时间:2013-03-27 22:53 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

敏捷团队有时也会为纯技术性任务而挣扎,比如必须处理技术债。虽然这种任务对系统用户没有直接价值,但要交付可以工作的软件又不得不处理。那么,是不是应该创建用户故事来应对这样的技术性任务或技术债呢?

在博文《 像“作为开发者……”这样的表达并非用户故事》中,Bill Wake谈到了他所遇到的对客户没什么价值的用户故事。作为例子,他提到了“作为开发者,我想配置Jenkins,以便进行持续集成”这个用户故事。Bill解释了为什么我们不应将其称作用户故事:

我不是说这些活动不好,或者说不重要,它们也是面向这个团队的,不过将其当作用户故事会误导团队及其客户。把与用户无关的东西以用户故事的 形式写下来,这是没抓住要领。

他的观点是,应该称其为任务,而非用户故事。根据精益思想,他认为这些活动其实是种浪费:

从精益思想的角度看,团队所做的很多活动都可以视作浪费,但我们又不知道如何避免这些活动从而有效地进行软件开发。精益团队称其为“不增加价值,却又必不可少”,因为这是不得已而为之的事。

Bill建议,如果某些用户故事的角色不是来自实际软件用户,而是来自于开发之中,这时一定要慎重。可以尝试将这样的用户故事重新组织为功能行为或质量特性,然后换种描述方式;如果行不通,再考虑将其看作任务。作为任务,开发团队需要跟踪,但又不应将其作为用户故事放在产品Backlog上,因为它们并不交付价值:

(……)承认你的团队有时面对的只是任务。可以内部跟踪这些任务,但是不要将其看作所开发系统的直接进展,更不要将其当作直接进展来跟踪。

关于如何在产品Backlog中处理技术性任务,Mattias Marschall在其博文《 技术上很重要的事物,怎样表达出“业务价值”》中提出了一种方案。他首先解释了如何看待用户故事与技术性任务之间的关系:

用户任务应该描述用户想让系统做的事情。纯粹的技术性任务通常实现为用户故事的一部分。

但如何处理与具体的用户故事没有直接关联的技术性任务呢?Mattias建议把它们放到产品Backlog上:

要把技术性任务按优先级放到产品Backlog中,那就为每一项创建一个用户故事。等等,这不是弄虚作假吗?不,如果你能回答如下两个问题,那就不是:

  1. 谁能从其结果中受益?
  2. 为什么这个任务是必要的?

利用他的解决方案,我们既可以把所有的技术性任务包含到产品Backlog中的用户故事里去,也可以将其作为面向客户的用户故事的一部分,还可以使用一个专为技术性任务创建的用户故事来应对:

如果你能将技术性任务明确地表达为一种用户故事,那么利益相关者就能理解它们的必要性,并将它们与其他用户故事一起优先考虑。

Bastian Buch在其博客文章 《减少技术债的有效步骤:敏捷方法》中解释道,对于与技术债相关的技术性任务,开发者和产品所有者可能有不同看法:

开发者了解技术债,也能意识到面对这种问题的重要性。

产品所有者往往不理解减少技术债的必要性和收益所在,因此他们不会考虑甚至不允许把技术性项目或用户故事列入他们的产品Backlog和发布计划中。

他建议由产品所有者负责减少技术债。团队成员应该与产品所有者讨论技术债,并共同努力,让技术债在产品Backlog中具有正确的优先级:

团队应该记住,产品所有者是团队的一分子,他的痛苦就是大家的痛苦,反之亦然。他不是团队的客户、买主或老板,而更像是来自不同利益相关者的主题专家(SME,subject matter expert)和产品需求管理者/分析员。

团队向产品所有者保证产品成长,这仍然是最重要的——不管从短期的绩效还是从长期的健康来看,都是如此。

Bastian建议把所有的技术性问题收集到用户故事中,评估投入和产出。他将收益称为“报酬”,因为解决了问题能减少技术债:

(……)针对我们定义的每一项任务,我们在JIRA中创建标记为“TechnicalDebtItems”的用户故事。为了安排这些项目的优先级并得出正确结论,我们创建一个图表来将投入与回报的相互关系可视化。

可视化有助于产品所有者和团队协作减少技术债。

通过将技术债和可能的回报可视化,(……)现在团队可以把精力集中在最重要的步骤上。还有一个重要的副作用:这也是与产品所有者和利益相关者协同工作的一个极好工具,因为它使技术债对他们也有很好的透明度。

查看英文原文 Should You Create User Stories for Technical Debt?

您可能也会喜欢

相关 [技术 用户故事] 推荐:

是否应该为技术债创建用户故事?

- - InfoQ cn
敏捷团队有时也会为纯技术性任务而挣扎,比如必须处理技术债. 虽然这种任务对系统用户没有直接价值,但要交付可以工作的软件又不得不处理. 那么,是不是应该创建用户故事来应对这样的技术性任务或技术债呢. 在博文《 像“作为开发者……”这样的表达并非用户故事》中,Bill Wake谈到了他所遇到的对客户没什么价值的用户故事.

Scrum敏捷实践之旅系列(一)用户故事概念 - 敏捷达人

- - 博客园_首页
      敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计.

前端技术

- - CSDN博客综合推荐文章
随着互联网产业的爆炸式增长,与之伴生的Web前端技术也在历经洗礼和蜕变. 尤其是近几年随着移动终端的发展,越来越多的人开始投身或转行至新领域,这更为当今的IT产业注入了新的活力. 尽管Web前端技术诞生至今时日并不长,但随着Web技术的逐渐深入,今后将会在以下几方面发力. JavaScript的兄弟们.

SSI技术

- - 开源软件 - ITeye博客
1.       SSI,通常称为“服务器端包含”技术. 使用了SSI技术的文件默认的后缀名为.shtml,SSI技术通过在html文件中加入SSI指令让web服务器在输出标准HTML代码之前先解释SSI指令,并把解释完后的输出结果和HTML代码一起返回给客户端. 2.       SSI技术的优点:SSI技术是通用技术,它不受限于运行环境,在java、dotnet、CGI、ASP、PHP下都可以使用SSI技术;解释SSI的效率比解释JSP的效率快很多,因为JSP规范提供了太多的功能,这些功能都需要servlet引擎一一进行解释,所以效率比较低.

技术选型

- - 企业架构 - ITeye博客
MVC Framwork: SpringMVC3.0 Restful的风格终于回归了MVC框架的简单本质,对比之下Struts2概念太复杂更新又太懒了. Template:JSP2.0且尽量使用JSP EL而不是taglib,万一要写taglib也用纯JSP来编写,一向是SpringSide的推荐,Freemarker们始终有点小众, 而Thymeleaf与美工配合度非常高,可惜也是太少用户了.

技术的异化:读《技术垄断》

- Dynamic - It Talks--上海魏武挥的博客
事实上,我认为国内对马克思或神圣化或妖魔化,都是要不得的. 我们应该还马克思一个伟大的社会学(当然还有哲学、经济学之类)学者的本来面目,而不是把他的话当成教义. 异化就是一个相当精到的学术词语,它所描述的是人们创造发明某物本来为了让人们自己更好地工作生活,结果该物却成了人的主宰. 在很多领域,都有异化的影子,比如宗教,比如官僚体系,当然,也包括技术.

HBase技术介绍

- 三十不归 - 搜索技术博客-淘宝
HBase – Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群. 上图描述了Hadoop EcoSystem中的各层系统,其中HBase位于结构化存储层,Hadoop HDFS为HBase提供了高可靠性的底层存储支持,Hadoop MapReduce为HBase提供了高性能的计算能力,Zookeeper为HBase提供了稳定服务和failover机制.

Web技术整理

- Gabriel - 博客园-首页原创精华区
  Web技术或许是将来最为热门的技术之一. 这里略作一些总结,以及对各种Web技术作一些概要性介绍. (以下内容建立在我的粗略理解之上,欢迎指正).   推荐个学习Web技术比较好的网站,介绍的比较全面.   页面的展示使用超文本标记语言(HTML)来表示. 这是一种标签语言,本身不具有执行能力,只是结构化页面内容.

Hadoop相关技术

- - CSDN博客云计算推荐文章
Apache的Hadoop是什么. Apache的Hadoop项目™®开发出可靠的,可扩展的,分布式计算的开源软件. Apache的Hadoop的软件库是一个框架,允许大型数据集通过计算机集群使用简单的编程模型,进行分布式处理. 它的设计规模从单一服务器到数千台计算机,每个提供本地计算和存储. 软件库是用来检测和处理应用层失败的,而不是依靠硬件提供高的有效度,因此在计算机集群上提供高度可用性服务,其中每个都有可能会有失败.

MySQL分区技术

- - 数据库 - ITeye博客
mysql分区技术是mysql5.1以后出现的新技术,能替代分库分表技术,它的优势在于只在物理层面来降低数据库压力. 常用的MySQL分区类型:. 1.RANGE分区:基于属于一个给定的连续区间的列值,把多行分配给分区(基于列). 2.LIST分区:类似于按RANGE分区,区别在于LIST分区是基于列值匹配一个离散值集合的某个值来进行选择(基于列值是固定值的).