任务重复，这是敏捷异味么？

作者 Mark Levison 译者 郑柯 发布于 2010年4月5日

领域

过程 & 实践

主题

敏捷实施 ,

用户故事 ,

敏捷技术 ,

企业级敏捷 ,

值和度量 ,

验收测试 ,

敏捷 ,

测试

分享到

在开发时，把系统的纵向切片作为用户故事，这是一种广为人知的方法，可以确保故事不会被应用的架构所驱动。培训师和教练们常常警告团队：水平切分系统作为用户故事，会导致多种问题，比如：预先假定架构、过度产品化（或可称为镀金过程，也就是说我们编写自认为需要的功能，可这些功能对于了解客户的进度或是业务价值无甚大用）。要想了解更多细节，请参见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中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。