敏捷开发的概念起源于20世纪90年代末期，旨在解决传统软件开发方法中存在的效率低下问题。
传统软件开发方法因其繁琐的过程和对文档的严格要求，导致了“重型化危机”，这使得开发效率大幅下降。为了应对这些问题，敏捷方法应运而生。
敏捷开发的起源可以追溯到2001年2月，当时Martin Fowler、Jim Highsmith等17位软件开发专家在美国犹他州雪鸟滑雪圣地聚集，共同签署了《敏捷宣言》，标志着敏捷开发作为一种新的软件开发方法正式诞生。
敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。
敏捷宣言4个核心价值观：
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
敏捷项目管理的12个原则：
这些原则旨在鼓励更敏捷、灵活和高效的项目管理方法，使项目团队能够更好地满足客户需求、应对变化并持续提供高质量的产品。
敏捷开发的核心原则包括主张简单、尽早交付、可持续的开发以及不断改进。这些原则强调了软件开发过程中应注重简单性和实用性，通过迭代和循序渐进的方式不断交付可工作的软件，并基于客户反馈进行调整和优化。
1、客户满意度最高的优先级是通过早期和持续交付有价值的软件来满足客户。
示例：在软件开发项目中，团队致力于以最小可行产品（MVP）的形式交付初始软件版本，以便客户尽早享受一些功能，而不必等待完整的产品。
2、欢迎变化，即使在项目的后期也同样欢迎。敏捷过程利用变化，以帮助客户获得竞争优势。
示例：项目团队允许客户在项目过程中提出变更请求，而不是坚持原始计划。这使得软件能够适应市场变化和客户需求。
3、经常交付可工作的软件，频率越高越好，通常在几周或几个月内。
示例：在敏捷开发中，软件交付是周期性的，例如每两周一次。这有助于客户及早检查和反馈，以确保产品与其期望保持一致。
4、业务人员和开发人员必须在整个项目过程中紧密合作。
示例：业务代表参与在每个迭代期间的需求定义和优先级确定，以确保开发人员了解客户需求。
5、构建项目团队，围绕那些能够完成工作的个体，提供他们所需的支持和信任。
示例：团队成员在项目中具有多样的技能，相互信任，鼓励开放的交流，以实现项目目标。
6、面对面的沟通通常是最有效的。
示例：团队成员通常举行每日站会，面对面讨论进展、问题和计划，以促进高效沟通。
7、可工作的软件是进度的首要度量标准。
示例：项目的进度与软件的可工作版本交付进度相关，而不仅仅关注文档和计划。
8、可持续的开发，支持不断的开发进程。
示例：团队通过定期迭代来保持软件的持续发展，不断添加新功能、修复问题和提高质量。
9、良好的设计和技术卓越，增强敏捷性。
示例：团队注重软件的整体架构和设计，以确保可扩展性、可维护性和性能。
10、简单性，即最大限度地减少不必要的工作，是必要的。
示例：团队遵循KISS（保持简单愚蠢）原则，避免过度复杂的解决方案，专注于解决问题的最简单方法。
"KISS" 是 "Keep It Simple, Stupid" 的缩写，意思是要保持事物简单。这个原则是敏捷开发中的一项重要指导原则，它鼓励团队在设计、开发和管理过程中尽量保持简单，避免过度复杂化。
KISS原则的核心思想是，简单的解决方案通常更容易理解、实施和维护，同时也减少了出错的机会。以下是KISS原则的一些具体含义和示例：
10.1解决方案的简洁性：在面对问题或挑战时，团队应该寻求最简单的解决方案，而不是过度复杂的解决方案。例如，在设计软件功能时，不要添加不必要的复杂性，而是选择最直接的方法来满足用户需求。
10.2避免不必要的特性：不要为项目添加过多的特性，特别是那些用户并不真正需要的特性。这会使项目变得复杂，增加了开发和维护的成本。在敏捷开发中，团队应专注于构建核心功能，以便更早地交付有价值的产品。
10.3简化流程：不仅适用于软件开发，KISS原则也适用于项目管理和流程设计。例如，尽量简化项目管理流程，减少冗长的文件和报告，以提高团队的效率。
10.4易于维护：简化的解决方案通常更容易维护。复杂性可能导致难以识别和解决问题。通过遵循KISS原则，团队可以减少维护成本并更快速地应对变化。
11、自组织的团队能够产生最好的架构、需求和设计。
示例：在敏捷项目中，团队成员具有决策权，可以自主组织工作，制定最佳的解决方案。
12、团队在定期回顾中反思并调整，以提高效率和效果。
示例：团队定期进行迭代回顾，评估过去的工作，识别问题并制定改进计划，以不断提高工作流程。
Scrum
符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。
Scrum框架可以概括为3(角色) 3(工件) 5(活动) 5(价值观):
角色【3】：
- 产品负责人（Product Owner）：负责定义产品愿景、管理Product Backlog。
- Scrum Master：确保团队遵守Scrum原则和实践，解决阻碍进展的问题。
- 开发团队：负责实际开发工作，通常是跨职能团队。
开发团队的规模？
Scrum 提倡小团队就保持敏捷，大团队则去完成重要工作，推荐 5 ~ 9 人的团队规模，但不用纠结这个数。关键是团队要有完成产品增量（PI）的所有技能，且能高效协作。团队有 11 人能高效协作就不用减人，有 4 人能完成产品增量（PI）也不用加人。
工件【3】：
- Product Backlog：产品待办事项列表（需求的清单，持续更新）。
- Sprint Backlog：冲刺待办事项列表（目标所需的具体任务）。
- Product Increment (PI)：产品增量（Sprint结束时的可交付的成果/产品）。
活动【5】：
- Sprint：时间固定的开发周期，通常2-4周。
- 日常站会（Daily Scrum）：每天短会议，讨论进展、计划和障碍。
- Sprint计划会议：确定Sprint目标和待办事项。
- Sprint复盘会议：展示和评估Sprint成果。
- Sprint回顾会议：回顾过程，讨论改进方法。
Scrum就是迭代开发？
这样理解是有偏差的。敏捷是个大概念，迭代开发只是很多敏捷开发用的主要基础实践之一。敏捷开发除了迭代开发，还包括很多其他管理和工程技术实践，像演进式架构设计、敏捷建模、重构、自动回归测试等等。
迭代周期如何选择？
选择迭代长度时考虑的因素：
1）不确定性的多少。不确定越多，迭代就应该越短；
2）获得反馈的难易程度。获得反馈越难，迭代就应该越短；
3）优先级可以保持多久不变。优先级变化越快，迭代就应该越短；
4）紧迫感的维持。越保持急迫感，迭代就应该越短。
不管迭代周期选多长，最好定好一个长度就一直用，别变来变去。比迭代周期更重要的是，团队遇到问题后怎么应对和改进，要真正把改进任务加到每个迭代里去做。
价值观【5】：
勇气Courage：有勇气去面对各种挑战。
专注Focus：每个迭代只专注于该迭代要完成的事情。
承诺Commitment：作为一个团队，在迭代开始时做出承诺，并在迭代中全力完成。
尊重Respect：团队是能随时沟通的，并且能相互理解的。
公开Openness：团队所有的进展、问题、阻碍都是对所有人可视化、透明的。
)
