实施敏捷：抄近道的迷思

作者 Ben Hughes 译者 李剑 发布于 2008年1月18日

领域

过程 & 实践

主题

敏捷介绍 ,

敏捷实施 ,

敏捷技术 ,

企业级敏捷 ,

敏捷

在ThoughtWorks身兼资深开发人员、PM和程序经理数职的Ross Petit，最近在一篇文章中讲述了实施敏捷的过程中常见的错误。表面看来，实施敏捷的过程不应该是荆棘密布一路泥泞的，而且它也往往不会像传统软件开发方法一样要求那么多流程和步骤。那问题到底在哪里？如果所有的流程都完成了，那为什么很多项目最终会终止于技术争论、未交付的代码和其他一些令人生厌的事情，而敏捷方法却还声称可以避免这一切呢？作者详细描述了几种自作聪明的抄近道的做法：

我们写了单元测试，但是它们是否运行通过无关紧要
编写单元测试并自动构建，这是很明显的一个最佳开发实践。虽然有很多人都愿意写单元测试，可不是所有人都很勤快的去维护它们。

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

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

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

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

查看英文原文：Mythical Agile Shortcuts

译者 李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。