敏捷软件开发
在软件开发中，通过与客户/最终用户的自组织和跨职能团队的协作努力，敏捷实践（有时编写的“敏捷”）包括要求，发现和解决方案的改进。这些价值观和原理在2001年的《敏捷软件开发》宣言中普及，源自包括Scrum和Manban在内的各种软件开发框架，并源于基础。
尽管有很多轶事证据表明采用敏捷实践和价值观提高了软件专业人士，团队和组织的有效性，但经验证据是混杂的，很难找到。
历史
迭代和增量软件开发方法早在1957年就可以追溯到1957年，并在1970年代初出现了进化项目管理和自适应软件开发。
在1990年代，许多轻量级软件开发方法反应了批评者所描述的过度调节，计划和微观管理的重量重量级方法（通常称为统称为瀑布）。这些轻巧的方法包括：1991年的快速应用开发（RAD）；从1994年起，统一的过程（UP）和动态系统开发方法（DSDM）; Scrum ，从1995年开始；从1996年起，晶体清晰而极端的编程（XP）；从1997年起，功能驱动的开发（FDD）。尽管所有这些都起源于敏捷宣言发表之前，但现在它们被共同称为敏捷软件开发方法。
自1991年以来，从精益管理中获得的制造和管理思维中已经进行了类似的变化。
2001年，17个软件开发人员在犹他州雪鸟的一个度假胜地举行了讨论轻量级开发方法。他们是：肯特·贝克（Extreme Programming）， Ward Cunningham （极端编程）， Dave Thomas （ Pragprog ，Ruby）， Jeff Sutherland （Scrum）， Ken Schwaber （Scrum）（Scrum）， Jim Highsmith （自适应软件开发）， Alistair Cockburn （Crystal）（Crystal） ，罗伯特·马丁（ Robert C. _ （Ruby， TDD ）和Steve Mellor （ OOA ）。他们一起发布了敏捷软件开发的宣言。
2005年，由Cockburn和Highsmith领导的一个小组撰写了项目管理原则的附录，即相互依存的PM声明，以根据敏捷软件开发方法指导软件项目管理。
2009年，与Martin合作的小组撰写了软件开发原则（软件工艺宣言）的扩展，以根据专业行为和精通来指导敏捷软件开发。
2011年，敏捷联盟创建了敏捷实践指南（2016年更名为敏捷词汇表），这是一部不断发展的开放源代码汇编，汇总了敏捷实践，术语和要素的工作定义，以及来自全球社区的解释和经验指南敏捷从业者。
敏捷软件开发的宣言
敏捷软件开发价值
根据他们开发软件并帮助他人做到这一点的综合经验，《宣言》的作者宣称他们重视：
- 个人和互动在流程和工具上
- 综合文档的工作软件
- 通过合同谈判的客户合作
- 响应遵守计划的变化
也就是说，尽管双方都有价值，应考虑右边的项目，但作者认为左边的项目应该对人们如何处理工作有更大的影响。
正如Scott Ambler所解释的那样：
- 工具和流程很重要，但是有效的人有效地共同努力更重要。
- 良好的文档对于帮助人们了解软件的构建方式以及如何使用它很有用，但是开发的重点是创建软件而不是文档。
- 合同很重要，但不能替代与客户紧密合作以发现所需的东西。
- 项目计划很重要，但绝不能太严格，无法适应技术或环境，利益相关者的优先事项以及人们对问题及其解决方案的理解。
一些作者组成了敏捷联盟，这是一个非营利组织，根据宣言的价值观和原则来促进软件开发。吉姆·高史密斯（Jim Highsmith）说，代表敏捷联盟介绍宣言
敏捷运动不是抗杀虫学，实际上我们许多人都想恢复对方法论一词的信誉。我们想恢复平衡。我们采用建模，但不是为了在尘土飞扬的公司存储库中提交一些图表。我们拥护文档，但不包括数百页从未维护和罕见的托米斯。我们计划，但认识到在动荡的环境中规划的局限性。那些会为XP或Scrum或任何其他敏捷方法论的人提供品牌支持者的人，对“黑客”一无所知。
-吉姆·高史密斯（Jim Highsmith），历史：敏捷宣言
敏捷软件开发原则
敏捷软件开发的宣言基于十二个原则：
- 通过早期和连续交付有价值的软件的客户满意度。
- 即使在晚期开发中，欢迎改变的要求。
- 经常（几周而不是几个月）交付工作软件。
- 关闭商人和开发商之间的日常合作。
- 项目建立在有积极的个人，应该值得信赖的人。
- 面对面的对话是交流的最佳形式（共置）。
- 工作软件是进度的主要度量。
- 可持续发展，能够保持持续的速度。
- 不断关注技术卓越和良好设计。
- 简单性 - 最大化未完成的工作量的艺术至关重要。
- 最佳体系结构，需求和设计来自自组织的团队。
- 定期，团队反思如何变得更加有效，并进行相应的调整。
概述
迭代，增量和进化
大多数敏捷开发方法将产品开发工作分为小额增量，以最大程度地减少前期计划和设计的数量。迭代或冲刺是短时间（时箱），通常持续一到四个星期。每次迭代都涉及一个在所有功能中工作的跨职能团队：计划，分析，设计，编码，单位测试和接受测试。在迭代结束时，有效的产品被证明是向利益相关者提供的。这可以最大程度地减少整体风险，并允许产品快速适应更改。迭代可能不会添加足够的功能来保证市场发布，但目标是在每次迭代结束时都可以使用可用的发布（最少的错误）。通过增量开发，在每个迭代阶段，产品都有“经常和早期失败”的空间，而不是在最终发布日期急剧。发布产品或新功能可能需要多次迭代。工作软件是进度的主要度量。
敏捷方法的关键优势是市场和降低风险的速度。较小的增量通常会发布到市场上，从而减少了工程不满足用户需求的产品的时间和成本风险。
高效和面对面的交流
软件开发的敏捷宣言的第六原则指出：“将信息传达给开发团队和内部的最有效方法是面对面的对话”。该宣言写于2001年，当时没有广泛使用视频会议，这与信息的通信有关，不一定应同居团队。
共同座位的原则是，同一团队的同事应放置在一起，以更好地建立一个团队的身份并改善沟通。这可以使面对面的互动（理想情况下在白板前面，这可以减少在通过电话，持续聊天，Wiki或电子邮件介导问题和答案时通常花费的周期时间。随着在Covid-19大流行期间远程工作的广泛采用以及对工具的变化，围绕共同定位和分布式工作进行了更多的研究，这表明共同定位越来越小的相关性。
无论遵循哪种开发方法，每个团队都应包括客户代表（ Scrum中的产品所有者）。利益相关者同意该代表代表他们采取行动，并为开发人员提供个人承诺，以在整个迭代中回答问题。在每次迭代结束时，项目利益相关者以及客户代表审核的进度并重新评估优先级，以期优化投资回报率（ROI）并确保与客户需求和公司目标保持一致。利益相关者满意度在每个阶段结束时频繁的互动和审查所详细介绍的重要性，就是为什么该方法通常表示为以客户为中心的方法。
信息散热器
在敏捷软件开发中，信息散热器是一个（通常大的）物理显示器，带有粘稠的板或类似的板，位于开发团队附近，路人可以看到它。它提供了产品开发状况的最新摘要。也可以使用构建灯指示器将其产品开发的当前状态告知团队。
非常短的反馈循环和适应周期
敏捷软件开发中的一个共同特征是每日站立（在Scrum框架中称为每日Scrum ）。在简短的会议（例如15分钟）中，团队成员共同审查了他们如何朝着自己的目标发展，并同意他们是否需要适应自己的方法。为了保持商定的时间限制，团队经常使用简单的编码问题（例如他们前一天完成的工作，他们的目标是完成什么，以及是否存在任何障碍或进步的风险），并延迟详细的讨论和问题解决直到站立后。
质量重点
特定的工具和技术，例如连续集成，自动化单元测试，配对编程，测试驱动的开发，设计模式，行为驱动的开发，域驱动的设计，代码重构和其他技术通常用于提高质量并增强产品开发敏捷。这是从一开始就设计和建立质量的基础，并且能够在任何时候或至少在每次迭代结束时为客户展示软件。
哲学
与传统的软件工程相比，敏捷软件开发主要针对复杂的系统和产品开发，具有动态，不确定性和非线性特性。准确的估计，稳定的计划和预测通常很难在早期阶段获得，对它们的信心很低。敏捷的从业者利用自己的自由意志来减少在获得任何价值证据之前所需的“信仰飞跃”。要求和设计将是紧急的。在这种情况下，大型前期规格可能会导致很多浪费，即在经济上并不是很合理的。这些基本的论点和以前的行业经验，从多年的成功和失败中学到的，有助于塑造敏捷发展的支持，迭代和进化发展。
自适应与预测
从自适应到预测性的连续体中存在开发方法。敏捷软件开发方法位于该连续体的自适应侧。自适应开发方法的一个关键是一种滚动浪量方法，用于安排计划，该方法确定了里程碑，但在达到目标的道路上留下了灵活性，并且还允许里程碑本身改变。
自适应方法着重于迅速适应不断变化的现实。当项目需要改变时，自适应团队也会改变。自适应团队很难确切描述将来会发生什么。日期越远，自适应方法越含糊地是关于该日期将发生的事情。自适应团队无法确切地报告他们下周将要做的任务，但只有他们计划在下个月计划的功能。当被问及六个月后的发布时，自适应团队可能只能报告发布的任务声明，或者是预期价值与成本的声明。
相比之下，预测方法着重于分析和计划未来，并满足已知风险。在极端情况下，一个预测团队可以准确地报告整个开发过程中计划的功能和任务。预测方法依赖于有效的早期分析，如果这是非常错误的，则项目可能难以改变方向。预测团队通常会建立一个变更控制委员会，以确保他们仅考虑最有价值的变化。
风险分析可用于在自适应（敏捷或价值驱动）和预测性（计划驱动）方法之间进行选择。巴里·鲍姆（Barry Boehm）和理查德·特纳（Richard Turner）建议连续体的每一侧都有自己的主场，如下所示：
| 价值驱动方法（敏捷） | 计划驱动方法（瀑布） | 正式方法 |
|---|---|---|
| 低关键性 | 高批判性 | 极端批判性 |
| 高级开发人员 | 初级开发人员（？） | 高级开发人员 |
| 要求经常改变 | 要求不经常改变 | 有限的要求，有限的功能，请参阅Wirth的定律 |
| 少数开发人员 | 大量开发人员 | 可以建模的要求 |
| 回应变革的文化 | 需要秩序的文化 | 极端质量 |
敏捷与瀑布
敏捷软件开发方法和瀑布之间的差异之一是质量和测试的方法。在瀑布模型中，工作贯穿软件开发生命周期（SDLC）阶段（在一个阶段都可以在另一个阶段开始之前完成），因此测试阶段是分开的，并且遵循构建阶段。但是，在敏捷软件开发中，测试以与编程相同的迭代完成。
因为在每次迭代中都进行了测试（开发一小部分软件），用户可以经常使用这些新软件并验证该值。在用户知道更新的软件的实际价值之后，他们可以更好地决定软件的未来。在每次迭代中都有一个价值回顾性和软件重新规划会话（ Scrum通常只有两个星期），团队不断调整其计划，以最大程度地提高其所提供的价值。这是按照计划，完成，检查工作（在审查和回顾性中）的计划，类似于计划检查的模式（PDCA）周期，并采取了所有同意的更改。
这种迭代方法支持产品而不是项目心态。这在整个开发过程中提供了更大的灵活性；而在项目上，要求从一开始就定义并锁定，因此以后很难更改它们。迭代产品开发使软件可以响应业务环境或市场需求的变化而发展。
代码与文档
在给IEEE计算机的一封信中，史蒂文·拉基汀（Steven Rakitin）对敏捷软件开发表示了愤世嫉俗的愤世嫉俗，称其为“又一次破坏软件工程学科”，并将“工作软件而不是全面文档进行翻译”，为“我们想花费所有时间编码。请记住，真正的程序员不会编写文档。”
这是敏捷软件开发的支持者对此提出争议的，他们说，如果这是实现相关目标的最佳方法，则开发人员应该撰写文档，但是通常有比编写静态文档更好的方法来实现这些目标。斯科特·安伯勒（Scott Ambler ）指出，文档应该“勉强足够好”（JBGE），过多或全面的文档通常会造成浪费，而开发人员很少信任详细的文档，因为它通常与代码不同步，而文档太少也可能导致。维护，沟通，学习和知识共享的问题。阿利斯泰尔·科克本（Alistair Cockburn）写了清晰的方法：
Crystal认为开发一系列合作游戏，并打算该文档足以帮助下一场比赛的下一个胜利。水晶的工作产品包括用例，风险清单，迭代计划，核心域模型和设计说明以告知选择...但是，这些文档没有模板，并且描述一定是含糊的，但是目标是明确的，只有下一场比赛的足够文档。我总是倾向于将其描述给我的团队：您明天是否加入团队，您想知道什么。
- Alistair Cockburn
敏捷软件开发方法
敏捷软件开发方法支持软件开发生命周期的广泛范围。一些方法着眼于实践（例如XP ，务实的编程，敏捷建模），而某些方法则专注于管理工作流程（例如，Scrum，斜视）。一些支持规范和开发的支持活动（例如， FDD ），而有些人则寻求涵盖完整的发展生命周期（例如， DSDM ， RUP ）。
著名的敏捷软件开发框架包括：
| 框架 | 主要贡献者 |
|---|---|
| 自适应软件开发（ASD） | 吉姆·高史密斯（Jim Highsmith） ，山姆·拜耳 |
| 敏捷建模 | 斯科特·安伯勒（Scott Ambler） ，罗伯特·塞西尔·马丁（Robert Cecil Martin） |
| 敏捷统一过程（AUP） | 斯科特·安伯勒（Scott Ambler） |
| 纪律处分敏捷交付 | 斯科特·安伯勒（Scott Ambler） |
| 动态系统开发方法（DSDM） | 詹妮弗·斯塔普尔顿（Jennifer Stapleton） |
| 极限编程（XP） | 肯特·贝克（Kent Beck ），罗伯特·塞西尔·马丁（Robert Cecil Martin） |
| 功能驱动开发（FDD） | 杰夫·德·卢卡（Jeff de Luca） |
| 精益软件开发 | 玛丽·波普迪克（Mary Poppendieck），汤姆 |
| 精益创业 | 埃里克·里斯（Eric Ries） |
| 看板 | 太极拳 |
| 快速应用开发（RAD） | 詹姆斯·马丁 |
| Scrum | 杰夫·萨瑟兰（Jeff Sutherland）的肯·施瓦伯（Ken Schwaber） |
| Scrimban | |
| 缩放敏捷框架 - 安全 | 缩放敏捷公司 |
敏捷软件开发实践
敏捷软件开发得到了许多具体实践的支持，涵盖了需求，设计，建模，编码，测试，计划，风险管理，过程，质量等。
| 实践 | 主要贡献者 |
|---|---|
| 接受测试驱动开发（ATDD） | |
| 敏捷建模 | |
| 敏捷测试 | |
| 积压（产品和冲刺） | 肯·施瓦伯（Ken Schwaber） |
| 行为驱动的发展（BDD） | Dan North，Liz Keogh |
| 连续集成（CI） | Grady Booch |
| 跨职能团队 | |
| 每日站立 /每日混乱 | 詹姆斯·科普林 |
| 域驱动设计（DDD） | 埃里克·埃文斯（Eric Evans） |
| 迭代和增量发展（IID） | |
| 配对编程 | 肯特·贝克 |
| 计划扑克 | 詹姆斯·格伦宁（James Grenning），迈克·科恩（Mike Cohn） |
| 重构 | 马丁·福勒 |
| 回顾 | |
| Scrum活动（冲刺计划，Sprint审查和回顾） | |
| 按示例规范 | |
| 故事驱动的建模 | 阿尔伯特·苏恩多夫（AlbertZündorf） |
| 测试驱动的开发（TDD） | 肯特·贝克 |
| 时箱 | |
| 用户故事 | Alistair Cockburn |
| 速度跟踪 |
接受测试驱动的开发
敏捷建模
敏捷测试
积压
行为驱动的发展
持续集成
跨职能团队
日常站立
方法裁缝
在文献中，不同的术语是指方法适应的概念，包括“方法裁缝”，“方法片段适应”和“情境方法工程”。方法裁缝定义为：
人类代理人通过响应迅速的变化以及上下文，意图和方法片段之间的动态相互作用来确定特定项目状况的系统开发方法的过程或能力。
- Mehmet Nafiz Aydin等人，一种使用的敏捷信息系统开发方法
情况 - 批准性应被视为敏捷方法与更具计划驱动的软件开发方法之间的区别特征，并采用敏捷方法，允许产品开发团队根据单个产品的需求调整工作实践。潜在地，大多数敏捷方法可能适用于定制方法，例如在CMM上下文中量身定制的DSDM 。 XP根据规则说明实践（RDP）技术量身定制。但是，并非所有敏捷的支持者都同意，Schwaber指出：“这首先是我们如何陷入困境的方式，认为问题不是有完美的方法。[应该]努力以企业中的变化为中心”。 。 Bas Vodde加强了这个观点，表明与传统的大型方法不同，需要您选择元素，Scrum在其上提供了基础知识，您可以添加其他元素来本地化和上下文化其使用。从业者很少使用本书使用系统开发方法或敏捷方法，通常选择省略或量身定制方法的某些实践来创建内部方法。
实际上，可以使用各种工具来量身定制方法。通用过程建模语言（例如统一建模语言）可用于量身定制软件开发方法。但是，对于方法工程的专用工具，例如SEMAT软件工程的本质理论。
大规模，离岸和分发
敏捷软件开发已被广泛认为非常适合某些类型的环境，包括从事Greenfield项目的小组专家团队，以及在具有传统基础设施的大型组织中采用敏捷软件开发方法所遇到的挑战和局限性是很好的记录并理解。
作为回应，通过大规模开发工作（> 20个开发人员）或分布式（非关联）开发团队克服挑战的一系列策略和模式，以及其他挑战；现在有几个公认的框架试图减轻或避免这些挑战。
关于所有这些是有效还是符合敏捷发展的定义，这仍然是一个积极且持续的研究领域，存在许多矛盾的观点。
当在分布式设置中应用敏捷软件开发（团队分散在多个业务位置）时，通常称为分布式敏捷软件开发。目标是利用每种方法提供的独特好处。分布式开发允许组织通过战略性地在全球不同地区建立团队来构建软件，实际上是在全天候构建软件（通常称为以下模型）。另一方面，敏捷开发在响应变化时提供了提高的透明度，持续反馈和更灵活的性能。
受管域
敏捷软件开发方法最初被视为最适合非关键产品开发，从而被排除在受监管的领域，例如医疗设备，药品，金融，核系统，汽车和航空电子部门等。但是，在最后几个多年来，已经有几项针对这些领域适应敏捷方法的举措。
在规范的域中可能有许多标准，包括ISO 26262 ， ISO 9000 ， ISO 9001和ISO/IEC 15504 。在受监管的领域中，许多关键问题特别重要：
- 质量保证（QA）：系统和固有的质量管理基于受控的专业流程以及产品的可靠性和正确性。
- 安全与保障：正式的计划和风险管理，以减轻用户的安全风险，并安全地保护用户免受意外和恶意滥用。
- 可追溯性：提供法规合规性的可审计证据，并促进可追溯性和问题的调查。
- 验证和验证（V＆V）：嵌入整个软件开发过程（例如用户需求规范，功能规范，设计规范，代码审核，单位测试，集成测试，系统测试）。
经验和收养
尽管在实践中可以与任何编程范式或语言一起使用敏捷软件开发方法，但它们最初与面向对象的环境（例如SmallTalk，Lisp和后来的Java，C＃）密切相关。敏捷方法的最初采用者通常是在没有前所未有的系统上工作的中型团队，这些团队的要求很难最终确定，并且随着系统的开发，可能会发生变化。本节描述了组织试图采用敏捷软件开发方法以及各种技术来衡量敏捷团队的质量和性能时遇到的常见问题。
测量敏捷性
内部评估
敏捷性测量指数（除其他）与产品开发的五个维度（持续时间，风险，新颖性，努力和相互作用）相比，对开发进行了评分。其他技术基于可测量的目标，一项研究表明，速度可以用作敏捷性的度量。还有敏捷的自我评估来确定团队是否使用敏捷软件开发实践（诺基亚测试，Karlskrona测试，42分测试）。
公共调查
一项早期研究通过使用敏捷软件开发方法来报导质量，生产力和业务满意度的提高是Shine Technologies从2002年11月至2003年1月进行的一项调查。
从2006年开始，每年都有一项类似的调查，即敏捷状况，来自软件开发社区周围的成千上万的参与者。这跟踪了敏捷性，经验教训和良好实践的感知益处的趋势。每项调查都报告越来越多的人数表明敏捷软件开发可以帮助他们更快地交付软件。提高他们管理不断变化的客户优先事项的能力；并提高其生产率。与经典项目管理相比，通过敏捷产品开发方法，调查还始终显示出更好的结果。在平衡上，有些人认为敏捷发展方法还太年轻，无法实现其成功的广泛学术研究。
常见的敏捷软件开发陷阱
实施敏捷软件开发的组织和团队通常会从更传统的方法（例如瀑布开发）过渡，例如在瀑布开发等更传统的方法中，例如在他们身上进行了敏捷过程。这些通常被称为敏捷的抗模式或更常见的敏捷气味。以下是一些常见的例子：
缺乏整体产品设计
敏捷软件开发的目标是将更多的精力集中在生产工作软件上，而不是文档上。这与瀑布模型相反，瀑布模型通常受到高度控制，并且对系统的微小更改需要对支持文档进行重大修改。但是，这根本没有任何分析或设计，这并不能完全证明完全是合理的。不关注设计可能会导致团队起初迅速进行，但随后在尝试扩展系统时需要进行大量返工。敏捷软件开发的关键特征之一是它是迭代的。正确完成后，敏捷软件开发可以随着系统的开发而出现设计，并帮助团队发现重复使用的共同点和机会。
将故事添加到正在进行的迭代中
在敏捷软件开发中，通常使用故事（类似于用例描述）来定义要求，迭代是团队致力于特定目标的短时间。将故事添加到正在进行的迭代中对良好的工作流程有害。这些应添加到产品积压中，并在后续迭代中优先考虑，或者在极少数情况下可以取消迭代。
这并不意味着故事不能扩展。团队必须处理新信息，这可能会为故事产生其他任务。如果新信息阻止了故事在迭代期间完成，则应将其转移到随后的迭代中。但是，应该优先考虑所有剩余故事，因为新信息可能改变了故事的原始优先级。
缺乏赞助商支持
敏捷软件开发通常是通过试图优化其开发过程并确保软件开发生命周期一致性的软件开发团队在组织中实施的。通过没有赞助商的支持，团队可能会面临业务伙伴，其他开发团队和管理层的困难和抵抗。此外，他们可能会在没有适当资金和资源的情况下受苦。这增加了失败的可能性。
培训不足
一项由版本的人进行的调查发现，受访者认为培训不足是敏捷实施失败的最重大原因，与其他方法相比，假设敏捷软件开发流程减少的过程（例如瀑布），这意味着没有敏捷的实际规则软件开发。
产品主角色未正确填补
产品所有者负责代表开发活动中的业务，并且通常是最苛刻的角色。
一个普遍的错误是与开发团队的某人一起填补产品主角色。这要求团队在优先级上做出自己的决策，而无需企业的真实反馈。他们试图在内部解决业务问题或延迟工作，因为他们到达团队以外的方向。这通常会导致分心和协作的细分。
团队不集中
敏捷软件开发要求团队满足产品承诺，这意味着他们应该只专注于该产品的工作。但是，通常期望似乎拥有备用能力的团队成员从事其他工作，这使得他们很难帮助完成团队所承诺的工作。
过度准备/计划
团队可能会陷入花费太多时间准备或计划的陷阱。对于不熟悉敏捷软件开发的团队来说，这是一个常见的陷阱，在该团队中，团队不得不对所有故事有完整的理解和规范。团队应准备仅通过那些有信心的故事前进，然后在迭代期间继续发现并为随后的迭代做准备（通常称为积压的精炼或修饰）。
每日站立中解决问题
每日站立应该是一个集中，及时的会议，所有团队成员都在传播信息。如果发生解决问题的话，它通常只能涉及某些团队成员，并且可能不是整个团队时间的最佳利用。如果在每日站立期间，团队开始潜入解决问题的问题，则应将其放在一边，直到副团队可以讨论，通常是在站立后立即完成。
分配任务
敏捷软件开发的预期好处之一是使团队能够做出选择，因为他们最接近问题。此外，他们应该尽可能接近实施，以在决策中使用更多及时的信息。如果团队成员是由他人分配的任务，或者在此过程中过早地分配了任务，则本地化和及时决策的好处可能会丢失。
被分配的工作还将团队成员限制为某些角色（例如，团队成员A必须始终执行数据库工作），这限制了交叉训练的机会。团队成员自己可以选择承担扩展能力并提供交叉训练机会的任务。
Scrum Master作为贡献者
在声称与敏捷的价值观和原则一致的Scrum框架中， Scrum Master角色负责确保遵循Scrum过程以及在该过程中指导Scrum团队。一个常见的陷阱是使Scrum大师担任贡献者。尽管没有被Scrum框架禁止，但Scrum Master需要确保他们有能力首先发挥Scrum Master的作用而不是在开发任务上。 Scrum Master的角色是促进该过程而不是创建产品。
拥有Scrum Master也可以多任务处理可能会导致上下文开关太多而无法生产。此外，由于Scrum Master负责确保拆除障碍，以便团队可以取得进步，因此，通过未能承受能力，前进的个别任务所获得的收益可能不会超过被推迟的障碍。
缺乏测试自动化
由于敏捷开发的迭代性质，通常需要进行多轮测试。自动测试有助于减少重复单元，集成和回归测试的影响，并释放开发人员和测试人员的重点，以专注于更高的价值工作。
测试自动化还支持迭代软件开发所需的继续重构。允许开发人员快速运行测试以确认重构，但没有修改应用程序的功能，可以减少工作量，并增加对清理工作未引入新缺陷的信心。
允许技术债务增加
专注于提供新功能可能会导致技术债务增加。团队必须让自己有时间进行缺陷修复和重构。技术债务通过增加计划缺陷的数量来阻碍计划能力，因为生产缺陷使团队不受进一步的进展。
随着系统的发展，重构很重要。随着时间的流逝，缺乏恒定维护会导致缺陷和发展成本增加。
试图在迭代中承担太多
一个普遍的误解是，敏捷软件开发允许持续更改，但是迭代积压是在迭代过程中可以完成的工作的协议。过多的工作（WIP）导致效率低下，例如上下文开关和排队。团队必须避免感到压力，以进行其他工作。
固定时间，资源，范围和质量
敏捷软件开发可以修复时间（迭代持续时间），质量以及理想情况下的资源（尽管如果经常将开发人员从任务中撤离以处理生产事件，那么维护固定资源可能会很困难），而范围仍然可变。客户或产品所有者通常会为迭代固定范围推动固定范围。但是，团队应不愿承担锁定的时间，资源和范围（通常称为项目管理三角形）。为固定时间和敏捷软件开发的资源增加范围的努力可能会导致质量下降。
开发人员倦怠
由于敏捷实践的重点和持续的性质，交付团队成员的倦怠风险增加。
敏捷管理
敏捷项目管理是一个迭代开发过程，在该过程中，反馈是从用户和利益相关者不断收集的，以创建合适的用户体验。可以使用不同的方法来执行敏捷过程，其中包括Scrum ， Extreme编程，精益和看板。敏捷管理一词适用于一种迭代，增量的方法，用于管理工程，信息技术和其他业务领域的设计和建立活动，旨在根据表达的原则以非常灵活和互动的方式提供新产品或服务开发在敏捷软件开发的宣言中。敏捷项目管理指标有助于减少混乱，确定弱点并在整个开发周期中衡量团队的绩效。供应链敏捷性是供应链应对所提供和需求的不确定性和可变性的能力。敏捷的供应链可以迅速增加并降低其容量，因此它可以适应瞬息万变的客户需求。最后，战略敏捷性是组织随着环境的发展而改变其行动进程的能力。战略敏捷性的关键是要尽早识别外部变化，并分配资源以适应这些不断变化的环境。
敏捷X技术也可以称为极端项目管理。它是迭代生命周期的一种变体，其中可交付成果分阶段提交。敏捷和迭代开发之间的主要区别在于，敏捷方法在每个交付周期（迭代）中完成了一小部分可交付成果，而迭代方法会随着时间的推移发展整个可交付成果，并在项目结束时完成。迭代和敏捷方法都是作为对以更顺序的项目组织形式发展的各种障碍的反应。例如，随着技术项目的复杂性增长，最终用户往往难以定义长期需求，而无需查看渐进的原型。在迭代中发展的项目可以不断收集反馈，以帮助完善这些要求。
敏捷管理还提供了一个简单的框架，促进了团队成员过去工作的沟通和反思。正在使用传统瀑布计划并采用敏捷发展方式的团队通常会经历转型阶段，并且经常得到敏捷教练的帮助，这些敏捷教练可以帮助团队通过更平滑的转型。敏捷教练通常有两种风格：基于推动和基于拉的敏捷教练。在这里，“推送系统”可以提到可以将哪些任务安装到Sprint（推动工作）中的前期估计，例如典型的scrum；而“拉动系统”可以指的是只有在工作可用时执行任务的环境，例如斜视的典型。敏捷管理方法也已被采用并适应了商业和政府部门。例如，在美国联邦政府内部，美国国际发展机构（USAID）正在采用一种协作项目管理方法，重点是将协作，学习和适应（CLA）策略纳入迭代和适应编程。
在产品开发生命周期定义下的项目管理知识机构（ PMBOK指南第6版）的指南中提到了敏捷方法：
“在项目生命周期内，通常有一个或多个阶段与产品，服务或结果的开发相关。这些被称为开发生命周期（...）自适应生命周期是敏捷，迭代或增量。详细的范围是在迭代开始之前定义和批准的。自适应生命周期也称为敏捷或变更驱动的生命周期。
软件开发以外的应用程序
Jean-Loup Richet（ ESSEC战略创新与服务研究所的研究员）表示：“这种方法可以有效地用于非软件产品和一般项目管理，尤其是在创新和不确定性领域。”结果是一个最能满足当前客户需求的产品或项目，并以最低的成本，浪费和时间交付，使公司能够比传统方法更早获得底线增长。
敏捷软件开发方法已广泛用于软件产品的开发，其中一些使用软件的某些特征，例如对象技术。但是，这些技术可以应用于非软件产品的开发，例如计算机，医疗设备，食物，服装和音乐。敏捷软件开发方法已用于非开发IT基础架构部署和迁移。敏捷软件开发的一些更广泛的原则也发现了根据业务敏捷性或敏捷业务管理条款在总体管理中的应用（例如，战略，治理，风险，金融）。
敏捷软件开发范例可用于生活的其他领域，例如养育儿童。它在儿童发展方面的成功可能基于一些基本管理原则。沟通，适应和意识。在TED演讲中，布鲁斯·费勒（Bruce Feiler）分享了他如何将基本的敏捷范式应用于家庭管理和抚养孩子。
批评
在大型组织和某些类型的发展中，敏捷实践被认为是潜在的效率低下。许多组织认为，敏捷软件开发方法太极端了，并且采用了混合方法，将敏捷软件开发元素和计划驱动方法融合在一起。某些方法，例如动态系统开发方法（DSDM）以纪律处分尝试，而不会牺牲基本原则。
敏捷实践的越来越多的采用也被批评是一种管理时尚，它只是描述了新的术语下的现有良好实践，促进了一种尺寸，这符合全部思维方式，符合发展策略，并错误地强调方法而不是结果。
阿利斯泰尔·科克本（Alistair Cockburn）于2011年2月12日在犹他州雪鸟（Snowbird）举行了宣传宣言敏捷软件开发纪念日的庆祝活动，聚集了约30多人参加了原始会议，此后。收集了房间中约20只大象的清单（“不可思议”的敏捷主题/问题），包括方面：敏捷软件开发实践和环境的联盟，失败和局限基于失败，客观证据，认知偏见和推理谬论取得进展），政治和文化。正如Philippe Kruchten所写：
敏捷运动在某种程度上有点像一个少年：非常自觉，不断地检查它在镜子里的外表，很少接受批评，只有对与同龄人在一起的兴趣，拒绝了过去的所有智慧，只是因为它是因为它来自过去，采用时尚和新的术语，有时是自大而傲慢的。但是我毫无疑问，它将进一步成熟，对外界更加开放，更具反思性，因此更有效。
- Philippe Kruchten
“宣言”可能对高等教育管理和领导力产生了负面影响，在此建议管理员建议较慢的传统和审议过程应替换为更多的“灵活”。这个概念很少在大学教师中得到接受。
另一个批评是，从许多方面来说，敏捷管理和传统管理实践最终彼此反对。对这种做法的普遍批评是，尽管潜在的好处，但尝试学习和实施这种做法花费的时间太昂贵了。从传统管理到敏捷管理的过渡需要全部提交给敏捷，以及组织的所有成员的坚定承诺，以查看该过程。整个组织中不平等的结果，员工处理能力的变化太多，或者在转型结束时缺乏保证只是一些例子。
也可以看看
- 跨职能团队
- Scrum（软件开发）
- FAST（Business）失败，这是业务管理中的相关主题
- 看板
- 敏捷的领导
- 敏捷合同