今年，敏捷宣言已经度过了它六周岁的生日，在敏捷的传播和（不可避免的？）效果弱化的过程中，我们见到了梦想的肥皂泡逐一幻灭。甚至在敏捷成为真正的主流之前，就已经有了关于后敏捷主义（post-agilism）的讨论。有些人建议说，在过去的几年里，我们已经成长了起来，现在该是更新敏捷宣言的时候了。身为敏捷宣言的作者之一的Brian Marick，也给自己在 XPDay Toronto 上讲演的主题命名为：《时隔六年：敏捷宣言几成明日黄花》，并随后在博客中做了详细说明：
虽然敏捷宣言中声称“客户协作胜于合同谈判”，但它从一定程度上可以算是对制定合同的一些建议：我们承诺会频繁交付可工作的软件，并且我们也不会因为项目后期的需求变更而牢骚满腹；对应的是，你不要用文档、工具和过程这种有时候看上去会对项目有所帮助但实际上并无益处，并一度因为信任度的缺乏而用来监视我们的东西来延缓我们的开发进度。你不需要直接盯着我们的工作，而是应该常常和我们沟通。 在当时，这种说法的出现无异于一剂强心剂，并且推动了项目的成功。但是那个时代已经过去了——敏捷已经大受欢迎，对项目开发而言也成了更加安全的选择。我们现在所面临的挑战已经不再是选用敏捷，而是选用敏捷后如何进行应用。
Marick 接着给出了宣言中所缺少的四种理念：技能、纪律、舒适 _ 和 _ 快乐。我们在 InfoQ 上曾有过类似的报道：Kent Back 针对如何更加快乐的工作和如何提高对工作的满意度的话题，和其他人进行了讨论。
Ron Jeffries 和 Chet Hendrickson 最近弄出了一个 5 天的训练课程，名为时尚优雅的五日软件开发。当我问起 Ron 为什么社区还需要另外一类 Agile 或 TDD 时，他回答说：
这并不是“另一类 Agile”。这实际上是一个工作间，人们通过观看我和 Chet 协同工作，可以以特殊的方式来了解敏捷，并对它产生兴趣。我们认为完善的软件开发过程应当包括优秀的开发技能和严格的纪律约束，同时还需要大家在轻松的环境下全心投入——这就是我们所说的“时尚优雅”。我们的计划是帮助人们理解我们的目标和完成目标的方式，并且让他们能够通过充分的亲身体验来判断这种方式是否适用于他们自己的开发过程。
Simon Baker 记录了在从前的 Agile Practitioners Forum 中进行的谈话：
在从前的 Agile Practitioners Forum 中，Colin MacAndrew 问了所有人一个问题：“敏捷宣言需要重构吗？” 当时我很高兴，因为着实有不少人站到了它的对立面。现在 Colin 把他的问题变成了敏捷宣言是否应该有所改进，并没有提到要重写宣言，但是仍然有人坚决抵制，这就让我感到奇怪了。我感觉到一场争执的风暴即将来临，确实有举办一次会议的必要了。
Baker 的想法是，敏捷宣言中的一些概念是商务群体很难理解的，如果把精益开发中的一些概念（诸如追求卓越，理解并消除浪费，整体优化和排队理论）加入到敏捷宣言中，就可以解决这个问题。
Jason Yip 的观点则相反，他给出了重构宣言后的一个精简且风趣的版本：
- 让我们互相交谈
- 让我们构建软件给你看
- 让我们彼此信任
- 让我们对正在发生的一切和我们所学到的东西做出响应
敏捷宣言本身应当是敏捷的吗？大多数人应该会同意这个观点，但是当整个敏捷社区的核心价值已经发生了变化的时候，对敏捷宣言的修改就该提上日程了。我们的核心价值变了吗？
不管答案如何，敏捷社区中一些卓有远见的人正在从他们的经验中探寻前行的路，并找出那些在宣言中没有指出的问题。当社区中关于如何构建更优秀的软件的理念在日趋完善的时候，也许敏捷宣言理应反映出这一变化。
查看英文原文： Refactoring the Agile Manifesto
译者简介：李剑，中国Eclipse 社区插件开发版版主，在JavaEye 拥有 RCP 专栏，北航软件工程硕士。现就职于 Ethos ，热衷于设计模式，敏捷软件开发的研究与实践。为 InfoQ 中文站贡献内容，请邮件至 china-editorial@infoq.com 。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论