写点什么

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

  • 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:531633
用户头像
臧秀涛 略懂技术的运营同学。

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

关注

评论

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

Linux云计算好学吗?Linux云计算运维学习资料 vim编辑器和恢复ext4下误删文件

学神来啦

前端开发之动态管理Nginx集群的方法

@零度

nginx 前端开发

服务探活的五种方式

捉虫大师

微服务 dubbo 健康检查 服务探活

Tech Talk 活动预告|“公有云+5G” 时代下的开发难题,架构师大咖带你逐个击破!

亚马逊云科技 (Amazon Web Services)

网络

近数据处理(NDP)——GaussDB(for MySQL)性能提升的秘密

华为云开发者联盟

MySQL 多线程 GaussDB(for MySQL) 近数据处理 算子下推

大画 Spark :: 网络(2)-上篇-通过网络收取消息的过程

dclar

大数据 spark Spark 源码

万字总结Keras深度学习中文文本分类

华为云开发者联盟

深度学习 CNN keras 文本分类 TextCNN

全面拆解携程云原生实践,打造智能弹性的云端酒店直连系统!

亚马逊云科技 (Amazon Web Services)

网络

低代码实现探索(十三)字典.静态实体.系统变量

零道云-混合式低代码平台

霸屏综艺,牵手明星,扩列神器皮皮APP的出圈始末

联营汇聚

研读网络安全法律法规,提升技术管理者 “法” 商

星环科技

风口上的“低代码”,是时候来系统学一学了!

博文视点Broadview

强化云原生基础服务,焱融科技 YRCloudFile 与秒云完成产品兼容性互认证

焱融科技

云计算 分布式 云原生 高性能 文件存储

低代码实现探索(十四)工程化思想提高项目质量与可维护性

零道云-混合式低代码平台

开发者喜欢的“夜宵”是什么?揭秘开发者的独特“口味”

OceanBase 数据库

数据库 开源 新年 oceanbase 开发者大会

盘点 | 常用 PG 数据恢复方案概览【建议收藏】

RadonDB

数据库 postgresql RadonDB

关于dart中的late关键字,你了解多少?

坚果

flutter dart 1月月更

巧用Amazon PrivateLink——轻松访问私有终端节点Amazon S3

亚马逊云科技 (Amazon Web Services)

网络

2022年,跨境ERP还是一门好生意吗?

ToB行业头条

【网络安全】你必须知道的几个网络安全概念

行云管家

运维 网络安全 防火墙 IT

linux系统管理与自动化运维工具用哪款好?

行云管家

Linux 运维 IT运维 自动化运维

MySQL高级特性篇教程

编程江湖

MySQL

大数据开发之离线分析工具Hive

@零度

大数据 hive

APP性能分析工作台——你的最佳桌面端性能分析助手

字节跳动终端技术

字节跳动 APM Mars 应用性能监控产品

百度搜索中台新一代内容架构:FaaS化和智能化实战

百度Geek说

架构 后端 搜索 Faas

【量化】量化交易入门系列6:量化交易学习书籍推荐(二)

恒生LIGHT云社区

量化策略 量化投资 量化交易 量化

您有一份Microsoft Office 365技能宝典等待签收

淋雨

Office 365 office办公软件

2021中国开源先锋33人榜单出炉:华为三位开源专家入选

科技热闻

🏆【Alibaba中间件技术系列】「RocketMQ技术专题」让我们一同来看看RocketMQ和Kafka索引设计

码界西柚

RocketMQ Alibaba Alibaba技术 1月月更

使用 KubeSphere 管理 Amazon EKS Anywhere 集群

亚马逊云科技 (Amazon Web Services)

网络

Karpenter : 新一代 Kubernetes auto scaling 工具

亚马逊云科技 (Amazon Web Services)

网络

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