敏捷软件开发

词源

敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。
迭代和增量式软件开发方法可以追溯到1957年。进化式项目管理和适应性软件开发出现在1970年代初期。在1990年代，因针对重量级的软件开发方法的批评，而发展了许多轻量化的软件开发方法、项目与细微化开发管理。包含了，从1991年开始的迅速应用程序开发、从1994年开始的统一进程与动态系统开发法（DSDM）、从1995年的Scrum、从1996年的水晶清透法与极限编程法、1997年的功能驱动开发。虽然那些开发法都起源于敏捷开发宣言之前，但都统称为敏捷软件开发法。在此同时，制造业与航空业也遭遇相同变化。
在2001年，十七名软件开发人员在犹他州的雪鸟度假村会面，讨论这些轻量级的开发方法，并由Jeff Sutherland，Ken Schwaber和Alistair Cockburn发起，一同发布了“敏捷软件开发宣言”。
在2005年，由Alistair Cockburn和Jim Highsmith领导的小组编写了一份项目管理原则的附录，即“相互依存声明”，以便根据敏捷软件开发方法来指导软件项目管理。
在2009年，罗伯特·C·马丁（Robert C Martin）编写了软件开发原则的扩展，即软件工艺宣言（Software Craftsmanship Manifesto），根据职业行为和掌握程度来指导敏捷软件开发。
在2011年，敏捷联盟创建了敏捷实践指南（2016年更名为“敏捷词汇”）、敏捷实践、术语和元素工作定义的演化开放式汇编，以及来自敏捷从业者社群的经验指南。

总览

迭代、渐进和进化
大多数敏捷开发方法将产品开发工作细分微小化，因此大大的减少了前期规划和设计的数量。迭代或冲刺都是短时间的框架(时间)，通常持续一到四周。每个迭代都具有跨功能、职能的团队，包含了规划、分析、设计、程序编码、单元测试和验收测试。在迭代结束时，将工作产品向利益相关者展示。透过上述方式让整体风险降至最低，并使产品能够快速适应变化。迭代的方式，可能不会一次增加足够的功能来保证可立即发布使用，但是目标是在每次迭代结束时，有一个可用的发行版（最小化程序缺点）。因此完整产品的发布或新功能可能需要多次迭代。
工作软件是进化的主要手段
高效率的面对面沟通
无论采用哪种开发方式，每个团队都应该包含一个客户代表（Scrum中的产品负责人）。这个人是由利益相关者同意代表他们行事，并作出个人承诺，回应开发人员在开发迭代过程中的问题。在每次迭代结束时，利益相关方和客户代表将审查进度并重新评估优先级，以优化投资回报（ROI）并确保与客户需求和公司目标保持一致。在敏捷软件开发中，会在开发团队附近设置一个消息发布器（通常很大）实体显示器，甚至路人也可以看到它。它提供了最新的产品开发状态摘要。并透过建置状态指示灯以通知团队他们的产品开发的当前状态。
非常短的反馈回路和适应周期
敏捷软件开发中的一个共同特点就是每日站立（也被称为日常scrum）。 在一个简短的会议中，团队成员相互报告他们前一天对于团队的迭代目标、今天打算做的目标以及他们可以看到的任何障碍或阻碍。
质量焦点
经常使用诸如持续集成、自动化单元测试、配对程序开发、测试驱动开发、设计模式、领域驱动设计，代码重构和其他技术的特定工具和技术来提高质量和提高产品开发敏捷性

剪裁法

在文献中，有不同的术语指适应法的概念，包括“剪裁法”、“片段适应法”和“情景方法工程”。 方法剪裁被定义为：一个程序或能力，在这个程序或能力中，人类代理程序通过在情境、意图和方法片段之间的响应变化和动态的相互作用来确定特定项目情境的系统开发方法。
几乎所有的敏捷方法都适用于剪裁法。即使是DSDM方法也被用于此目的，并且已经成功地在CMM环境中进行了定制。敏捷法和传统的软件开发法之间的情境适应性，可以被认为是一个明显的特征，后者因规范而相对更加僵化。敏捷法实际的含义是可以使产品开发团队根据个别产品的需求来调整工作实践。实践是作为方法框架一部分的具体活动和产品。在更为极端的层面上，可以调整由多种原则组成的方法背后的哲学（Aydin，2004）。
某些方法，如Scrum和极限编程，使得方法适应的需求是明确的。有了这些不太规范的框架，原则之一就是没有一个程序适合每一个产品的开发，而是应该根据产品的需求量身定做。 Mehdi Mirakhorli提出了一个剪裁实践，为适应所有实践提供了足够的路线图和指导方针。RDP 的实践是为极限编程而设计的。这种做法首先作为ICSE 2008会议APSO研讨会上的一篇长篇研究论文提出，是当前唯一提出并且适用于定制极限编程的方法。虽然它是专门针对极限编程的解决方案，但是这种做法有扩展到其他方法的能力。乍看之下，这种做法似乎属于静态方法适应的范畴，但RDP实践的经验表明，它可以像动态方法适应一样对待。静态方法适应和动态方法适应之间的区别是微妙的。
Scrum不是为剪裁法而设计的。 Schwaber指出：“Scrum不是一种需要加强的方法，这是我们首先遇到的麻烦，认为问题没有一个完美的方法，努力集中在企业所需的变化上。 Bas Vodde强调了这一说法，表明Scrum不像传统的大型方法论，需要你“挑选”元素。 这是基础知识的基础上，您添加额外的元素来本地化和使用情况。

对比其他的方法

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

对比迭代方法

相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。

对比瀑布式开发

两者没有很多的共同点，瀑布模型是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。
有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行，例如极限编程。

用于敏捷开发团队的项目管理工具

已经有一些项目管理工具用于敏捷开发，可以用它们来帮助规划，跟踪，分析和集成工作。
这些工具在敏捷开发中扮演的重要的角色，也是知识管理的一种方法。
通常包括：版本控制集成，进度跟踪，工作分配，集成发布和迭代规划，论坛和软件缺陷的报告和跟踪。