BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Mark Levison 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2010年4月6日. 估计阅读时间: 2 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

在开发时,把系统的纵向切片作为用户故事,这是一种广为人知的方法,可以确保故事不会被应用的架构所驱动。培训师和教练们常常警告团队:水平切分系统作为用户故事,会导致多种问题,比如:预先假定架构、过度产品化(或可称为镀金过程,也就是说我们编写自认为需要的功能,可这些功能对于了解客户的进度或是业务价值无甚大用)。要想了解更多细节,请参见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?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT