敏捷开发的由来

敏捷开发是全球主流的软件开发模式，从上世纪九十年代就开始逐渐引起广泛关注的软件开发方法，它是一种应对快速变化的需求的一种软件开发能力。在2001年，17位自称“有组织的无政府主义者”在Utah（犹他州）的Snowbird（雪乌）分享了互相竞争的几种方式：极限编程（XP）；透明化；自适应软件开发（ASD）；特征驱动开发（FDD）；动态系统开发方法（DSDM）。这些方式都是“轻量版”的框架，使用更少，更简单的规则来适应快速变化的环境，并且为这个运动取了个名字：敏捷。有了这个名字后，参与者们达成一致，发布了“敏捷软件开发宣言”，该宣言中突出了每个人都同意的4个关键价值。之后的几个月中，他们发展了12个操作原则，被称为“敏捷宣言背后原则”。从2011年开始，所有的开发框架，以及与之匹配的价值观和原则就被称作为敏捷技术。

开发宣言

针对传统开发模式

个体与交互 高过 过程与工具

项目启动时，需要用一些项目管理方法和工具进行开发管理。合适的工具能很好的帮助开发，但当在开发人员面前出现大量庞大笨重甚至不好用的工具和开发环境时效率就会开始降低到最后无法前进。

但并不是说就不需要过程和工具了。敏捷项目首先拥有一个小规模但拥有各种不同职能的成员，每个成员都需要定时和团队的其他成员一起查看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力，可以自发的通过各种途径解决开发过程中遇到的问题，所以需要哪些过程和工具应该是由自组织团队制定的。

可以工作的软件 高过 面面俱到的文档

编写一份详尽的需求文档总是好的，然而文档承载着各阶段之间的信息传递。例如产品文档、需求文档、接口文档等，除非有充足的时间，否则我们不可能一开始就想清楚所有细节。另外编写文档需要花费大量的时间，仍旧只能以降低质量来遵循计划的执行。

难道就不需要文档了吗？面面俱到的文档对客户来说确并不重要，用户需要的是一个能够运行起来，能够实质解决工作中问题的可以工作的软件。面面俱到的文档对开发团队也不重要，对开发团队来说最好的两份文档就是代码和团队。通过频繁的提供可以工作的软件，我们也可以更为频繁的搜集对产品和开发过程的反馈，保证开发人员始终是在处理最具有价值的功能，而且这些功能可以满足用户的需要。在开发过程中需要进行内部交流，也需要和客户交流，我们仍旧可能需要制作原型，书写一些主要需求，只要自组织团队认为足够就可以了。

客户协作 高过 合同谈判

项目开发一般都是跟随着合同开始的，在开发期间，如果需要变更合同，则需要经过一系列变更流程，遇到一些客户只是简单的询问一下进度，有的甚至是到最后交付日了直接来问你要东西，并且在开发过程中也不会进行实质性的反馈，导致最终的产品不满意，还得重新商讨解决方案。

寻求客户合作的价值重于对合同的谈判。敏捷开发提倡客户和开发团队密切的在一起工作，并尽量经常行得提供反馈。利用短期迭代，通过尽早提供软件来达到与客户频繁沟通和反馈的，这也可以把问题暴露出来，以免在后期造成更大的影响。虽然我们致力于客户协作，但为了双方利益和需要仍旧需要进行合同谈判。

响应变化 高过 遵循计划

项目开始之后，负责人制定出明确的计划，详细列出需求、设计、开发、测试的各项任务，并拟定看似完整齐全的计划，并以此不变的计划作为对客户的承诺。但是开发过程中存在很多不确定性，这来自于每个人拥有不同的技能、经验和观点，因此在一起合作时会使得开发过程变得复杂。但为了保证”遵循计划“，会忽略这些不稳定的因素。最后就势必导致提供给客户的是一个不满意的产品。

计划赶不上变化，敏捷不是不需要计划，相反它需要更多的规划。许多项目管理方法是“规划、规划。规划－执行”，而敏捷开发方法是“规划－执行－调整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要，不断学习和调整是敏捷开发的核心。虽然我们致力于响应变化，但并不是不需要计划了，只是变得更多规划了。

尽管右项有其价值，但我们更重视左项的价值。

原则

• 我们最优先考虑的是尽早和持续不断地交付有价值的软件，从而使客户满意。

• 即使在开发后期也欢迎需求变更。敏捷过程利用变更可以为客户创造竞争优势。

• 采用较短的项目周期（从几周到几个月），不断地交付可工作软件。

• 业务人员和开发人员必须在整个项目期间每天一起工作。

• 围绕富有进取心的个体而创建项目。为他们提供所需的环境和支持，信任他们所开展的工作。

• 不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈。

• 可工作软件是度量进度的首要指标。

• 敏捷过程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。

• 坚持不懈的追求技术卓越和良好的设计，从而增强敏捷能力。

• 以简洁为本，最大限度的减少工作量。

• 最好的架构、需求和设计出自于自组织团队。

• 团队定期地反思如何提高成效，并相应地协调和调整自身的行为。

优点

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。传统开发方法是基于客户能够在需求阶段就给出完整、准确的需求，期望于在项目初期获得详细的需求，然后严格控制需求变更，最终完成符合需求的软件。但随着开发的不断进展而不断更改的需求，根本无法在项目初期就明确的定义它。敏捷开发，相对传统软件开发模式，认为需求是无法在早期完全确定的，所以采用的是基于经验的开发方法，也就是说事先不详细定义整个开发过程，而通过多次迭代来逼近最终目标。它主要是针对快速变化的需求，不断优化管理流程，最终推出优质软件。

缺点

• 对参与员工的个人能力和态度要求比较高
• 长期的面对面沟通最终会导致低效
• 人员流动较大，导致简化的文档不能满足
• 客户的理解与配合
• 适合小型的企业需求

解决的办法

• 事前做培训。
• 不需要每一步都记录，拟定大致的轮廓。
• 需要客户配合时，简化阐述。
• 大项目开发具体问题具体分析，根据项目特点制定敏捷计划。

总结

敏捷开发是一种过程控制的方法，用短周期迭代，可视化流程，自适应调整，及时沟通对产品需求做高效管理。