起源
2001 年，17 位软件从业者在美国犹他州聚会，发表了《敏捷软件开发宣言》。
四组价值主张（左侧被倡导，右侧也被认可但优先级较低）：
- 个体和互动 高于 流程和工具；
- 可工作的软件 高于 详尽的文档；
- 客户合作 高于 合同谈判；
- 响应变化 高于 遵循计划。
注意："高于"不是"取代"——右侧的价值依然存在，但当两者冲突时，优先左侧。
常见的误解
误解一："敏捷 = 没有文档"
宣言说的是"可工作的软件高于详尽的文档"，不是"不写文档"。
敏捷反对的是：为了流程而写的、写完就没人看的、冗长的文档。
好的敏捷团队依然需要：
- 架构决策记录（ADR）；
- API 文档；
- 必要的用户文档。
只是更强调简洁够用和保持更新。
误解二："敏捷 = 不需要计划"
宣言说"响应变化高于遵循计划"，不是"不做计划"。
敏捷的做法是：
- 做短期、滚动的计划（如每两周一个迭代）；
- 保持计划的可调整性；
- 但仍然有产品愿景和路线图作为长期方向。
误解三："敏捷 = 快"
敏捷的目标不是"更快交付"，而是"更快获得反馈并调整方向"。
在需求不确定的环境中，敏捷能减少"做错东西"的浪费——这才是它真正的价值。
如果需求已经非常明确、稳定，敏捷带来的收益会减少，传统的计划式开发未必更差。
误解四："敏捷就是 Scrum / 站会 / 看板"
Scrum、Kanban、XP 是具体框架，敏捷是价值观和原则。
很多团队"做了 Scrum 的所有仪式"（站会、评审、回顾、计划会），却没有任何敏捷的实质：
- 站会变成了"汇报给领导"；
- 迭代成了"每两周交付一批任务"，但从不根据反馈调整方向；
- 回顾会从未产生任何实际的改进。
这被称为"僵尸 Scrum"（Zombie Scrum）或"货物崇拜敏捷"（Cargo Cult Agile）——模仿形式，不解其意。
误解五："敏捷不需要管理者"
敏捷强调自组织团队，但不等于没有管理。
管理者的角色从"分配任务和监督"转变为：
- 移除障碍；
- 提供资源和上下文；
- 保护团队免受外部干扰；
- 培养人才。
十二条原则（节选）
宣言背后有十二条原则，其中几条特别值得注意：
- "尽早并持续交付有价值的软件" —— 强调频繁交付；
- "欢迎需求变化，即使在开发后期" —— 敏捷视变化为竞争优势；
- "业务人员和开发人员必须每天一起工作" —— 强调协作；
- "可工作的软件是进度的首要度量标准" —— 而非完成的任务数或文档页数；
- "简洁——最大化未做工作量的艺术——是至关重要的" —— 这与 YAGNI 一脉相承；
- "团队定期反思如何更有效，并相应调整行为" —— 这是回顾会的依据。
什么时候敏捷不适用
诚实地说，敏捷不是万能的。
以下情况，敏捷的收益可能有限：
- 需求极其明确且稳定（如某些合规性改造、标准化部署）；
- 高度安全关键的系统（如航空、医疗）——需要大量前置验证和文档（虽然也有"敏捷 + 严格验证"的实践）；
- 合同约束严格的外部项目（固定范围、固定价格的合同，与敏捷的"拥抱变化"存在张力）；
- 团队成员分散且协作成本过高。
一个务实态度
从原则出发，而非从仪式出发。
问自己：
- 我们是否更快获得了反馈？
- 我们是否能应对变化？
- 团队的协作是否更顺畅？
如果答案是否定的，那么即便你每天开站会、用着看板，也未必是"敏捷"。
说明：本文为软件方法论的知识整理。