说明：由于知识点梳理时间紧张，内容中不免有错别字出现，如影响阅读，请私信本人，六月_Z
定义
- 在合作环境下由自我管理的团队进行产品迭代开发的过程
- 通过渐进式的迭代工作步骤，团队可以应对未预期的事项，也被称为冲刺（Sprints）
- 敏捷开发在软件行业的应用极为普遍
敏捷宣言
| 更重要、价值更大 | > | 有价值 |
|---|---|---|
| 个体和交互 | > | 过程和工具 |
| 可运行软件 | > | 面面俱到的文档 |
| 客户合作 | > | 同谈判 |
| 响应变化 | > | 遵循计划 |
12条原则
- （满足客户)）我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
- （拥抱变化）即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
- （持续交付）经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
- （跨职能）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
- （充分信任）招揽积极主动的人员来开发项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
- （面对面）在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
- （可用的软件）工作的软件是首要进度度量标准。
- （可持续开发）敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
- （不断完善）不断地关注优秀的技能和好的设计，会增强敏捷能力。
- （简洁）简洁—令待办工作最少化的艺术是一切的基础；
- （自组织）只有自我管理的团队才能做出最好的架构和设计。
- （回顾总结）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
优势
- 对于业务要求很难被文化或难以成功的产品开发项目而言，敏捷流程带来了新的可行机会。
- 凭借敏捷方法，快速变化中的前沿开发得以呗迅速编码和测试。一旦出现错误，也可以很容易地纠正。
- 通过定期会议京城性地更新工作进展。敏捷是一种轻量级的管控方法，因此项目开发有明显的可视性。
- 像任何其他敏捷方法一样，其本质是迭代，需要来自用户的连续反馈。
- 由于冲刺周期短，反馈及时，团队更容易应对变化。
- 通过日常会议可以评估个体的生产力，从而提高团队成员的生产力。
- 通过日常会议可以提前识别问题，随后迅速解决问题。
- 敏捷方法与任何技术或变成语言兼容，特别是快速发展的网络2.0项目或新媒体项目。
- 在流程和管理方面的运营成本最小，因此项目进展更快、花费更少。
局限性
- 敏捷是出现“范围蔓延”问题的主要原因。这是因为，除非有一个明确的截止日期，否则项目管理相关者会不断要求团队交付新功能。
- 如果任务的定义不明确，对项目成本和时间的预估是不准确的。在这种情况下可以将任务分散为多次冲刺。
- 如果团队成员没有全力以赴，项目将永远不会完成或失败。
- 因为敏捷方法可以由小型团队完成，它适用于快速变化的小型项目
- 敏捷方法需要有经验的团队成员，如果团队中有新手，项目可能无法按时完成
- 若敏捷负责人信任手下的团队，敏捷方法与项目管理的配合效果良好。若敏捷负责人对团队成员实行过于严格的控制将会给团队带来极大的挫败感，导致团队缺乏动力，进而导致项目失败。
- 任何一个团队成员在开发过程中离开都会对项目开发产生巨大的负面效果
- 难以实施和量化项目管理，除非测试团队能够在每次冲刺后进行回归测试。
