在看过资料后，自己对敏捷开发有了一些粗浅的认识，在这里略做浅谈。
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。其实，敏捷开发有自己的核心价值观：沟通、简单、反馈、勇气、谦逊。
多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” 。设计过程充斥着短期的、即时的决定，而无完整的规划。 这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加 入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典 型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期 之感，从而对项目的完成产生严重的影响。软件行业中最初的一场运动是要改变这种情况，而引入了“正规方法” 的概念。这些方法对开发过程有着严格而详 尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他 工程领域的实践 － 因此我把它们称为工程方法。工程方法已存在了很长时间了，但是没有取得令人瞩目的成功，甚至就 没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐， 要是按照它的要求来，那有做太多的事情需要做，而延缓整个开发进程。敏捷型方法的发展是对这些工程方法的反叛。 对许多人来说，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们 在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取 较满意的结果。
敏捷型与工程型方法有一些显著的区别。其中一个显而易见的不同反映在文档 上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。 从许多方面来看，它们更象是“面向源码”。事实上，它们 认为最根本的文档应该是源码。
但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减 少仅仅是个表象，它其实反映的是两个更深层的特点：1.敏捷型方法是“适应性”而非“预见性”。 工程方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划， 然后依计划进行开发。这类方法在一般情况下工作良好，但（需求、环境等） 有变化时就不太灵了。因此它们本质上是拒绝变化的。而敏捷型方法则欢迎 变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适 应变化。2.敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法 则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的 工作提供支持。
敏捷开发的预见性与适应性：1.将设计与建造分离开来 设计是难于预见的，并且 需要昂贵的有创造性的人员，建造则要易于预设。我们有了设计之后， 便可对建造进行计划了。而有了建造计划后，我们进行建造则可以是非常可 预见性的了。在土木工程中，建造不论在经费上还是在时间上的成本都要比 设计和计划大得多。所以，软件工程方法的途径是象这样的：我们想要可预见的生产进度计划， 以便能使用技能较低的人员。要达到这一点，我们必须得把设计与建造分离 开来。因此，在软件开发中，我们得想法作出这样的设计，使得计划一经完 成，建造将会是直接而明确的。2.需求的不可预见性 作软件开发的费用估算是不容易的，这有多种原因。部分原因是因为软件 开发是一种设计活动，因此难于精确计划。部分原因是系统的“基本材料”变化 非常之快。部分原因是开发活动极大地依赖于项目参与人员，而个体是难于 预测和量化的。软件的“不可触摸”性也是一个原因。在系统建成之前，有时很难判断一项 功能的具体价值。也就是说，只有当你在实实在在地使用系统时，你才能 知道哪些功能是有用的，哪些没什么用。软件开发的一切都取决于系统需求，如果需求不固定，你就不能制订出一个可 预见性的计划。3.不可预见过程的控制 － 迭代 那么，我们如何对付一个不可预测的世界呢？最重要，也是最困难的是要随时 知道我们在开发中的情形处境，这需要一个诚实的反馈机制来不断准确地告诉 我们。这种机制的关键之点是“迭代式”开发方法。这并不是一个 新思路，迭代式开发方法已存在很久了，只是名称不同。迭代式开发的要点是经常不断地生产出最终 系统的工作版本，这些版本逐部地实现系统所需的功能。它们虽然功能 不全，但已实现的功能必须忠实于最终 系统的要求，它们必须是经过全面整合和测试的产品。这样做的理由是：没有什么比一个整合了的、测试过的系统更能作为一个项目 扎扎实实的成果。文档可以隐藏所有的缺陷，未经测试的程序可能隐藏许多缺 陷。但当用户实实在在地坐在系统前来使用它时，所有的问题都会暴露出来。 这些问题可能是源码缺陷错误，也有可能是对需求理解有误。虽然迭代式开发也可用于可见性环境，但它基本上还是用作“适应性” 过程,因为适应性过程能及时地对付需求变更。需求变更使得长 期计划是不稳定的，一个稳定的计划只能是短期的，这通常是一个“迭代周 期”。迭代式开发能让每个迭代周期为下面的开发计划提供 一个坚实的基础。
此外，敏捷开发需要把人放在第一位，在软件开发中应以人为中心，其实这种概念在许多软 件行业的有识人士中已是共识。这造成了一个很强的正反馈机制。如果你期望你的开发人员是可互替的编程插件，则你不会去试着把他们看成是不同的个体。这会降低士气，并使优秀的人才跳到一个能发挥其个性特长的地方，最后你倒是得到你所需要的：可互替的编程插件。敏捷型过程中“以人为本”的理念可以有不同的表现，这会导致不同的效果， 而并非所有结果都是完全一致的。实施敏捷型过程的一个关键之处是让大家接受一个过程而非强加一个过程。 通常软件开发的的过程是由 管理人员决定的，因此这样的过程经常受到抵制，特别是如果管理人员已脱离 实际的开发活动很长时间了。而接受一个过程需要一种“自愿致力” ，这样大家就能以积极的态度参与进来。这样导致了一个有趣的结果，即只有开发人员他们自己才能选择并遵循一个适 应性过程。这一点在XP中特别明显，因为这需要很强的自律性来运行这个过程。 。另一点是开发人员必须有权作技术方面的所有决定。XP非常强调这一点。 在前期计划中，它就说明只有开发人员才能估算干一件工作所需的时间。对许多管理人员来说，这样形式的技术领导是一个极大的转变。这种途径要求 分担责任，即开发人员和管理人员在一个软件项目的领导方面有同等的地位。 注意我说的同等。管理人员仍然扮演着他们的角色，但需认识并尊重开发 人员的专业知识。之所以强调开发人员的作用，一个重要的原因是IT行业的技术变化速度非常之快。今天的新技术可能几 年后就过时了。这种情况完全不同于其他行业。即使管理层里的以前干技术的人 都要认识到进入管理层意味着他们的技术技能会很快消失，因此必须信任和依靠当前的开发人员。