HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

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

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

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

关注

评论

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

星环科技边缘计算平台Sophon Edge通过EC Ready边缘服务权威评测!

星环科技

TDH8.0使用必读2: 10种数据模型全支持 未来属于多模型大数据平台

星环科技

NeoFetch - Linux 使用命令行查看系统信息

HoneyMoose

收藏!阿里P9耗时28天,总结出来了“618、双十一”活动高并发系统设计手册

Java 程序员 架构 面试 高并发

什么是NQI?质量基础设施“一站式”服务平台我来帮你搭建

源中瑞-龙先生

NQI 质量基础设施“一站式”

SpringCloud Gateway 路由断言

中原银行

函数式接口 reactor SpringCloud Gateway

模型化生存

俞凡

认知

网络攻防学习笔记 Day56

穿过生命散发芬芳

网络攻防 6月日更

源中瑞区块链BaaS平台为企业一键部署区块链应用

13530558032

redis面试知识点和内存算法了解

经典Android开发教程!腾讯T3团队整理,附小技巧

欢喜学安卓

android 程序员 面试 移动开发

什么是网络流量劫持?

网络安全学海

网络安全 安全 渗透测试 安全漏洞 网络攻防

Ubuntu 安装 NTP 服务

HoneyMoose

亚马逊云科技宣布Amazon WAF 在北京区域和宁夏区域正式上线

亚马逊云科技 (Amazon Web Services)

建信金科大咖访谈:人工智能技术应用与展望

金科优源汇

前端工程化的思考

金科优源汇

肝到头秃!阿里爆款的顶配版Spring Security笔记

Java 程序员 架构 面试 计算机

Jenkins 控制台输出中的奇怪字符

HoneyMoose

【Jetpack篇】协程+Retrofit网络请求状态封装实战

付十一

Android进阶 JetPack

用Python手动实现LRU算法

IT蜗壳-Tango

6月日更 算法训练营 算法训练营2021第0期

企微私域经营

soho

Swarm云算力矿机分币系统搭建,chia矿机系统源码

拥抱数字娱乐家庭新生态,亚马逊云科技赋能智象“蛟龙出海” | 精选案例

亚马逊云科技 (Amazon Web Services)

平安社区建设解决方案.智慧小区平台系统建设

四份深入源码层面笔记,学完后让你彻底精通Spring Cloud!

Java架构追梦

Java 架构 面试 微服务 SpringCloud

JAVA原生线程池源码解析及使用建议( 程序员必看!)

Java 面试 BAT

重磅!北京区域已经推出第三个可用区啦

亚马逊云科技 (Amazon Web Services)

区块链创新食品溯源--让舌尖上的安全看的见

13530558032

Linux学习经验分享:搞定这六点,Linux命令So easy!

学无止境的阿奔

Linux 分布式 运维 C/C++

【Jetpack篇】协程+Retrofit网络请求状态封装实战(2)

付十一

Android进阶 JetPack

软件工程师的10个认知模型

俞凡

认知

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