敏捷开发落地通常从两个动作开始：先判断团队该用 Scrum 还是 Kanban，再把选定框架压缩成角色、事件、工件和完成定义四类最小规则，用一个迭代验证后按证据调整。本文按这一顺序展开，给出框架选择判断表、一页运行规则、角色与交付物对照、首个迭代示例和落地检查清单；ONES 可作为承载工作项状态、迭代看板与回顾文档的工具，具体配置按团队规则设定。
要点总览（TL;DR）
- 框架选择看工作特征：需求在迭代内相对稳定、能按固定节奏交付增量的团队以 Scrum 为起点；工作持续流入、需要控制在制品数量的团队以 Kanban 为起点。
- 选定框架后先写一页最小规则，覆盖角色决策边界、事件时间盒与产出、工件字段与状态、完成定义四类内容，保证第一周就能照着执行。
- 角色分工用对照表固定下来，交接以交付物是否存在为确认依据，计划会、评审会、回顾会结束时各自要有对应产物。
- 首个迭代的作用是验证规则本身，重点观察事件是否按时召开、工件是否被真实更新、完成定义是否被逐项判定。
- 落地是否到位看规则执行情况而非会议次数；连续两个迭代未达目标、事件反复超时、在制品持续堆积时，一次调整一到两条规则再观察。
先判断用 Scrum 还是 Kanban
框架选择看工作本身的特征，不看团队偏好。判断的核心是两件事：需求在迭代内是否相对稳定，以及工作是否按固定节奏成批交付。需求变化频繁、需要短周期交付反馈的团队，以 Scrum 为起点；工作持续流入、需要控制在制品数量的团队，以 Kanban 为起点。选定一个框架先跑起来，比同时套用两套规则更容易暴露问题。
选择前需要确认三项项目条件。第一是需求变化程度：如果每个迭代内需求大体可锁定，Scrum 的迭代承诺有意义；如果需求随时插入、优先级每天变化，Kanban 的持续流动更贴近现实。第二是交付节奏：能按一到四周固定节奏交付可用增量的团队适合 Scrum；交付由外部事件驱动、无法按固定周期切分的团队适合 Kanban。第三是工作流入方式：工作由迭代计划统一纳入的，用 Scrum；工作从多个来源持续进入、需要限制同时进行数量的，用 Kanban。
| 项目特征 | 更匹配的框架 | 判断说明 |
|---|---|---|
| 需求在迭代内相对稳定，可按周期交付增量 | Scrum | 迭代承诺与评审反馈形成闭环 |
| 需求频繁变化，优先级需要随时调整 | Kanban | 以流动和拉动代替迭代承诺 |
| 工作持续流入，来源多、类型杂 | Kanban | 用列和在制品上限控制同时进行的工作 |
| 需要固定节奏对齐多方评审与发布 | Scrum | 事件时间盒提供稳定的对齐节点 |
| 团队刚起步，尚无稳定交付节奏 | 先选一个，跑两到三个迭代再评估 | 避免规则叠加导致无法判断哪条规则有效 |
选定框架后，需要固定的最小规则范围包括：谁承担哪些角色、哪些事件必须召开及各自时间盒、工件包含哪些字段和状态、完成定义覆盖哪些检查项。这四类规则写在一页纸内，团队能照着执行即可，细节留到迭代回顾中补充。
搭建最小可运行的敏捷规则
最小规则的目标是让团队第一周就能按规则开会、更新工件、判定完成，而不是建立完整体系。以下四要素各给出可直接填写的内容。
角色职责与决策边界
产品负责人对“做什么、先做哪个”有最终决定权，负责维护待办事项的顺序和验收标准；Scrum Master 或流程负责人对“规则是否被遵守”负责，组织事件、清除障碍，不替团队分配任务；开发团队对“怎么做、做多少”负责，集体承诺迭代范围并自行拆解任务。决策边界要写清楚：范围变更由产品负责人决定，工艺与技术方案由开发团队决定，流程调整在回顾会上共同决定。
事件的时间盒与产出
每个事件写明时长上限和必须产出的东西，没有产出的会议视为未完成。迭代计划会产出一份迭代目标与任务清单；每日站会产出障碍清单和当天调整；评审会产出验收结论与待办变更；回顾会产出一到两项下个迭代要执行的改进项。时间盒按迭代长度设定，例如两周迭代中计划会不超过四小时、站会不超过十五分钟，团队可按实际情况调整并写入规则。
工件的最小字段与状态
待办事项至少包含标题、价值说明、验收标准、优先级和负责人；迭代任务至少包含所属需求、负责人、预估工时和状态。状态建议控制在少量几列，例如待办、进行中、待验证、完成，列数过多会让看板失去可读性。字段和状态的目的是让站会和评审有共同依据，字段缺失时应在站会上补齐，而不是会后补录。
完成定义的编写方法
完成定义逐条写成可判定的检查项，每条都能回答“是或否”。写法上从交付物出发：代码是否已合并、是否通过约定的测试、文档是否更新、是否经过验收人确认。避免写“质量达标”这类无法判定的表述。完成定义由团队共同商定，一旦写入规则，迭代内不随意放宽；需要调整时在回顾会上提出并记录原因。
角色分工与各环节交付物
职责重叠和职责空缺是敏捷落地最常见的两类问题。用一张对照表把角色、事件和交付物固定下来，交接时以交付物是否存在作为确认依据，可以减少口头约定带来的遗漏。
| 环节 | 产品负责人 | Scrum Master／流程负责人 | 开发团队 | 交付物 |
|---|---|---|---|---|
| 迭代前准备 | 整理并排序待办事项，写明验收标准 | 确认事件安排与规则就绪 | 提供技术可行性意见与预估 | 排好序的待办清单、迭代目标草案 |
| 迭代计划会 | 说明目标与优先级，确认范围 | 主持并控制时间盒 | 拆解任务、认领并承诺范围 | 迭代目标、任务清单与负责人 |
| 每日站会 | 按需参加，回应需求疑问 | 组织站会，记录障碍 | 同步进展、暴露障碍、调整当天安排 | 更新后的看板、障碍清单 |
| 迭代评审 | 验收增量，决定待办调整 | 组织评审并记录结论 | 演示已完成内容 | 验收结论、待办变更记录 |
| 迭代回顾 | 参与讨论改进项 | 主持回顾，跟踪改进项落实 | 提出改进建议并认领行动 | 改进项清单与责任人 |
交接确认采用“交付物在场”原则：计划会结束时任务清单已分配到人，评审结束时验收结论已记录，回顾结束时改进项已有责任人和期限。任何一环缺少交付物，由流程负责人当场指出并补做，而不是留到下一个迭代。
当团队把上述规则搬到工具中执行时，工作项状态、迭代看板和评审记录需要有统一的承载位置。ONES 敏捷研发管理方案覆盖需求、研发、测试的流程衔接，把需求提出方、产品经理、研发和测试等角色放在同一套工作项上协作；迭代中团队通过敏捷看板更新任务状态，站会时用看板对齐进度与风险。迭代结束后，燃尽图、工时日志等报表可用于回顾进度与质量偏差，经验可用 ONES Wiki 沉淀为团队知识库。对于中大型团队，ONES 还提供组织架构管理、资源管理与全局进度管控，便于在多团队并行时保持规则一致。
一个团队的首个迭代示例
以下示例用于演示规则如何在一个迭代内跑通，团队与数据均为示意，实际执行按自身情况替换。
迭代开始前的准备输入包括：产品负责人整理好的待办清单，前五项已写验收标准并按优先级排序；团队确认的完成定义，包含代码合并、单元测试通过、文档更新、验收人确认四项；以及两周迭代的日历，计划会、站会、评审会、回顾会时间已排定。
迭代第一天召开计划会，产品负责人说明迭代目标，团队逐项估算并承诺范围，将选中的需求拆成任务并分配到人，产出迭代目标和任务清单。此后每天站会十五分钟，成员对照看板说明昨天完成、今天计划、遇到的障碍，流程负责人记录障碍并跟进。迭代中期若出现新需求，产品负责人将其放入待办清单并标注优先级，是否进入当前迭代由团队评估容量后决定，变更记录在评审会上说明。
迭代最后一天召开评审会，团队演示已完成的需求，产品负责人按验收标准逐项确认，未通过项退回待办并注明原因，产出验收结论与待办变更记录。随后召开回顾会，对照燃尽图和工时记录讨论进度偏差，产出一到两项改进项，例如“站会障碍当天登记到看板”并指定责任人。完成定义的判定在评审会上逐条执行：代码已合并、测试通过、文档更新、验收人确认四项全部满足才计为完成，任一缺失则不计入迭代完成量。
该迭代的产物清单包括：迭代目标与任务清单、每日更新的看板与障碍清单、验收结论与待办变更记录、改进项清单。这些产物构成下一轮调整规则的依据。
落地完成检查与调整依据
判断敏捷是否落地到位，看规则是否被真实执行，而不是看会议是否开过。以下检查项可逐条核对，每项给出可观察的判定标准。
- 计划会是否在时间盒内结束，并产出分配到人的任务清单；
- 站会是否每天召开，障碍是否当天登记并有跟进人；
- 看板状态是否在站会前更新，字段缺失是否当场补齐；
- 评审会是否按验收标准逐项判定，未通过项是否退回待办；
- 完成定义是否在每次评审中被逐条使用，而非事后追认；
- 回顾会的改进项是否在下一个迭代中被执行并复核。
交付节奏与在制品数量是两项持续观察的指标。交付节奏看每个迭代实际完成的条目数与承诺数的差距，连续两个迭代差距过大，说明承诺方式或任务拆解需要调整。在制品数量看进行中列同时存在的任务数，若长期堆积且完成时间拉长，应设定在制品上限并限制同时开工。使用 Kanban 的团队尤其需要关注这一指标，Scrum 团队也可用其判断迭代内是否存在并行过多的问题。
调整规则需要触发条件，避免凭感觉频繁改动。常见触发条件包括：连续两个迭代未达成迭代目标；站会或评审会连续多次超时；完成定义中的检查项反复被跳过；回顾会改进项连续未落实；在制品数量持续上升且交付周期延长。触发后先在回顾会上定位原因，一次只调整一到两条规则，并在下一个迭代观察效果，形成“执行—观察—调整”的循环。
常见问题
团队同时有迭代交付和线上问题处理两类工作，只选一个框架够用吗？
可以先用一个框架建立主规则，再为另一类工作补充少量约定。常见做法是以 Scrum 管理迭代交付，把线上问题作为独立来源持续进入，在站会上明确当天投入处理的比例，并记录处理量。关键是两类工作共用同一块看板和同一套完成定义，避免出现两套口径。若线上问题占比长期超过迭代工作量的一半，说明工作流入方式更接近持续流动，可考虑整体转向 Kanban，或把问题处理单独设为一个固定容量的工作流。
完成定义写多少条合适，写多了会不会拖慢评审？
完成定义按交付物逐条写，初期控制在四到六条，覆盖代码合并、测试通过、文档更新、验收确认这类可判定项即可。条目多并不必然拖慢评审，真正影响效率的是条目无法判定，例如“质量达标”这类表述会让评审变成讨论。建议把检查项做成评审时的逐条勾选，未满足的项当场退回待办并注明原因。随着团队问题暴露，再在回顾会上增补条目，每次增加都记录原因，避免完成定义无限膨胀。
迭代进行中插入紧急需求，规则上应该怎么处理？
先区分两种情况。若新需求确实紧急且影响当前迭代目标，由产品负责人在待办清单中登记并标注优先级，团队评估剩余容量后决定是否替换等量工作，被替换的条目退回待办，变更在评审会上说明。若不紧急，放入待办等待下个迭代排序。规则中应写明谁有权发起插入、由谁评估容量、变更记录在哪里留痕，这三项确定后，插入就不再依赖临时协商。连续多个迭代都出现大量插入时，说明需求侧稳定性不足，应在回顾会上讨论是否调整框架或承诺方式。
团队规模较小，角色可以兼任吗？
小团队中角色兼任常见，但决策边界仍需分开写清楚。产品负责人与流程负责人可以由不同人担任，也可以兼任，前提是范围决策与流程执行两类职责在规则中分别说明，避免同一个人既定范围又判定规则执行。开发团队内部的工艺与技术方案决定权应保留在团队，不因人数少而上收到个人。兼任时建议在规则中注明哪些事项需要两人以上共同确认，例如范围变更和完成定义调整，用确认动作弥补角色分离不足。
敏捷落地一段时间后，怎么判断该继续沿用还是换框架？
先看规则执行情况再看框架适配度。如果事件按时召开、工件被真实更新、完成定义被逐项使用，但交付节奏仍长期不稳，问题可能出在框架与工作特征的匹配上，例如需求随时插入却坚持固定迭代承诺，此时可评估转向 Kanban 或以 Kanban 为主。如果规则本身就没被执行，换框架不会解决问题，应先回到执行检查项逐条核对。调整时保留已验证有效的部分，一次只改一到两条规则，并在下一个迭代观察效果。
