作者 | Al Tenhundfeld
译者 | 弯月
出品 | CSDN（ID：CSDNnews）
今年距离敏捷宣言发布已经20年了，而我们可以从这20年的发展中，总结出以下两个不争的事实：
敏捷，作为一个标签，赢了。人人都想套上敏捷这个标签。
敏捷，实践的结果与创始人革命性的思想相去甚远。
我们是如何走到这一步的？每个人都说他们采用了敏捷，但几乎没有人是敏捷的。
敏捷宣言的来历
2001年2月，17 位专业的软件从业者聚集在美国犹他州瓦萨奇山区雪鸟滑雪胜地的洛奇酒店。经过几天的讨论和争辩，他们共同撰写了“敏捷软件开发宣言”。
首先需要说明，这些人都是软件开发从业者。他们不是项目经理、CTO或工程总监。他们是开发人员、程序员、科学家和工程师。他们都会编写代码，并与利益相关者合作解决问题。这一点很重要。
还有一点，敏捷宣言不是凭空产生的。在这些人之中，许多人都已经创建了自己的方法论，比如极限编程、Scrum、DSDM、自适应软件开发、水晶方法、功能驱动开发、实用编程等等。
这个小组中的每个人都拥有丰富的软件编写经验，他们都在寻找一种方法，以替代当时由文档驱动的重量级软件开发流程。敏捷宣言的核心是四项价值陈述：
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
新希望
今时今日看来，这些现代软件开发实践是理所当然的事情，但在2001年，这些想法非常激进。
还没有收集所有需求，并估算每项功能，你就打算开始构建软件？这太疯狂了！
还有最重要的一点却被人们忘记了：公开积极地反对管理。例如，Ken Schwaber直言不讳地表达了他的目标是所有项目都可以摆脱项目经理，不仅仅是让这些人离开他的项目，他希望我们整个行业消灭这个职业。
敏捷与PMI
“我们发现，在复杂的创造性工作中，项目经理的角色会阻碍生产力的提高。项目经理的思维代表了项目计划，只会将项目中其他人的创造力和智慧约束在计划之内，而不是调动每个人的聪明智慧来更好地解决问题。”—— Ken Schwaber，敏捷宣言签署人、Scrum 联合创始人
ScrumMaster几乎没有任何权力，也没有投票权。他们是团队的公仆，负责保护团队，并为团队解决难题，但不会管理团队。极限编程也很类似，最初极限编程有负责跟踪的人和教练，这些团队也有类似的促进和支持力量。
AlistairCockburn是敏捷宣言签署人，也是水晶方法论以及六边形架构的创始人，最近他提出了一个奇妙且非常有见地的看法：
Scrum在一片充满对立的领域达成了一项完美的协议：
管理层每年有12次机会，在每个sprint结束后调整团队前进的方向。
团队有一个月的时间静静地思考和工作，不会被人打断，也不需要调整方向。
团队必须宣布本月他们可以完成哪些工作，而哪些完成不了，而管理层不会干涉他们的计划。
无论是对于高管，还是对于开发团队，这都是堪称完美的协议。
我是一名经过认证的Scrum Master，在敏捷团队工作15年，而且我阅读了大量该领域的流行书籍。而下面是对Scrum最为简洁清晰的描述：
Scrum的创立是为了在充满对立的环境中发挥作用。这是强硬的经理和需要时间思考与探索的开发人员之间的契约。
管理层反击战
从某些方面来说，敏捷是一场底层劳动人民的起义。这场运动始于底层的从业者，然后向上推至管理层。敏捷是如何取得成功的呢？
部分原因是开发人员的数量和业务价值不断增长，影响力越来越大。但在我看来，最大的原因是传统的瀑布方法根本行不通。随着软件变得越来越复杂，业务步伐加快，用户的复杂程度不断提高，我们不可能提前计划好一切。尽管迭代开发尽管是合乎逻辑的，但习惯于计划好一切的管理者依然对此心存畏惧。
我记得在2005年前后的会议上，可以看出管理层并不认可敏捷，但他们也没有更好的主意。
“我们何不试一试工程师们一直在谈论的这个疯狂的想法呢？反正我们无法在最后截止期限前完成工作。情况还能更糟吗？”
然而，令他们感到惊讶的是，敏捷居然真的有成效。虽然刚开始的时候，团队会有点不适应，但经过一段时间后，就会站稳脚跟，并逐步发现哪些模式对团队有效，慢慢地一切都会好转。经过几个sprint后，你就会感受到敏捷的真正力量：划分工作的优先级、协作、检查和调整，以及其他方面等等。
大约经过了5年的时间，敏捷从一种有所耳闻、但不太熟悉的方法论，变成了人人都在实施的实践。2005年，我换了一份工作，我记得当时我对敏捷的了解非常肤浅，而在当时测试驱动开发才是主流。时至2010年，几乎所有现代软件团队都采用了敏捷。
在当时看来，敏捷成功了！大获全胜！恭喜大家！
然而，“打天下易，守天下难”。不幸的是，敏捷未能实现创始人的梦想。
事实证明，优先考虑个人以及互动是一个很难贯彻的概念。普及流程和工具要容易得多。
事实证明，生产能够正常工作的软件的难度远大于不切实际的计划和大量的文档。
事实证明，与客户合作需要信任和坦诚，这在业务环境中并不一定存在。
事实证明，高管们想要掌控一切，我们需要根据他们的业务制定长期计划，这往往根据变化做出反应更重要。
事实证明，敏捷实施不当往往会让人觉得很混乱。
这并不意味着敏捷的四项价值是错误的。这只是意味着为了正确地实施敏捷，我们需要付出巨大的努力，此外还需要一些勇气来接受软件中固有的混乱本质。你必须理解并相信，只要不断地学习，适应、改进和发布产品，最终肯定能够取得更好的成果，实现比瀑布式更现实、更高效的开发。
“敏捷运动并不是反对方法论，事实上我们很多人都希望重塑方法论的可信度。我们希望恢复平衡。我们接受建模，但不是为了将各种图表存储到公司的仓库里。我们接受文档，但不接受从未得到维护且很少使用的长篇巨著。我们计划，但是我们也清楚在动荡的环境中计划的局限性。那些称极限编程、Scrum以及其他敏捷方法论的支持者为‘黑客’的人，对于敏捷方法论和‘黑客’的原始定义一无所知。”—— Jim Highsmith，《History: The Agile Manifesto》
上述内容说到了重点，敏捷开发仍然需要计划和文档，以及严谨的实施。这是一个度的把控问题。但是，如果组织正在为敏捷转型而苦苦挣扎，陷入了混乱，此时有人提供认证、流程和工具，你必然会将之视为救命的稻草，死死抓住。高管们对流程和工具的了解远远超过他们对自组织团队的了解。
起义失败
然而不幸的是，敏捷这场起义并没有取得成功。
工具供应商、流程顾问和专家做出了许多永远无法兑现的承诺。很多人采用了 SAFe、 Scaled Scrum以及所有其他企业敏捷风格的方法论。这些框架的诞生并非出于恶意，在正确的环境下，它们甚至还有一定的价值。但我不会称它们为敏捷。试图扩展一种专注于个人与互动的方法论将不可避免地引发各种问题，并最终侵蚀该方法论原有的价值。
开发人员应该放弃敏捷
如果“敏捷”理念运用不当，则往往会给开发人员带来更多干扰，导致他们实际的工作时间更少，承受的压力更大，而且还需要“更快”地完成工作。这对开发人员很不友好，而且最终对企业也不利，因为这样的“敏捷”效果非常差，往往会引发更多缺陷，导致项目进展更缓慢。出现这样的情况，优秀的开发人员会离职，企业的效率还不如不实施敏捷。
敏捷已死
“敏捷”这个词已被颠覆，没有任何实际的意义，敏捷社区变成了顾问和供应商兜售服务和产品的舞台。当初，敏捷宣言非常流行，敏捷一词变成了吸金石，被人用以获取支持、收费或销售产品，几乎形同于一个营销术语。
因此，我认为是时候让“敏捷”这个词退出历史的舞台了。
反思
在我看来，真正令人难过的是看到年轻的开发人员诋毁敏捷，将其视为管理层的空头支票，以及推动开发团队疯狂工作的一种手段。我理解他们。在他们看来，敏捷是一种强加给他们的控制机制，而不是他们欣然接受的自我武装力量。但我希望围绕历史和最初的愿景展开一些讨论，帮助我们记住敏捷应有的发展方向。
值得庆幸的是，20年前提出的敏捷宣言在如今看来依然充满智慧，而且非常中肯。
如今敏捷不再是一个热门话题。每个人都在实施敏捷。但是，我希望在此20周年之际，反省一下下列几个问题：
哪些方面做对了？
哪些方面做错了？
下一次我们该如何改进？
我们中的一些人经历了敏捷革命，我们希望能够反思一下最初的12条敏捷原则，思考它们在当前软件开发环境中的价值。
我希望研究一下敏捷的基本原则，从过去的失败中吸取教训，用 Dave Thomas 的话来说，即使我们选择放弃“敏捷”，也能保持敏捷。
参考链接：
https://www.simplethread.com/agile-at-20-the-failed-rebellion
