在技术革命期间，我们开始思考《敏捷宣言》是否还应该成为我们的指南，因为我们进入了一个以持续创新定义的世界。这份简短但颠覆性的文件能够从各方面为我们提供帮助，从产品交付到当日送达。
但如今，我们不再那么像开拓者，而更像是在持续改进这片海洋上航行的探索者。这不禁让我们思考：是否也该对这份宣言进行优化了？
《敏捷宣言》诞生记
《敏捷宣言》诞生记
2001 年初，在犹他州瓦萨奇山脉的雪鸟度假村，17 个人聚集在一起讨论软件开发的未来。该组织的成员对目前的状况感到沮丧，虽然他们在如何纠正这种情况方面存在分歧。
他们一致认为，问题在于，各公司过于专注于过度规划和记录其软件开发周期，以至于忽略了真正重要的事情——取悦客户。
公司可能秉持“卓越”和“诚信”等企业价值观，但这些价值观并没有引导员工，尤其是软件开发人员走向更好的方式。这种情况需要改变。在雪鸟的 17 个人 (Snowbird 17) 中有一部分已经对如何开创软件开发的新时代有了想法。
山上旅行是他们讨论这个问题的机会。
《敏捷宣言》就是在这个周末制定的，只有 68 个单词，而这份简短良好的文件却永远改变了软件开发。自制定以来的近二十年中，这些词语（以及随后的 12 项原则）已（在不同程度上）被无数个人、团队和公司所接受。
12 项敏捷宣言原则：一种已定义的文化
当今的敏捷环境似乎充满了方法，这些方法有望实现敏捷理想并将其转变为现实世界。但是今天方法的疯狂并不是什么新鲜事。
《宣言》本身的诞生源于需要在 Scrum、极限编程、Crystal Clear 和其他框架之间找到共同点。
“他们开始看到自己在做一些共同的事情。但是当时，他们在很大程度上是竞争对手，至少在思想上是竞争对手。”Atlassian DevOps 首席解决方案工程师 Ian Buchanan 说，“考虑到当时的背景，他们可以在任何事情上达成共识这一事实真是太令人震惊了。”
Snowbird 17 想看看不同学科的代表能否就某件事达成共识——任何事情。令他们惊讶的是，他们做到了。他们商定了一套定义文化的价值观。
包括：
敏捷软件开发宣言
我们正在通过开发软件和帮助他人开发软件来发现更好的开发软件方法。
通过这项工作，我们获得了以下价值：
个体与互动高于流程与工具
可工作的软件高于全面的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，虽然右边的项目有价值，但我们更看重左边的项目。
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler | James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick | Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
敏捷软件十二原则同样诞生于雪鸟峰会，它们对《敏捷宣言》中寥寥数句的价值观进行了拓展。
就这样，从那时起，《敏捷宣言》网站的变化很小，如果有的话。但是围绕敏捷的世界却已经大为不同。
敏捷的精彩辩论
Snowbird 17 成功地在几个核心原则下统一了他们的不同观点，但辩论并没有就此结束。在某些方面，敏捷已经分解为比远见者最初想到的多得多的操作方式。看来每个人对敏捷都有自己的看法。
今天，有 SAFe，也有 LeSS。尽管《敏捷宣言》开篇即指出：“我们正在通过实践以及帮助他人实践，探寻更优秀的软件开发方法”，但如今敏捷的应用早已不局限于软件开发领域。
Scrum.org 首席执行官 Dave West 曾前往多个组织观察敏捷实践，他召集了一个研究小组，该小组正在使用敏捷开发一种利用病毒治疗遗传性失明的方法。
事实上，在软件领域之外拥抱敏捷已经很普遍，但《宣言》创始人可能并没有预想到这一点。
Buchanan 表示：“并非它无法解读，而是需要更深入的理解，才能确保这些理念被精准传达”。 即便在软件开发领域内部，这种深入理解也并非总能实现。
敏捷的工业中心
许多人认为，敏捷教育和咨询的货币化加剧了“虚假敏捷”及其邪恶的双胞胎“黑暗敏捷”。有些人甚至将这种货币化背后的组织称为“敏捷工业联合企业”。
Buchanan 说道：“有一种货物崇拜敏捷，操作和理念都是对的，但是因为不了解基本原则，所以无法实现有效成果。”
有些人（而且为数不少）认为 Atlassian 是造成这一问题的“罪魁祸首”，因为我们的工具为 Scrum、看板等敏捷框架提供了支持。但我们坚信，敏捷本质上是一种文化价值观，团队应被赋予自主权，以他们认为最合适的方式开展工作。敏捷框架需与文化价值观相辅相成，但如果缺乏这种文化基础，那么一切实践从起步阶段就可能存在缺陷。
所谓“伪敏捷”、“暗敏捷”或“形式主义敏捷”，这些对敏捷的曲解常常导致与《敏捷宣言》初衷背道而驰的局面—微观管理、透支团队的工作节奏、交付失败以及固守流程而非原则，这些行为堪称最恶劣，即便践行者手握认证资质也于事无补。遗憾的是，这些“暗敏捷”的实践经历导致一些人全盘否定敏捷（或根据自身实际经历对敏捷进行重构）。
作为“雪鸟 17 人”之一的 Ron Jeffries，曾通过以下界定试图纠正这些对敏捷的曲解： “在本文及其他论述中，我对‘敏捷’一词加引号，指代那些以‘敏捷’自我标榜、却未必遵循我们在《敏捷宣言》中所阐述的敏捷软件开发字面含义或精神内核的各种实践、方法与流程。我有时会强调性地使用‘伪敏捷’，或称之为‘暗敏捷’，用以指代那些已然变质却仍自诩‘敏捷’的做法。我或许会用‘宣言敏捷’一词来指代《敏捷宣言》中的核心理念—这些理念，我至今依然深信不疑。”
但是，鉴于敏捷的广泛采用，有时甚至被误导，《敏捷宣言》这份文件还值得参考吗？
宣言还有意义吗？
在与数百位 Atlassian 客户、公司内外的敏捷教练、敏捷爱好者及资深实践者深入交流后—更不用说我们还在社交媒体上投入了大量时间研读相关内容—我可以肯定地回答：是的。《敏捷宣言》仍然具有重要意义，甚至可能现在比以往任何时候都更重要。
我的两位同事，高级企业敏捷教练 Dan Radigan，以及每天与客户打交道的 Ian Buchanan 都证实，他们会定期向新客户重点介绍《宣言》。
LinkedIn 敏捷教练兼高级技术项目经理 Tanner Wortham 表示，自己也经常引用《宣言》。在海军陆战队工作了十年的 Wortham 说，他甚至在不知道敏捷之前就开始实践敏捷了。对他来说，敏捷意味着“领导海军陆战队”。但是，对 Wortham 来说，给某件事起个名字是解决这个问题的重要第一步。
“除非你能给某件事情名字，否则你真的不知道该如何处理这件事情。我想《宣言》就是这么做的，给它起了个名字，叫敏捷。我认为虽然这是已经发生的事情，但是当他们给它命名时，就可以更轻松地识别。”
Scrum.org 首席执行官 West 指出，敏捷原则根本不是什么新鲜事。它们之前只是以不同的方式应用。
West 说：“当我看到宣言背后的原理时，这些原理不是我们自己创造的，而是科学方法的原理，伽利略用过，阿基米德也用过。”
也许《敏捷宣言》的最大成就是编写了一种尚未用于软件开发的思维方式，这当然不是一件小事。
那是什么意思？
因此，敏捷原则在《敏捷宣言》发布之前就已经存在。人们将它们应用于软件开发，《敏捷宣言》整理了这些价值观。然后，人们采纳了《宣言》的原则，开始将其应用于自己的工作中。随着所有理念重新使用，是时候更新《敏捷宣言》了吗？
不一定。
像《宣言》这样具有文化意义的东西出现时，您也许可以重新解释它，但没有什么比原版更贴切了。因此，与其尝试对其进行正式更新，不如弄清楚如何将其应用于自己、团队或组织。
Wortham 说：“从很多方面来说，《宣言》是对话的基础。我就是这样认为的，你呢？好吧，我们先了解一下如何合作。”
本着这种精神，也许重要的不是一份每个人都能达成共识的幸福文件，而是是否有一群人（从团队到整个组织）能够在不忽视《宣言》精神的情况下将《宣言》中的想法应用于自己的具体情况。如果我们能把这一点做好，就会拥有无限的可能。
“我认为，如果我们做对了，世界会变得更好。我们可以解决癌症，我的孩子可能会活到 150 岁、175 岁，”West 说，“我认为我们能做到，并且我相信我们会做到。”
特别感谢 Amanda O'Callaghan、Ian Buchanan、Dan Radigan、David West 和 Tanner Wortham 为本文分享宝贵洞察信息与专业知识。
在技术革命期间，我们开始思考《敏捷宣言》是否还应该成为我们的指南，因为我们进入了一个以持续创新定义的世界。这份简短但颠覆性的文件能够从各方面为我们提供帮助，从产品交付到当日送达。
但如今，我们不再那么像开拓者，而更像是在持续改进这片海洋上航行的探索者。这不禁让我们思考：是否也该对这份宣言进行优化了？
《敏捷宣言》诞生记
《敏捷宣言》诞生记
2001 年初，在犹他州瓦萨奇山脉的雪鸟度假村，17 个人聚集在一起讨论软件开发的未来。该组织的成员对目前的状况感到沮丧，虽然他们在如何纠正这种情况方面存在分歧。
他们一致认为，问题在于，各公司过于专注于过度规划和记录其软件开发周期，以至于忽略了真正重要的事情——取悦客户。
公司可能秉持“卓越”和“诚信”等企业价值观，但这些价值观并没有引导员工，尤其是软件开发人员走向更好的方式。这种情况需要改变。在雪鸟的 17 个人 (Snowbird 17) 中有一部分已经对如何开创软件开发的新时代有了想法。
山上旅行是他们讨论这个问题的机会。
《敏捷宣言》就是在这个周末制定的，只有 68 个单词，而这份简短良好的文件却永远改变了软件开发。自制定以来的近二十年中，这些词语（以及随后的 12 项原则）已（在不同程度上）被无数个人、团队和公司所接受。
12 项敏捷宣言原则：一种已定义的文化
当今的敏捷环境似乎充满了方法，这些方法有望实现敏捷理想并将其转变为现实世界。但是今天方法的疯狂并不是什么新鲜事。
《宣言》本身的诞生源于需要在 Scrum、极限编程、Crystal Clear 和其他框架之间找到共同点。
“他们开始看到自己在做一些共同的事情。但是当时，他们在很大程度上是竞争对手，至少在思想上是竞争对手。”Atlassian DevOps 首席解决方案工程师 Ian Buchanan 说，“考虑到当时的背景，他们可以在任何事情上达成共识这一事实真是太令人震惊了。”
Snowbird 17 想看看不同学科的代表能否就某件事达成共识——任何事情。令他们惊讶的是，他们做到了。他们商定了一套定义文化的价值观。
包括：
敏捷软件开发宣言
我们正在通过开发软件和帮助他人开发软件来发现更好的开发软件方法。
通过这项工作，我们获得了以下价值：
个体与互动高于流程与工具
可工作的软件高于全面的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，虽然右边的项目有价值，但我们更看重左边的项目。
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler | James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick | Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
敏捷软件十二原则同样诞生于雪鸟峰会，它们对《敏捷宣言》中寥寥数句的价值观进行了拓展。
就这样，从那时起，《敏捷宣言》网站的变化很小，如果有的话。但是围绕敏捷的世界却已经大为不同。
敏捷的精彩辩论
Snowbird 17 成功地在几个核心原则下统一了他们的不同观点，但辩论并没有就此结束。在某些方面，敏捷已经分解为比远见者最初想到的多得多的操作方式。看来每个人对敏捷都有自己的看法。
今天，有 SAFe，也有 LeSS。尽管《敏捷宣言》开篇即指出：“我们正在通过实践以及帮助他人实践，探寻更优秀的软件开发方法”，但如今敏捷的应用早已不局限于软件开发领域。
Scrum.org 首席执行官 Dave West 曾前往多个组织观察敏捷实践，他召集了一个研究小组，该小组正在使用敏捷开发一种利用病毒治疗遗传性失明的方法。
事实上，在软件领域之外拥抱敏捷已经很普遍，但《宣言》创始人可能并没有预想到这一点。
Buchanan 表示：“并非它无法解读，而是需要更深入的理解，才能确保这些理念被精准传达”。 即便在软件开发领域内部，这种深入理解也并非总能实现。
敏捷的工业中心
许多人认为，敏捷教育和咨询的货币化加剧了“虚假敏捷”及其邪恶的双胞胎“黑暗敏捷”。有些人甚至将这种货币化背后的组织称为“敏捷工业联合企业”。
Buchanan 说道：“有一种货物崇拜敏捷，操作和理念都是对的，但是因为不了解基本原则，所以无法实现有效成果。”
有些人（而且为数不少）认为 Atlassian 是造成这一问题的“罪魁祸首”，因为我们的工具为 Scrum、看板等敏捷框架提供了支持。但我们坚信，敏捷本质上是一种文化价值观，团队应被赋予自主权，以他们认为最合适的方式开展工作。敏捷框架需与文化价值观相辅相成，但如果缺乏这种文化基础，那么一切实践从起步阶段就可能存在缺陷。
所谓“伪敏捷”、“暗敏捷”或“形式主义敏捷”，这些对敏捷的曲解常常导致与《敏捷宣言》初衷背道而驰的局面—微观管理、透支团队的工作节奏、交付失败以及固守流程而非原则，这些行为堪称最恶劣，即便践行者手握认证资质也于事无补。遗憾的是，这些“暗敏捷”的实践经历导致一些人全盘否定敏捷（或根据自身实际经历对敏捷进行重构）。
作为“雪鸟 17 人”之一的 Ron Jeffries，曾通过以下界定试图纠正这些对敏捷的曲解： “在本文及其他论述中，我对‘敏捷’一词加引号，指代那些以‘敏捷’自我标榜、却未必遵循我们在《敏捷宣言》中所阐述的敏捷软件开发字面含义或精神内核的各种实践、方法与流程。我有时会强调性地使用‘伪敏捷’，或称之为‘暗敏捷’，用以指代那些已然变质却仍自诩‘敏捷’的做法。我或许会用‘宣言敏捷’一词来指代《敏捷宣言》中的核心理念—这些理念，我至今依然深信不疑。”
但是，鉴于敏捷的广泛采用，有时甚至被误导，《敏捷宣言》这份文件还值得参考吗？
宣言还有意义吗？
在与数百位 Atlassian 客户、公司内外的敏捷教练、敏捷爱好者及资深实践者深入交流后—更不用说我们还在社交媒体上投入了大量时间研读相关内容—我可以肯定地回答：是的。《敏捷宣言》仍然具有重要意义，甚至可能现在比以往任何时候都更重要。
我的两位同事，高级企业敏捷教练 Dan Radigan，以及每天与客户打交道的 Ian Buchanan 都证实，他们会定期向新客户重点介绍《宣言》。
LinkedIn 敏捷教练兼高级技术项目经理 Tanner Wortham 表示，自己也经常引用《宣言》。在海军陆战队工作了十年的 Wortham 说，他甚至在不知道敏捷之前就开始实践敏捷了。对他来说，敏捷意味着“领导海军陆战队”。但是，对 Wortham 来说，给某件事起个名字是解决这个问题的重要第一步。
“除非你能给某件事情名字，否则你真的不知道该如何处理这件事情。我想《宣言》就是这么做的，给它起了个名字，叫敏捷。我认为虽然这是已经发生的事情，但是当他们给它命名时，就可以更轻松地识别。”
Scrum.org 首席执行官 West 指出，敏捷原则根本不是什么新鲜事。它们之前只是以不同的方式应用。
West 说：“当我看到宣言背后的原理时，这些原理不是我们自己创造的，而是科学方法的原理，伽利略用过，阿基米德也用过。”
也许《敏捷宣言》的最大成就是编写了一种尚未用于软件开发的思维方式，这当然不是一件小事。
那是什么意思？
因此，敏捷原则在《敏捷宣言》发布之前就已经存在。人们将它们应用于软件开发，《敏捷宣言》整理了这些价值观。然后，人们采纳了《宣言》的原则，开始将其应用于自己的工作中。随着所有理念重新使用，是时候更新《敏捷宣言》了吗？
不一定。
像《宣言》这样具有文化意义的东西出现时，您也许可以重新解释它，但没有什么比原版更贴切了。因此，与其尝试对其进行正式更新，不如弄清楚如何将其应用于自己、团队或组织。
Wortham 说：“从很多方面来说，《宣言》是对话的基础。我就是这样认为的，你呢？好吧，我们先了解一下如何合作。”
本着这种精神，也许重要的不是一份每个人都能达成共识的幸福文件，而是是否有一群人（从团队到整个组织）能够在不忽视《宣言》精神的情况下将《宣言》中的想法应用于自己的具体情况。如果我们能把这一点做好，就会拥有无限的可能。
“我认为，如果我们做对了，世界会变得更好。我们可以解决癌症，我的孩子可能会活到 150 岁、175 岁，”West 说，“我认为我们能做到，并且我相信我们会做到。”
特别感谢 Amanda O'Callaghan、Ian Buchanan、Dan Radigan、David West 和 Tanner Wortham 为本文分享宝贵洞察信息与专业知识。