敏捷宣言只有四句话，落到研发团队的日常协作里，需要变成每天能看见、能执行、能检查的行为。可行的做法是：先把四条价值观各拆成2—3条团队行为约定，再把这些约定嵌入需求澄清、每日同步、交付评审和回顾四个日常动作，明确每项动作的输入、负责人和产出，最后用检查项确认行为是否真的发生。本文给出一套从约定到检查的落地路径，适合研发团队负责人或敏捷实践推动者参考。
要点总览（TL;DR）
- 四条价值观要逐条翻译成可观察的协作行为：澄清会形成双方确认的验收条件、评审演示运行中的功能、需求方参与澄清与评审、计划调整有影响评估和团队确认。
- 落地按三步推进：团队共创一页行为约定，把约定嵌入需求澄清、每日同步、交付评审和回顾四个动作，再设置最少的记录点让行为可回溯。
- 分工原则是每个交付物只有一个主要责任人，日常动作的主持责任分散到不同角色，负责人只做节奏维护，避免包办或空转。
- 检查分机制层和行为层：机制层看四个动作是否有说明、有负责人、有记录位置；行为层抽查记录是否完整、结论是否被后续工作引用。
- 机制层通过而行为层不通过，说明约定停留在纸面，应回到第一步重新讨论约定是否具体、是否被团队认可。
四条价值观对应的日常协作行为
价值观本身不提供操作指令，团队需要把它翻译成“在什么场合、做什么动作、留下什么痕迹”。翻译的标准是行为可观察：换一个不在场的同事，也能通过产出判断这件事有没有发生。下表给出四条价值观与日常协作行为的对应关系，以及常见反例。
| 价值观 | 对应的日常协作行为 | 可观察的行为标志 | 常见反例 |
|---|---|---|---|
| 个体与互动高于流程与工具 | 需求澄清以面对面讨论为主，文档记录结论；遇到阻塞先找人对话，再走流程 | 澄清会形成双方确认的验收条件；阻塞问题在当日同步中被提出并有人认领 | 需求只靠工单流转，开发与产品长期不见面；问题卡在流程节点无人推动 |
| 可运行的软件高于详尽的文档 | 每个短周期结束时有可演示、可运行的成果；文档服务于交付，随交付更新 | 评审会上演示的是运行中的功能，而非进度幻灯片；验收条件对应到具体功能 | 以文档完成度作为阶段完成标准；演示时用截图和口头描述代替实际操作 |
| 客户合作高于合同谈判 | 需求提出方参与澄清和评审，优先级由业务价值驱动并共同确认 | 需求提出方出席评审并给出反馈；优先级调整有明确记录和理由 | 需求方只在立项和验收两端出现；优先级由单方下达，团队不了解背景 |
| 响应变化高于遵循计划 | 计划按优先级滚动调整，变更进入需求池统一评估，而非冻结或随意插入 | 每次调整有影响评估和团队确认；被替换的工作有明确去向 | 变更靠口头插入，打乱当前周期；或者一律拒绝变更，等到下个版本再说 |
四条价值观在实践中互相支撑。“个体与互动”让澄清和同步中的对话真实发生，“客户合作”保证对话的另一方在场；“可运行成果”为评审提供可验证的对象，“响应变化”则让评审中发现的调整有渠道进入下一轮计划。团队如果只挑其中一条执行，往往会在另一条上失效，例如强调响应变化却没有稳定的可运行成果，变更就会变成无序插入。
落地步骤：从行为约定到日常动作
落地分三步推进，每一步都有明确的输入、动作、负责人和完成标志。三步的顺序不宜颠倒：先有团队自己认可的行为约定，再谈嵌入日常动作，最后才设置记录方式。
第一步：团队共创行为约定
输入是敏捷宣言原文和团队近一个月的协作问题清单。动作是由团队负责人主持一次工作坊，逐条讨论四条价值观在本团队意味着什么，每条价值观收敛出2—3条具体行为约定，写成“在什么场合，我们做什么”的句式，并同时写明对应的反例。产出是一页行为约定清单，张贴在团队可见的位置。完成标志是每位成员都能说出至少两条约定，且清单由团队共同确认而非负责人单方面发布。
第二步：把约定嵌入四个日常动作
输入是行为约定清单和现有协作流程。动作是逐项检查需求澄清、每日同步、交付评审、回顾四个动作，为每个动作补上缺失的环节。需求澄清要明确参与人、验收条件和结论记录方式；每日同步要围绕看板对齐进度与阻塞，控制在十五分钟内；交付评审要安排可运行成果的演示和需求方反馈；回顾要基于数据讨论改进项并指定负责人。产出是四个动作各自的简易说明，写清输入、负责人和产出。完成标志是下一个周期内四个动作都按说明执行过一次。
第三步：设置轻量记录与反馈
输入是四个动作的执行情况。动作是选择最少的记录点：澄清结论记在需求条目上，同步中的阻塞记在看板或任务状态里，评审反馈记在评审记录中，回顾改进项单独跟踪。记录的目的是让行为可回溯，而非增加填报负担。产出是一份记录约定，说明每类信息记在哪里、由谁更新。完成标志是团队成员能在需要时找到上一次澄清结论或评审反馈，且记录耗时没有明显影响协作节奏。
角色分工与各环节交付物
落地需要有人推动，也需要每个角色在自己的环节承担明确责任。分工的原则是：每个交付物只有一个主要责任人，其他角色提供输入或确认；同一件事不设两个负责人，避免出现都在管或都不管的情况。
| 角色 | 在落地中的职责 | 主要交付物 | 更新频率 |
|---|---|---|---|
| 团队负责人 | 主持行为约定共创，维护四个日常动作的执行节奏，跟踪回顾改进项 | 行为约定清单、回顾改进项跟踪表 | 约定清单一次性建立、按需修订；改进项每周期更新 |
| 产品角色 | 组织需求澄清，明确验收条件和优先级依据，参与交付评审并带回反馈 | 澄清结论与验收条件、优先级调整记录 | 每个需求澄清时更新；优先级调整发生时记录 |
| 开发角色 | 拆解任务并在同步中暴露阻塞，保证周期结束有可运行成果，参与评审演示 | 任务拆解与状态、可演示的功能成果 | 每日同步时更新任务状态；每周期末产出可运行成果 |
| 测试角色 | 在澄清阶段提出可测性意见，在交付前给出质量结论，参与回顾的数据准备 | 测试结论与缺陷记录、质量相关数据 | 随交付节奏更新；回顾前汇总 |
分工中容易出现两类空转。一类是负责人包办了所有推动工作，团队只在会上被动确认，行为约定难以内化；另一类是记录分散在多个地方，评审时找不到澄清结论。对应的处理方式是：把每个日常动作的主持责任分给不同角色，负责人只做节奏维护；记录点统一到需求条目和任务状态两处，其他材料作为附件关联。
当团队使用 ONES 承载这些日常动作时，需求、任务、缺陷和迭代可以在同一套工作项体系中流转，看板和燃尽图用于同步进度与风险，评审和回顾的结论可以通过 ONES Wiki 关联对应任务沉淀下来。工具承担的是记录和可视化，行为约定本身仍需团队自己制定和遵守。
示例：一个迭代周期内的协作落地
以下为一个演示情景，用于说明行为约定如何贯穿一个迭代周期，不代表特定团队的真实案例。
需求澄清阶段。产品角色带着需求背景和初步优先级组织澄清会，开发与测试角色参加。会上逐条确认验收条件，测试角色提出边界场景，产品角色当场记录结论并标注优先级依据。这里体现的是“个体与互动”和“客户合作”：需求提出方或产品角色在场对话，结论落到需求条目上，而不是靠工单来回传递。若会上发现某需求需要拆分，直接进入需求池重新评估，体现“响应变化”的入口是澄清而非事后插入。
开发与测试协作阶段。开发角色按任务拆解推进，每日同步围绕看板对齐进度，阻塞当场认领。测试角色在功能可运行后介入验证，缺陷与对应任务关联。这个阶段的行为标志是周期中段就能演示部分功能，而不是等到最后一天才第一次运行。可运行成果让评审有真实对象，也让测试反馈提前发生。
交付评审与回顾阶段。评审会上演示运行中的功能，产品角色和需求提出方给出反馈，反馈分为本周期修复和进入需求池两类，分别记录去向。回顾会基于本周期的进度、质量和阻塞记录讨论改进项，每项指定负责人和检查时间。回顾结论写入团队知识库并关联相关任务，下一个周期的同步中跟踪改进项进展。这样反馈形成闭环：评审发现的问题有去向，回顾提出的改进有跟踪。
完成检查：判断落地是否真的发生
检查的目的是区分“机制已建立”和“行为已改变”。机制建立只需文件和会议，行为改变要看日常动作中是否真的按约定执行。建议每个周期末用下表核对一次，由团队负责人组织，各角色提供对应证据。
| 检查项 | 证据来源 | 负责人 | 未通过时的调整方向 |
|---|---|---|---|
| 本周期需求澄清会是否召开，验收条件是否记录在需求条目上 | 需求条目中的澄清结论 | 产品角色 | 固定澄清会的触发条件，明确缺席时的替代确认方式 |
| 每日同步是否围绕看板进行，阻塞是否有人认领 | 看板状态与阻塞记录 | 团队负责人 | 缩短同步时长，把讨论移到会后；明确阻塞的认领规则 |
| 周期结束是否有可运行成果可供演示 | 评审演示记录 | 开发角色 | 检查任务拆解粒度，把可演示节点提前到周期中段 |
| 需求方是否参与评审并给出反馈，反馈是否有去向 | 评审反馈记录 | 产品角色 | 提前约定评审参与人；反馈分类后进入需求池或修复任务 |
| 本周期计划调整是否有影响评估和团队确认 | 优先级调整记录 | 产品角色与团队负责人 | 建立变更进入需求池的统一入口，禁止口头插入 |
| 回顾改进项是否指定负责人并在下周期跟踪 | 改进项跟踪表 | 团队负责人 | 减少每周期改进项数量，只保留可验证的条目 |
判断标准可以分两层。第一层是机制层：四个日常动作是否都有说明、有负责人、有记录位置。第二层是行为层：随机抽取本周期的一次澄清、一次同步和一次评审，看记录是否完整、结论是否被后续工作引用。机制层通过而行为层不通过，说明约定停留在纸面，需要回到第一步重新讨论约定是否具体、是否被团队认可；两层都通过，才可以说敏捷宣言在本团队的日常协作中真正落了地。
常见问题
团队规模较小、角色兼职时，这套落地步骤需要怎么调整？
小团队可以合并角色，但每个交付物仍要指定一个主要责任人。例如产品角色同时承担需求澄清主持和评审反馈收集，测试意见由开发角色在澄清会上代为提出。四个日常动作可以压缩时长，需求澄清与交付评审可以合并为一次短会，每日同步控制在十分钟内。行为约定清单同样保留，只是条目可以更少，每条都写清场合和动作。调整的判断标准不变：换一个不在场的同事，能通过产出判断这件事有没有发生。
团队已有较重的流程和文档要求，如何在不推翻现有流程的前提下落地？
从现有流程中找出与四条价值观冲突最明显的环节先改，不必整体重构。常见做法是把阶段汇报改为可运行成果演示，把需求文档的结论部分前置到澄清会当场确认，把变更审批改为进入需求池统一评估并记录影响。文档本身保留，调整的是文档与对话、文档与可运行成果之间的主次关系。每次只改一到两个环节，在回顾中观察效果，再决定下一步。
行为约定执行一段时间后流于形式，怎么判断和纠正？
先看行为层的抽查结果：随机抽取本周期的一次澄清、一次同步和一次评审，检查记录是否完整、结论是否被后续工作引用。如果记录齐全但结论无人引用，说明约定与工作实际脱节。纠正方式是回到共创环节，删掉团队说不清场合的条目，把保留的条目改写成更具体的动作，并在下一个周期只跟踪两到三条。改进项数量减少、每条可验证，比一次列十几条更容易坚持。
需求方无法稳定参加澄清和评审时，客户合作这一条怎么落实？
先确认需求方能够稳定参与的最近环节，把澄清和评审安排在那个时间点，或者由产品角色带着澄清结论向需求方做一次简短确认并留下记录。关键是反馈有明确去向：本周期修复还是进入需求池，都要记录并告知需求方。若需求方长期无法参与，团队应在行为约定中写明替代确认方式，例如书面确认加定期同步，避免出现需求方只在立项和验收两端出现的情况。
用工具承载这些日常动作时，记录点应该怎么设置才不增加负担？
记录点控制在两处：需求条目承载澄清结论与验收条件，任务状态承载进度与阻塞，评审反馈和改进项作为关联内容挂到对应条目上。ONES 的需求、任务、缺陷和迭代可以在同一套工作项体系中流转，看板和燃尽图用于同步进度与风险，评审和回顾结论可以通过 ONES Wiki 关联对应任务沉淀。工具承担记录和可视化，行为约定本身仍需团队自己制定和遵守，记录耗时是否影响协作节奏应在回顾中检查。
