BT

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

实施敏捷:抄近道的迷思

| 作者 Ben Hughes 关注 0 他的粉丝 ,译者 李剑 关注 1 他的粉丝 发布于 2008年1月19日. 估计阅读时间: 1 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。
ThoughtWorks身兼资深开发人员、PM和程序经理数职的Ross Petit,最近在一篇文章中讲述了实施敏捷的过程中常见的错误。表面看来,实施敏捷的过程不应该是荆棘密布一路泥泞的,而且它也往往不会像传统软件开发方法一样要求那么多流程和步骤。那问题到底在哪里?如果所有的流程都完成了,那为什么很多项目最终会终止于技术争论、未交付的代码和其他一些令人生厌的事情,而敏捷方法却还声称可以避免这一切呢?作者详细描述了几种自作聪明的抄近道的做法:
我们写了单元测试,但是它们是否运行通过无关紧要
编写单元测试并自动构建,这是很明显的一个最佳开发实践。虽然有很多人都愿意写单元测试,可不是所有人都很勤快的去维护它们。

我们结对——只在出现问题的时候
结对往往只被看作一种“有益”的实践,而非必需。但事实却是,结对可以维持敏捷团队稳定的产出,就像伟大的团队从知识共享中收益一样。

我们所做的工作不会自己生成敏捷“故事”,所以我们用技术任务来进行记录
团队把工作定义成任务,而不是连续的故事。需求被组织成开发人员技术行为的语句描述,而不是可以让客户理解、对用户有价值的特性。技术团队很容易做出这样一系列的技术任务来,把它们当成故事。

Petit最后总结说:“捷径就是两点之间最远的路线。” 看上去半途而废的敏捷实施甚至比它想要取而代之的完整流程还要更坏。

这里有Agile Journal上的全文,你可以了解一下Petit有关如何避免这些陷阱的论述。

查看英文原文Mythical Agile Shortcuts

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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