敏捷宣言强调四组价值取向：个体与互动高于流程与工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。它表达的是取舍时的优先顺序，右侧各项仍有价值；这四句话属于价值判断，并非一套具体流程或方法清单。
要点总览（TL;DR）
- 敏捷宣言强调四组价值取向：个体与互动高于流程与工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。
- “高于”表达的是取舍时的优先顺序，右侧各项仍有价值；宣言做价值排序，不宣布取消文档、计划或合同。
- 宣言面向软件开发背景提出，不规定角色、事件和工件；Scrum、Kanban等框架在宣言与十二条原则之下承载具体实践。
- 四条取向相互支撑：顺畅互动支撑客户合作，可运行成果提供反馈依据，对变化的开放态度让合作持续。
- 常见误读是把“高于”当成“取代”或把宣言当成流程规范，结果在交接、追溯和“敏捷该怎么做”的争论中付出额外成本。
敏捷宣言的四条价值取向分别指什么
敏捷宣言发布于2001年，由十七位软件开发从业者共同起草。全文很短，核心就是四句以“高于”连接的价值表述。理解这四句话，关键在于看清每组中左右两项各自指什么，以及“高于”在什么情境下起作用。
| 价值取向 | 左侧（更看重） | 右侧（仍有价值） | 取舍含义 |
|---|---|---|---|
| 个体与互动高于流程与工具 | 团队成员之间的直接沟通、协作意愿、彼此信任 | 既定流程、管理工具、规范文档 | 流程和工具服务于人；当流程阻碍沟通时，优先调整流程 |
| 可工作的软件高于详尽的文档 | 能运行、能交付、能验证的产品增量 | 需求文档、设计文档、说明材料 | 文档用于支撑开发与交接；进展以可运行成果为准 |
| 客户合作高于合同谈判 | 与客户持续沟通、共同澄清需求、一起调整方向 | 合同条款、范围约定、验收标准 | 合同界定合作基础；日常推进依靠持续协作 |
| 响应变化高于遵循计划 | 根据新信息调整优先级和方案 | 计划、排期、里程碑 | 计划提供参照；变化出现时按价值重新安排 |
逐条来看，第一条把团队协作放在流程工具之前。流程和工具能降低协调成本，但遇到流程没覆盖的情况，靠的是成员之间的直接沟通。第二条把可运行的产品作为进展的最终证据。文档帮助理解需求、记录决策，但一份写得很完整的文档无法证明功能可用。第三条强调客户在开发过程中持续参与。合同明确双方责任，而需求的真实含义往往要在反复沟通中才逐渐清晰。第四条承认计划的价值，同时允许团队根据市场、技术或用户反馈调整方向。
四句话共同的结构是“左侧高于右侧”，而非“左侧取代右侧”。宣言原文在列出四条之后专门补充：右侧各项仍有价值。这句话决定了整份宣言的语气——它做的是价值排序，在两者冲突时给出倾向，不宣布右侧项目应当取消。价值取向与具体做法的区别也在这里：宣言不告诉你多久开一次会、用什么工具管理需求，它只说明当流程与沟通、文档与成果、合同与合作、计划与变化发生张力时，应当往哪边倾斜。
敏捷宣言的适用范围与边界
敏捷宣言面向软件开发背景提出，起草者的经验来自各类软件开发项目。它讨论的是软件开发中人与协作的基本取向，这一背景决定了它的适用语境，也决定了它不承担的功能。
宣言本身不规定角色、事件和工件。它没有说要有产品负责人、 Scrum Master，没有规定迭代长度，也没有要求写用户故事或维护燃尽图。这些内容属于具体框架和实践的范畴。把宣言当作流程规范来读，会不断遇到“宣言里没写怎么做”的困惑，原因在于它本来就不回答这个问题。
宣言与Scrum、Kanban等框架是不同层次的东西。宣言和十二条原则提供价值基础和判断依据；Scrum、Kanban、极限编程等框架则在这个基础上给出角色分工、活动节奏和工件形式。一个团队可以遵循宣言的价值取向，同时选择Scrum作为落地方式；也可以采用Kanban的流动管理方式。框架可以替换，价值取向相对稳定。
还有一些内容明确落在宣言边界之外，属于迭代管理与需求池管理的操作范围，例如Sprint如何规划、评审会怎么开、回顾会产出什么、Product Backlog如何拆分和排序。这些是团队在选定框架后需要自行设计或参照实践指南解决的问题。本文只说明它们不属于宣言的内容，不展开具体操作方法。
四条价值取向如何在实际工作中体现
价值取向要发挥作用，需要转化为日常协作中的具体判断。四条取向相互支撑，单独看一条容易走偏，放在一起才能形成完整的运作机制。
个体与互动体现在信息如何流动。团队遇到需求歧义时，优先找相关成员当面或即时沟通澄清，而不是先补一份流程文档再走审批；跨角色协作出现卡点时，先看沟通渠道是否顺畅，再考虑增加管控环节。这种取向要求团队保留直接对话的空间，也让流程设计以降低沟通成本为目标。
可工作的软件作为进展判断依据，改变的是汇报方式。与其用“完成了80%”描述进度，不如展示一个能运行、能演示的增量。这一取向推动团队把工作拆到可以独立验证的粒度，也让评审有实物可看。文档在这个机制中承担记录决策、支撑交接的角色，写多少取决于它能否帮助后续工作，而非追求覆盖所有细节。
客户合作与响应变化共同影响计划方式。客户持续参与，需求才能在早期被澄清；变化被及时接收，计划才有调整的依据。实践中常见的做法是把计划做成可更新的：近期安排相对具体，远期保留调整空间；当新信息出现时，评估其对当前工作的影响，再决定是否调整优先级。计划仍然要写，它的作用是提供参照和协调基础，而非锁定未来。
四条取向的相互支撑关系值得注意。没有个体之间的顺畅互动，客户合作难以持续；没有可工作的软件作为反馈载体，响应变化就缺少判断依据；没有对变化的开放态度，客户合作容易退化为一次性需求确认。团队在协作中落实这些取向时，通常需要把需求、迭代和进度放在同一处管理，让沟通有共同的对象。ONES 敏捷研发管理方案覆盖需求池管理、迭代规划、迭代开发、缺陷追踪与迭代进度跟进等场景，ONES Project 提供需求池、迭代规划、敏捷看板、燃尽图和自定义工作流等能力，可以作为承载这些协作动作的工具环境；价值取向本身仍由团队在具体取舍中体现。
敏捷宣言与敏捷原则、敏捷框架的区别
敏捷宣言、十二条原则与Scrum、Kanban等框架经常被混为一谈，实际它们处在不同层次，回答的问题也不同。
| 层次 | 典型内容 | 回答的问题 |
|---|---|---|
| 价值观（宣言） | 四条价值取向 | 发生取舍时，我们更看重什么 |
| 原则 | 十二条原则，如尽早持续交付有价值软件、欢迎需求变化、自组织团队等 | 依据这些价值，我们应当遵循哪些行为准则 |
| 框架 | Scrum的角色、事件、工件；Kanban的流动与在制品限制 | 用什么样的结构和节奏把这些准则落成日常实践 |
宣言与十二条原则同属敏捷宣言的原始文本，二者一起发布。宣言给出价值排序，原则把价值展开为更具体的行为指引，例如“业务人员和开发人员必须每天一起工作”“以简洁为本”等。原则比宣言更接近操作，但仍属于指导性表述，不规定会议形式或工具配置。
Scrum、Kanban等框架位于原则之下，提供可执行的结构。Scrum规定Sprint、每日站会、评审、回顾等事件和相应角色；Kanban关注工作流动、可视化与在制品限制。框架之间存在差异，选择哪个取决于工作性质和团队情况，而它们都可以被视为对宣言价值取向的一种承载方式。
常见混淆点有三个。其一，把“敏捷”直接等同于Scrum，忽略了宣言和原则的层次。其二，把宣言中的价值取向当成实践清单，追问“宣言要求开什么会”。其三，把某个框架的具体规则当作敏捷的普遍标准，用框架合规性替代价值判断。区分这三个层次，有助于在选用框架时保持清醒：框架是手段，价值取向是判断依据。
理解敏捷宣言时的常见误解与例子
宣言的表述简短，容易被读成极端主张。澄清几个典型误读，能让四条价值取向更可操作。
最常见的误读是把“高于”理解为“取代”。有人据此认为敏捷团队不需要文档、不需要计划、不需要合同。宣言原文明确说明右侧各项仍有价值，四句话处理的是冲突时的优先级。没有文档，交接和追溯会变得困难；没有计划，协作缺少参照；没有合同，合作缺少基本约定。这些项目被保留，只是在与左侧冲突时让位。
第二个误读是把“可工作的软件高于详尽的文档”读成“不要写文档”。实际含义是文档的详略程度应服务于交付，而非以完备为目标。一份记录关键决策和接口约定的简短文档，往往比一份无人维护的详尽规格更有用。同理，“响应变化高于遵循计划”不意味着计划可以随意废弃，而是说计划需要具备根据新信息调整的机制。
可以用一个演示情景说明取舍如何发生。假设一个团队在迭代中期收到客户反馈，指出某项功能的使用方式与真实场景不符。团队手上有已排好的计划和一份需求说明文档。遵循价值取向的处理方式是：先与客户确认反馈的具体影响，评估调整所需工作量，再决定是否在本迭代内替换部分原定内容。这里计划没有被抛弃，而是被重新评估；文档没有被否定，而是根据新理解更新。若团队机械执行原计划，可能交付一个不符合场景的功能；若团队完全无视计划随意插入需求，则可能打乱节奏、影响其他承诺。价值取向提供的是判断方向，具体决定仍需结合工作量、依赖关系和客户优先级做出。
误读带来的后果通常不是立刻显现的。把“高于”当“取代”，团队可能在早期感觉轻快，随后在交接、审计或人员变动时付出额外成本；把宣言当流程规范，团队会陷入“敏捷到底该怎么做”的争论，却得不到答案。把四条取向理解为取舍时的优先顺序，并保留右侧项目的价值，才能让宣言真正成为判断工具，而非口号。
常见问题
敏捷宣言说“可工作的软件高于详尽的文档”，团队还需要写文档吗？
需要写，只是详略程度服务于交付。宣言原文在四条之后补充说明右侧各项仍有价值，文档承担记录决策、支撑交接和追溯的作用。判断标准可以落到具体问题上：这份文档是否帮助后续开发、测试或运维理解关键约定？如果一份简短记录已经覆盖接口约定和关键决策，就不必为追求完备而扩写成无人维护的长文档。
团队采用Kanban而不采用Scrum，还算遵循敏捷宣言吗？
可以。宣言和十二条原则提供价值基础，Scrum、Kanban等框架是在这个基础上承载实践的结构，框架可以替换。Kanban关注工作流动、可视化与在制品限制，同样可以在个体互动、持续交付和响应变化上体现宣言的取向。判断一个团队是否遵循宣言，看的是取舍时是否偏向左侧价值，而非采用哪个框架。
客户坚持按合同范围验收，团队还怎么体现“客户合作高于合同谈判”？
合同界定合作基础，日常推进依靠持续协作，两者可以并存。可行做法是在合同框架内建立固定的沟通节奏，例如定期向客户演示可运行增量、提前暴露需求歧义，把分歧放在影响交付之前讨论。当确实需要调整范围时，用已展示的成果和评估过的工作量作为协商依据，比在验收阶段才争论更有效。
响应变化和遵循计划冲突时，团队应该按什么顺序判断？
先确认变化的具体影响，再决定是否调整。可以依次评估：变化涉及的需求是否影响当前迭代目标，调整需要多少工作量，是否影响对其他承诺的交付。评估之后再结合客户优先级做取舍。计划在这里提供参照和协调基础，调整的依据是新信息带来的价值判断，而非变化本身。
敏捷宣言和十二条原则是什么关系，需要分开理解吗？
二者同属敏捷宣言的原始文本，一起发布，处在不同层次。宣言给出四条价值排序，回答取舍时更看重什么；十二条原则把价值展开为更具体的行为指引，例如尽早持续交付有价值软件、欢迎需求变化、业务人员与开发人员每天一起工作。原则比宣言更接近操作，仍属于指导性表述，不规定会议形式或工具配置。分开理解有助于在选用框架时保持判断依据。
