写点什么

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

  • 2013-03-27
  • 本文字数:1720 字

    阅读完需:约 6 分钟

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

在博文《像“作为开发者……”这样的表达并非用户故事》中,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?

2013-03-27 09:531490
用户头像
臧秀涛 略懂技术的运营同学。

发布了 300 篇内容, 共 133.9 次阅读, 收获喜欢 35 次。

关注

评论

发布
暂无评论
发现更多内容

百度地图开发 - 在地图上检索数据 08

Andy阿辉

android Android 小菜鸟 Android端 8月日更

Golang:并发操作中常见的读写锁

Regan Yue

读写锁 Go 语言 8月日更

Vue进阶(八十二):updated 应用详解

No Silver Bullet

Vue 8月日更

八位阿里大牛耗时三年总结出Java面试复盘手册!带你实现逆风翻盘

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

面试进阶双飞!Alibaba新产SpringBoot深度历险(嵩山版)开源

Java~~~

Java spring 架构 面试 JVM

在线JSON转CSV,TSV工具

入门小站

工具

架构实战营 - 模块六作业

Julian Chu

架构实战营

关于我尝试抓包微信失败后想到的新方法居然和奥特曼有关~

4ye

Python TCP 爬虫 后端 8月日更

架构实战营 - 模块六作业

思梦乐

详解Java方法句柄MethodHandle

Java 方法句柄

难以置信!网易首席架构师竟用了500页笔记,把网络协议给趣谈了

Java~~~

Java 架构 面试 TCP 网络

☕【Java技术指南】「TestNG专题」单元测试框架之TestNG使用教程指南(下)

洛神灬殇

Java JUnit 8月日更 testNG

清华毕业20年从业经验马士兵建议所有Java高工必看的高并发编程

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

教你一招疯狂拿Offer!用微服务设计一个超大型分布式电商平台

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

华为18级工程师耗时三年才总结出这份Java亿级高并发核心编程手册

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

无意发现,某东买来的Redis核心实践PDF,竟在GitHub数据库榜第一

Java~~~

Java redis 架构 面试 架构师

Linux之file命令

入门小站

Linux

基于Netty,20分钟手撸一个RPC框架

码农参上

netty 8月日更

架构实战营模块 6 作业指导

华仔

#架构实战营

难以置信!阿里新产微服务架构进阶笔记我粉了!理论实战齐飞

Java 编程 架构 面试 架构师

业界良心啊!第五次更新的Spring Cloud Alibaba升级太多内容

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

模块六作业

king

架构实战营 - 模块六作业

李东旭

「架构实战营」

新书介绍 -- 《Redis核心原理与实践》

binecy

redis cluster 书籍 redis sentinel Redis Stream

系统对接阿里云短信接口(Java开发实践)

Python研究者

8月日更

模块六作业

俊杰

架构实战营

阿里二面:怎么解决MySQL死锁问题的?

Java MySQL 架构 面试 后端

Scrum Patterns:持续改进脉冲(Kaizen Pulse)(译)

Bruce Talk

敏捷开发 译文 Agile Scrum Patterns

架构实战营模块6作业

技术是伙伴

架构实战营

认认真真的聊聊"软"中断

编程 架构 后端 计算机

阿里P8整理的《百亿级并发系统设计》实战教程,实在是太香了

Java 架构 后端 高并发

是否应该为技术债创建用户故事?_研发效能_Ben Linders_InfoQ精选文章