> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 敏捷方法论
> 敏捷方法论是一种迭代式的项目管理与软件开发方法，强调灵活性、协作和持续改进。
**类别**: 方法
**类型**: 项目管理框架
**起源**: 敏捷宣言，2001年 / 软件开发实践者
**别名**: 敏捷、敏捷开发、敏捷项目管理
**快速回答** — 敏捷方法论是一种迭代式的项目管理与软件开发方法，强调以小增量而非大型发布的方式交付价值。敏捷方法论创立于2001年的敏捷宣言，重视个人和互动胜于流程和工具，重视可工作的软件胜于详尽的文档，重视客户协作胜于合同谈判，重视响应变化胜于遵循计划。团队以称为冲刺的短周期工作，通常持续两周，以便快速获得反馈和适应变化。
## 什么是敏捷方法论？
敏捷方法论是一种灵活的迭代式项目管理与软件开发方法，帮助团队更快地交付价值，减少意外。与其在开始时计划整个项目并在一个长的瀑布式阶段执行不同，敏捷将工作分解成称为冲刺的小增量。每个冲刺产生一个潜在可发布的产品增量，可以进行测试、审查和在此基础上构建。
敏捷的核心哲学是拥抱不确定性和变化。传统的项目管理假设你可以在开始时准确预测需求、时间表和成本。敏捷承认需求会演变，最好的解决方案是通过实验和反馈产生的。通过频繁交付并收集真实用户反馈，团队可以在错误方向上投入过多之前及时调整。
> "敏捷宣言重视可工作的软件胜于详尽的文档，但这并不意味着不需要文档。" — 17位敏捷宣言签署者之一
敏捷不仅仅是一种方法论——它是一种思维方式的转变。它要求团队优先考虑客户价值、欢迎变化、赋能个人，并持续反思其流程。敏捷的成功较少依赖于遵循特定的仪式，更多依赖于体现其基本原则：频繁交付可工作的解决方案、欢迎不断变化的需求、与利益相关者每日协作、保持可持续的工作节奏。
### 敏捷方法论的三层理解
* **入门**: 参加冲刺规划会议，了解工作是如何被选择和承诺的。参与每日站会，观察团队如何跟踪进度。回顾你的第一次冲刺演示，观察反馈如何塑造未来的工作。
* **实践**: 主持冲刺回顾会议以识别流程改进。使用燃尽图来跟踪速度并预测产能。使用用户故事地图将功能分解为可管理的增量。
* **进阶**: 使用SAFe或LeSS等框架规模化实施Scrum。建立实践社区以在团队间分享知识。使用累积流图等精益指标来识别瓶颈并优化流程。
## 起源
敏捷方法论诞生于2001年2月，17名软件开发者和思想领袖聚集在犹他州的洛奇酒店。他们厌倦了重量级的软件开发流程，这些流程似乎更重视文档和仪式而非交付可工作的软件，于是聚在一起讨论在1990年代兴起的轻量级开发方法。
结果是敏捷宣言的诞生，这是四项核心价值和十二项原则的宣言，优先考虑个人和互动、可工作的软件、客户协作和响应变化。这些签署者代表了各种正在获得关注的轻量级方法论，包括Scrum（由肯·施瓦伯和杰夫·萨瑟兰开发）、极限编程（由肯特·贝克创建）和水晶方法（由阿利斯泰尔·科伯恩开创）。
敏捷宣言的发布恰逢基于网络的软件兴起和对更快发布周期的需求增长。随着谷歌、Facebook和Netflix等公司展示了迭代开发的力量，敏捷原则扩展到软件之外的营销、人力资源、制造业和其他领域。如今，敏捷是全球主导的软件开发方法论，Scrum是采用最广泛的框架。
## 核心要点
将工作分解成固定时间的迭代，通常为1-4周。每个冲刺产生一个可交付给客户的可工作增量。短周期能够实现更快的学习并降低变更成本。
进展的主要衡量标准是可工作的软件。最小化在制品，专注于完成功能而非启动许多事情。未完成的功能不会交付价值。
即使在开发后期，也欢迎将变更视为提供更好解决方案的机会。不要将变更视为干扰，而是将其视为改进最终产品的学习机会。
面对面交流仍然是最有效的沟通形式。每日站会、冲刺评审和回顾会创造定期的对齐和反馈接触点。
团队应该能够以恒定的节奏无限期地工作。通过根据历史速度建立现实的承诺，避免加班和倦怠。
## 应用场景
最初和最常见的应用。敏捷帮助软件团队更快地交付功能，响应用户反馈，并在开发过程中适应不断变化的需求。
产品经理使用敏捷根据客户价值和市场反馈来优先考虑路线图。功能根据实际使用数据持续评估和重新排序。
敏捷营销将迭代周期应用于活动开发。团队测试信息、衡量结果并快速调整策略，而不是规划冗长的季度活动。
初创企业使用敏捷以最小投资快速验证想法。构建-测量-学习循环本质上是敏捷的，允许在不需要大量沉没成本的情况下进行转型。
## 经典案例
2008年，Spotify面临一个关键挑战：公司增长迅速，但工程团队正努力以适度的速度交付功能。传统的开发流程造成了瓶颈，协调开销让每个人都变慢。领导团队决定采用敏捷原则，但根据他们的独特需求进行调整。
他们将工程师组织成小型自治小组，每组8-12人，各自负责一个特定的功能领域。他们没有遵循僵化的Scrum框架，而是采用了后来被称为Spotify模式的方式：跨职能团队可以独立发布，与其他团队的依赖关系最小。他们引入了"部落"来组织有共同使命的小组，以及"公会"让有共同技能的人分享知识。
结果非常显著。Spotify从每季度发布一个主要功能转变为每天部署数百次。工程速度大幅提升，同时保持了质量。更重要的是，团队保持了自主性和创造力——公司可以在不失去初创企业敏捷性的情况下规模化发展。Spotify模式已成为最具影响力的敏捷实施之一，被全球公司学习和采用。
## 边界与失效场景
敏捷有显著局限性，团队必须认识到。首先，敏捷需要有经验、自我驱动的团队成员——它在初级团队或需要严格流程合规的环境中效果不佳。其次，缺乏前期规划如果不谨慎管理会造成范围蔓延；没有明确的边界，项目可能会无限漂移。
另一个常见失败是将敏捷仅仅作为一套仪式而非接受其原则。团队可能举行每日站会但忽略其反馈，或者完成冲刺但不展示可工作的软件。此外，敏捷在需要大量文档和审计跟踪的高度监管行业中可能举步维艰。最后，将敏捷扩展到大型组织会引入原始框架未解决的协调挑战，需要SAFe或LeSS等额外框架。
## 常见误区
敏捷重视可工作的软件胜于详尽的文档，并非不需要文档。在较大组织中，为了协调和知识传递，一定程度的规划和文档是必要的。
敏捷用轻量级流程取代重量级流程。团队仍然需要冲刺规划和回顾等仪式，但应该调整这些仪式以服务于团队需求，而不是僵化地遵循。
敏捷将经理的角色从指令性转变为 facilitative。经理成为服务型领导者，他们消除障碍、指导团队并优化高性能环境。
## 相关概念
最流行的敏捷框架。使用Scrum的角色、事件和工件以结构化方式实施敏捷实践。
可视化工作流管理方法，补充敏捷。使用看板可视化在制品并限制瓶颈。
团队为即将到来的冲刺选择和承诺工作的固定时间活动。使用来对齐团队优先级并设定现实的期望。
简短的每日会议，团队成员分享进度、计划和障碍。使用来保持对齐并及早发现问题。
目标与关键结果与敏捷配合良好。使用OKR提供转化为冲刺目标的战略方向。
敏捷与精益有共同根源和互补原则。应用精益思维在敏捷流程中消除浪费和优化流程。
## 一句话总结
以小增量交付价值，欢迎变化的需求，并根据反馈持续调整——这些是敏捷方法论成功的关键。