敏捷开发
敏捷开发（Agile）是一种价值观伞，而非单一方法或框架。它源自 2001 年美国犹他州雪鸟（Snowbird）滑雪场的 17 位软件实践者会议，会议产出了《敏捷宣言》（Agile Manifesto）：4 条价值观 + 12 条原则。核心要义是「左边的项虽有价值，但我们更重视右边的项」——这是「左>右」而非「左弃右」，强调以人为本、拥抱变化、持续交付可用软件、跨职能协作。敏捷本身不规定具体流程；**Scrum、Kanban、XP（极限编程）、Lean（精益）**等都是这一价值观之下的具体实现路径。与瀑布（Waterfall）的线性「需求→设计→编码→测试→交付」不同，敏捷以短周期迭代、持续反馈、自适应计划应对需求不确定性。选型一句话：需求稳定、变更成本高→瀑布仍合理；需求不确定、需快速验证→敏捷。核心共识：敏捷是价值观不是流程，落地靠具体框架（Scrum/Kanban/XP），且必须贴合团队上下文，而非照搬教条。
注意：本叶以《敏捷宣言》原文（agilemanifesto.org）为准。市面上常见的「敏捷 = Scrum」「敏捷 = 站会 + 看板」是简化误解——敏捷是伞，Scrum 是伞下的一种实现。
评价
优点
- 拥抱变化：以短迭代 + 持续反馈，把「需求变更」从风险变为竞争力来源，特别适合不确定的创新型项目
- 以人为本：强调个体与互动、自组织团队、面对面沟通，尊重开发者的判断力，而非把人当资源
- 持续交付价值：每个迭代产出可用软件，客户尽早看到真实成果而非纸面文档，降低方向性返工
- 降低交付风险：瀑布要等项目末期才验收，敏捷在迭代中持续暴露问题，失败成本小
- 价值观统一生态：作为「伞」，让 Scrum/Kanban/XP/Lean 等异构方法共享同一套底层信念，便于跨团队协作
- 可测量、可改进：每个迭代有回顾（Retrospective），形成「计划→执行→检查→改进」的闭环
缺点
- 被滥用为「无文档/无计划」借口：宣言从未否定文档与计划，但实践中常被扭曲为「不用写文档、不用做设计」，埋下技术债
- 对团队成熟度要求高：自组织、跨职能、持续重构需要高自律与强工程能力，新人多 / 能力弱的团队硬上敏捷易翻车
- 缺乏架构视角易短期化：迭代式开发若无架构演进规划，容易堆叠「能用就行」的代码，长期维护成本上升
- 规模放大困难：单团队敏捷顺畅，但多团队、跨地域、强合规的大型项目上，敏捷需要 SAFe/LeSS 等扩展框架，复杂度激增
- 合同与采购模式不匹配：传统固定范围、固定价格合同与敏捷「范围可变、预算/时间固定」的理念冲突，B2B 场景落地难
- 「敏捷仪式」官僚化：站会变汇报、回顾会变甩锅、估算变承诺，敏捷的「仪式」一旦僵化反而拖慢团队
文档地址
- Agile Manifesto（敏捷宣言原文，4 价值观）
- 12 Principles behind the Agile Manifesto
- Agile Manifesto History（雪鸟会议历史）