敏捷宣言用四条价值取向说明团队在冲突时如何取舍：个体与互动高于流程与工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。这四条并不否定流程、文档、合同和计划，它们共同构成敏捷方法的价值观基础，具体角色与事件由 Scrum、看板等框架展开。
要点总览（TL;DR）
- 敏捷宣言用四条价值取向表达冲突时的取舍：个体与互动高于流程与工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。
- 四条取向并未否定流程、文档、合同和计划，右侧各项仍有价值，只是在与左侧冲突时排序靠后。
- 四条取向互相支撑：个体互动决定信息流动，可工作的软件提供进展依据，客户合作与响应变化形成反馈闭环。
- 敏捷宣言处于价值观层，Scrum、看板等处于框架层，同一组价值取向可以由不同框架承载。
- 判断团队是否体现宣言精神，看冲突时刻的实际选择，而非是否张贴宣言或是否保留文档。
敏捷宣言的四条价值取向分别是什么
敏捷宣言发布于 2001 年，由十七位软件开发实践者共同讨论形成。它用四组对照句表达价值排序，每组都写成“左侧高于右侧”的形式。理解这四条，关键是看清每组两侧分别指什么，以及“高于”表达的是冲突时的优先顺序。
| 价值取向 | 左侧指什么 | 右侧指什么 | 取舍含义 |
|---|---|---|---|
| 个体与互动高于流程与工具 | 团队成员之间的直接沟通、协作意愿、彼此信任与当面讨论 | 既定的工作流程、审批环节、协作平台与自动化工具 | 当流程或工具阻碍人解决问题时，先调整流程和工具，让人能顺畅协作 |
| 可工作的软件高于详尽的文档 | 能够运行、可以演示、能交付用户使用的软件成果 | 需求规格、设计说明、接口文档等书面材料 | 当文档编写与交付可用成果争夺同一段时间时，优先保证成果可运行 |
| 客户合作高于合同谈判 | 与客户持续沟通、共同澄清目标、一起调整方案 | 以合同条款界定范围、责任与验收条件 | 当合同条款与客户真实需要出现偏差时，先通过合作澄清需要，再处理条款 |
| 响应变化高于遵循计划 | 根据新信息、新反馈调整方向与优先级 | 按既定计划推进、维持原定范围与时间表 | 当计划与实际情况冲突时，优先让计划服务于目标，而非让目标迁就计划 |
四条合起来表达的是一种排序逻辑：右侧各项在项目里都有位置，左侧各项在两者发生冲突时获得优先。宣言原文在四条之后补充了一句说明，右侧各项也有价值，这一句是理解整份宣言的前提，也是后文讨论边界的依据。
四条价值取向的边界：它肯定什么、不否定什么
敏捷宣言是一份价值观陈述，它回答“遇到取舍时偏向哪一边”，不回答“团队应该设哪些角色、开哪些会、迭代多长”。把宣言当成流程规范，是常见误读的来源。
右侧各项仍然有价值。流程与工具能降低协作成本、让新成员快速上手；文档能保存决策依据、支撑交接与合规；合同能明确双方责任、控制商业风险；计划能协调资源、给干系人稳定预期。宣言说的是冲突时的优先级，并没有把这些实践排除在项目之外。一个团队保留详细的设计文档和完整的合同条款，同时按宣言的取向做取舍，这并不矛盾。
宣言也不规定具体做法。迭代周期是两周还是四周、角色叫产品负责人还是业务代表、用故事点还是工时估算、开哪些评审会，这些属于框架和实践层面的选择，宣言本身没有给出答案。不同团队可以在同一组价值取向下采用差别很大的工作方式。
因此，判断一个团队是否体现宣言精神，看的是冲突时刻的实际选择：流程卡住沟通时是否愿意改流程，文档挤压交付时是否敢于先交付可用成果，合同条款与客户需要不符时是否先沟通再处理，计划失效时是否及时调整。这些选择比是否张贴宣言更能说明问题。
四条价值取向如何共同支撑敏捷运作
四条价值取向并非彼此独立的格言，它们在日常决策中互相支撑，形成一条从沟通到交付再到反馈的链条。
个体与互动决定了信息如何流动。团队遇到问题时，先找相关的人当面说清，而不是先在系统里提交流程单等待流转。这一取向让决策速度取决于沟通质量，而非流程层级。它带来的直接结果是：问题在变复杂之前就被讨论，误解在变成返工之前就被澄清。
可工作的软件提供了进展的判断依据。当团队用“能不能演示、能不能用”来衡量进度，讨论就会回到具体成果上，而不是停留在完成百分比或文档页数。这一取向让个体互动的产出有可检验的落点：沟通是否有效，看交付物是否更接近可用状态。
客户合作与响应变化共同构成反馈闭环。客户合作让反馈有稳定来源，响应变化让反馈能够进入计划调整。两者结合，团队不必在项目初期把所有需求定死，而是按阶段获取真实反馈并调整优先级。合同与计划在这个闭环中承担约束和协调作用，当它们与反馈冲突时，团队先处理反馈所指向的真实需要。
在冲突场景中，四条取向提供了一套排序参照。例如，一项审批流程要求文档齐全才能进入开发，而客户希望尽快看到可演示的版本，此时“可工作的软件高于详尽的文档”和“响应变化高于遵循计划”共同支持团队先交付最小可用成果，同时保留必要的记录。排序不是固定公式，但它让讨论有共同语言，减少每次冲突都从头争论。
敏捷宣言与 Scrum、看板等框架的关系区别
敏捷宣言处于价值观层，Scrum、看板等处于框架层。前者说明为什么这样取舍，后者说明具体怎么组织工作。两者是层次关系，并非替代关系。
| 层次 | 内容 | 回答的问题 | 典型例子 |
|---|---|---|---|
| 价值观层 | 四条价值取向及背后的十二条原则 | 冲突时优先什么 | 敏捷宣言 |
| 框架层 | 角色、事件、工件、规则与节奏 | 用什么结构组织工作 | Scrum 的三种角色、五个事件、三类工件；看板的可视化列与在制品限制 |
| 实践层 | 团队具体的做法与工具配置 | 每天怎么执行 | 站会时长、估算方式、缺陷处理规则 |
Scrum 在宣言基础上补充了产品负责人、 Scrum Master、开发团队等角色，以及 Sprint、每日站会、评审、回顾等事件和产品待办列表、Sprint 待办列表、增量等工件。看板则强调把工作可视化、限制在制品数量、管理流动。两者承载同一组价值取向的方式不同：Scrum 通过固定节奏创造反馈机会，看板通过流动管理暴露瓶颈。团队选择哪个框架，取决于工作性质与约束条件，宣言本身不指定答案。
当价值取向要落到团队协作中，承载方式通常是工作项与文档的状态管理。以 ONES 为例，其敏捷研发管理解决方案打通需求、研发、测试流程，把需求提出方、产品经理、研发、测试等角色连接起来，并为需求管理、迭代规划、进度跟踪、迭代复盘等 Scrum 关键环节提供工具支撑；同时支持自定义与组件化配置，团队可以按自身工作习惯组合流程。这类工具承担的是把价值取向转化为可执行协作动作的角色，它本身不替代团队对价值取向的理解和判断。
具体例子：一次需求变更中四条价值取向如何体现
以下为演示情景，用于说明四条价值取向在决策中的表现，不指向特定企业或项目。
某团队正在开发一个订单管理功能，迭代进行到第二周，客户提出希望增加批量导出。原计划中该功能排在两个迭代之后，合同约定的范围也不包含它。团队面临几个选择：按原计划继续，把变更排到后面；暂停当前工作立即插入；或者先与客户确认使用场景再决定。
按宣言的取向，团队会先与客户沟通，弄清批量导出的实际用途、使用频率和紧急程度。这是“客户合作高于合同谈判”的体现：先理解需要，再讨论范围与合同如何处理。沟通后发现客户下周有一次对账，需要导出数据核对，团队于是决定先提供一个简化版本，满足对账场景，完整功能仍按原计划推进。这是“响应变化高于遵循计划”与“可工作的软件高于详尽的文档”的共同作用：调整计划以交付可用成果，而不是先补一份完整的变更文档再排期。
在这个过程中，文档与流程仍有合理位置。团队把变更原因、简化版本的范围、后续完整功能的排期记录在需求条目和迭代说明中，供测试和后续交接使用；变更也走了必要的确认环节，让合同范围的变化有据可查。区别在于，这些记录服务于交付和协作，没有成为启动工作的前置门槛。
常见的误解是把宣言读成“不要文档、不要计划”。从上面的情景看，团队既写了记录，也保留了计划，只是在冲突时让文档和计划服务于客户需要与可用成果。另一种误解是把宣言当成可以随意变更的借口：响应变化的前提是变化有真实来源、经过判断、留下记录，而非任何临时想法都立即插入。四条价值取向支持的是有依据的调整，团队仍需对每次调整的影响做出评估。
常见问题
敏捷宣言是否意味着团队可以不做文档、不做计划？
不是。宣言的表述是“可工作的软件高于详尽的文档”“响应变化高于遵循计划”，表达的是冲突时的优先顺序，右侧各项仍然有价值。文档能保存决策依据、支撑交接与合规，计划能协调资源、给干系人稳定预期。团队可以保留设计文档和完整计划，同时在文档挤压交付、计划与实际情况冲突时，优先保证可用成果和及时调整。
四条价值取向之间是什么关系，遇到冲突时怎么用？
四条取向互相支撑，形成从沟通到交付再到反馈的链条：个体与互动决定信息如何流动，可工作的软件提供进展的判断依据，客户合作与响应变化构成反馈闭环。遇到冲突时，四条提供一套排序参照，例如审批流程要求文档齐全才能开发，而客户希望尽快看到可演示版本，此时“可工作的软件高于详尽的文档”和“响应变化高于遵循计划”共同支持先交付最小可用成果。排序不是固定公式，但让讨论有共同语言。
敏捷宣言和 Scrum、看板是什么关系，学了宣言还需要选框架吗？
两者是层次关系。敏捷宣言处于价值观层，回答冲突时优先什么；Scrum、看板处于框架层，回答用什么结构组织工作。Scrum 补充了角色、事件和工件，通过固定节奏创造反馈机会；看板强调工作可视化、限制在制品数量、管理流动。宣言本身不指定具体做法，团队仍需根据工作性质与约束条件选择框架，并在框架中落实价值取向。
团队把变更随时插入迭代，算不算践行“响应变化高于遵循计划”？
不算。响应变化的前提是变化有真实来源、经过判断、留下记录。宣言支持的是有依据的调整，团队仍需评估每次调整对范围、进度和质量的影响。任何临时想法都立即插入，会让计划失去协调作用，也让团队难以对交付做出稳定承诺。合理的做法是先与提出方沟通使用场景和紧急程度，再决定是否调整以及如何记录。
用协作工具管理需求和迭代，会不会与“个体与互动高于流程与工具”相矛盾？
不矛盾。工具承担的是把价值取向转化为可执行协作动作的角色，例如记录需求状态、同步迭代进展、留存变更依据，让团队成员把精力放在沟通和解决问题上。关键在于当流程或工具阻碍人解决问题时，团队愿意调整配置甚至改变做法，让人能顺畅协作。工具本身不替代团队对价值取向的理解和判断。
