写点什么

任务重复,这是敏捷异味么?

  • 2010-04-05
  • 本文字数:824 字

    阅读完需:约 3 分钟

在开发时,把系统的纵向切片作为用户故事,这是一种广为人知的方法,可以确保故事不会被应用的架构所驱动。培训师和教练们常常警告团队:水平切分系统作为用户故事,会导致多种问题,比如:预先假定架构、过度产品化(或可称为镀金过程,也就是说我们编写自认为需要的功能,可这些功能对于了解客户的进度或是业务价值无甚大用)。要想了解更多细节,请参见Mike Cohn 的《User Stories Applied》一书【译者注:本书已由InfoQ 中文站敏捷社区的编辑滕振宇和石永超翻译完成,不日即将出版】。

Antony Marcano 提出一个有趣的观点,认为水平切分的故事常常产生重复的任务,比如:“向 Model 中加入 X”、“改变 View”。在传统的 Scrum 和 Agile 方法中,团队会估算 sprint 中任务的完成小时数,然后在 Sprint 或迭代燃尽图中进行跟踪。Antony 指出:如果以可工作的软件的角度来看,这不是一种衡量进度的真实方式。

InfoQ 已经有对这一问题的回应:燃尽图故事不是任务跟踪速度而不是在任务上耗费的时间

Antony 建议:我们应该跟踪每个故事成功实现的验收条件。要做到这一点,我们要把验收条件从模糊的语句变为可验证的例子,比如:“必须有一个链接可以保存档案”变为“应该创建一个新的档案”。只要验证条件可以测试,我们就可以跟踪条件是否有验收测试,以及这些测试是否可以运行通过。

Jason Gorman 注意到同样的问题,还指出:跟踪任务会让人们对完成度产生错误的感觉:

任务属于“如何做”的过程,很可能已经完成了某个用户故事 90% 的任务,可这时还没有向用户交付任何价值。因此,使用任务来规划和跟踪迭代,这会导致臭名昭著的“90% 完成”综合症。

Jason 的方法能够解决 Antony 提出的问题。Jason 愿意让团队估算某个故事涉及的各个测试的复杂度。团队会跟踪交付的验收测试点数。

不管采用哪种方式切分故事,现在大家都有一个共识:跟踪任务小时数已经过时了,我们应该找到一种更好的方式,用以度量交付给客户的价值。

查看英文原文: Repetitive Tasks an Agile Smell?

2010-04-05 04:331859
用户头像

发布了 479 篇内容, 共 172.3 次阅读, 收获喜欢 52 次。

关注

评论

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

ARTS 打卡第 21 天

自由

ARTS 打卡计划

保姆级教程|带你体验华为云测试计划CodeArts TestPlan

平平无奇爱好科技

体验华为云Serverless FunctionGraph,一分钟上线应用

平平无奇爱好科技

使用生成式 AI 和 Amazon Kendra 实现企业规模的图像字幕创建和搜索

亚马逊云科技 (Amazon Web Services)

API #人工智能

TiDB 一栈式综合交易查询解决方案获“金鼎奖”优秀金融科技解决方案奖

PingCAP

数据库 TiDB

华为云Astro低代码平台关键能力技术浅析

平平无奇爱好科技

中欧财富:分布式数据库的应用历程和 TiDB 7.1 新特性探索

PingCAP

数据库 TiDB pingCAP

最佳实践:TiDB 业务读变慢分析处理

PingCAP

数据库 TiDB

漱玉平民大药房:多元化药店变革的前夜

PingCAP

MySQL 数据库 TiDB

TiDB x 安能物流丨打造一栈式物流数据平台

PingCAP

数据库 TiDB

华为云classroom赋能|tookIT助力开发者上云

平平无奇爱好科技

华为云Classroom一站式教学实践平台,开启云端教学新征程

平平无奇爱好科技

TiDB Serverless Branching:通过数据库分支简化应用开发流程

PingCAP

数据库 TiDB pingCAP TiDB Serverless

重磅!华为云计算技术有限公司云原生中间件高分通过中国信通院《云服务稳定运行能力标准体系》能力评估先进级

平平无奇爱好科技

Serverless冷启动:如何让函数计算更快更强?

平平无奇爱好科技

纷繁复杂见真章,华为云产品需求管理利器CodeArts Req解读

平平无奇爱好科技

任务重复,这是敏捷异味么?_研发效能_Mark Levison_InfoQ精选文章