我们一直在谈论、学习并实践敏捷，在敏捷大爆发的今天，许多组织或团队都声称自己是“敏捷的”，那么到底什么是 “敏捷” 呢 ？要回答这个问题，我们有必要回归到标志着敏捷诞生的敏捷宣言。
在2001年，17位具有反叛精神的软件开发方法的代表性人物相聚在犹他州的雪鸟城，并进行为期三天的小型会议。这些人都是来自当时“轻量级”软件开发方法的代表性人物，相比于计划驱动的开发方式，特别是已被业界普遍接受的瀑布模型，这些轻量级的软件开发方法还不太为大众所熟知。他们共同探讨了关于软件的构想、开发、交付甚至涉及了关于世界运作的方式，并最终签署了敏捷诞生的标志性文件-敏捷宣言。
敏捷的价值观
敏捷宣言的开篇即描述了敏捷宣言的初衷，其所探求的是更好的软件开发方式。实践出真知，通过在不断的实践中进行总结、抽象、剥离，最终汇总出来这四颗 “银弹”，为诸多寻求更好的的软件开发方式的人提供思想指引。
最后一句总结同样重要，敏捷宣言对左右两侧的价值都认可，并不是否认右侧存在的价值。只是，敏捷认为左侧更为重要。
也许敏捷所遵循的原则通过英文的方式表述更加“原汁原味”，不同的中文翻译多有偏颇，下面是摘自官方英文版的原文。
We follow these principles:
这12个原则所表述的不是什么新东西，也不是敏捷的独创性原则，大家在软件开发的过程中已经亲身实践着里面的一个或多个原则。这些原则是17位敏捷宣言签署者从已有的软件开发方法中汇总、提炼所得，有几分最佳实践的意思。
大家结合自身的工程经历，对每条原则可能会有不同的体会。我个人印象最深刻是：
简单是敏捷的精髓，这是使 “不需要做的工作最大化” 的一门艺术。如何保持简单确实是一门艺术。根据“二八原则”，80%的价值通过20%的工作实现。当我们完成了百分之八十的价值之后，剩余的百分之二十的价值要耗费我们百分之八十的工作量，那我们还需要继续做下去吗？当然。剩余的80%的工作依然适用二八原则。但最终我们关注的是给客户带来的价值，通过最少的工作使客户最大的价值得以满足，可谓是“事半功倍”了。
的确如此，我们软件开发的原始动力是要为商业目标服务。我们开发出来的软件产品能够满足客户的需求，并最终获得客户的认可，这是实现商业目标的必要条件。及早的和持续的交付有架子的软件是实现这一条件的有效方式。及早的交付能够实现客户所关注的价值的软件能够有效提升客户满意度，持续的交付（相对的概念，可能“频繁的交付”更为合适）有助于我们尽快获得客户的反馈，及早捕获客户可能得变更，降低后续变更带来的风险。
敏捷没有终点，倡导持续性的检视和改进。这是一个持续性的过程，不以项目的开始而开始，项目的结束而结束。在单个团队、多个团队和组织内持续的改进。我们要有审视自身问题的勇气和改进的决心，不以追责和批判为目的，以发现问题和改进为导向，在更加积极、热情的分为下，形成检视-改进的良性循环。
探讨一：敏捷的本质是什么 ？
“敏捷”是一种抽象的软件开发思想，敏捷宣言用四颗“银弹”勾勒出一种思维方式，这种思维方法有助于我们更好进行软件开发，甚至有助于我们更好的认识世界。
我个人认为敏捷是纯粹的，敏捷白喉的原则不应当属于敏捷定义的范畴。敏捷是通过其价值观所体现出的一种思想方式，是纯粹的价值观。
“敏捷”不是方法论，敏捷也不是“框架”，“方法即为具体，框架即结构”，敏捷没有告我们进行软件开发的具体步骤，也没有为我们描绘软件开发的框架，我们在实际开发中如何实践敏捷多有差异。如果您在工程实践中遵循了敏捷的价值观，就可以认为具有“敏捷性”。
探讨二：敏捷过时了吗 ？
自2001年到现在，作为一份签署的历史性文件敏捷宣言已经有近17年了。如此长的一段时间内，已经涌现出非常多的、优秀的软件开发方法实践。但软件开发的根本思想变化并不是很大，过去的一些价值和原则时至今日依然适用。当然，我们不能完全的认为敏捷宣言是百分之百正确的且无懈可击的，世界上本没有“银弹”，依然有很多人对敏捷持有不同见解和意见。不可否认，敏捷宣言所倡导的价值观和原则确实能够使得我们在软件开发中受益，只是作为一份历史性的材料，敏捷宣言已经不可能再发生改变。
也许，敏捷宣言的签署者们也没有料想到敏捷宣言会带来如此大的变化，拥有如此众多的敏捷追随者。但令人不安的是，当前敏捷似乎已经“泛滥”了，大家都在谈敏捷、实践敏捷并声称自己是敏捷的，同时，也涌现出了很多的其他的敏捷领域，紧跟“敏捷”之后，“敏捷软件”、“敏捷教练”、“敏捷培训”和“敏捷会议”都成为了“敏捷”的理念。这些理念不能说是错的，也不能说是“纯粹的”敏捷，或多或少地都是遵循了敏捷的价值和原则。个人并不排斥这种“百家争鸣”式的 “发展”，但另许多人不安的是，这些敏捷似乎已经脱离了 “技术性” 的轨道，也许这种场景下，“纯粹敏捷” 的拥护者已经不再认为那是敏捷了。
探讨三：敏捷等于“快”？
许多企业或组织准备引入敏捷的最初动力就是 “敏捷能使我们更快”，因为我们引入了敏捷，所以我们一定能：
更快的开发出产品 让团队能拥有更高的开发效率 ……
非常不幸的是，敏捷并不等于“快”，相反，敏捷引入的初期可能会导致生产力的下降。比如，为了能够实现所谓的“更快”的目标，管理层频繁的向团队施压，要求团队在更短的时间内交付更多的价值。团队面对管理层的压力也就不得不靠“加班”来实现预期结果了（团队自组织的成熟度有限，在实际落地时，或多或少都会感受到来自“管理层”的压力。）。虽然在短期内可能能够“立竿见影”，但这种方式已经“不敏捷”了，因为它已经违背了敏捷的“持续性”要求。
有效的实施敏捷确实能使我们更好的交付商业价值、客户更加满意、缩短产品上市时间。但这并不是基于 “敏捷等于快” 的这个论调。以敏捷的价值观为指引，遵循敏捷的相关原则，我们会更加关注业务价值的交付，并且会尽可能早的交付客户，尽快获得客户的反馈，自组织的团队也更关注研发能力提升、使不需要做的工作最大化了等等……所有这些改变和提升都有利于我们变得更 “快”。
