敏捷开发落地可以从一条产品线、一个两星期迭代开始：先选定 Scrum 或 Kanban 中的一种框架，明确产品负责人、Scrum Master 和开发团队三类职责，建立按价值排序的产品待办列表；再通过迭代规划、每日站会、评审和回顾跑完一轮，用完成定义约束质量，最后按检查项判断首轮是否跑通。本文按这条路径给出角色分工表、操作清单和完成检查清单，并说明 ONES 在待办排序、任务拆分、迭代进度与回顾沉淀中的衔接方式。
要点总览（TL;DR）
- 敏捷开发起步先选定一种框架：需求变化频繁、需要固定反馈点选 Scrum；任务持续到达、交付随条目流动选 Kanban，首轮不混用两套机制。
- 三类角色各对一种结果负责：产品负责人定优先级与验收标准，Scrum Master 组织事件并跟踪阻碍，开发团队拆分任务并交付增量，每项决定写明拍板人。
- 一个迭代按五步走：建立并排序产品待办列表、迭代规划、每日站会、迭代评审、迭代回顾，每步都有输入、输出和完成标志。
- 完成定义约束所有条目的质量底线，写成可逐条判断的条件；验收标准针对单个条目判断业务是否通过，两者配合使用。
- 首轮迭代结束用检查清单核对角色、事件、增量、待办列表和回顾改进项，发现偏差作为下一轮改进输入。
先定框架：Scrum 还是 Kanban
敏捷开发的第一步是选定一种起步框架，并把它的会议、看板列和角色语义固定下来。Scrum 与 Kanban 都能支撑敏捷开发，差别在于节奏来源：Scrum 以固定长度的迭代组织交付，每个迭代结束时产出可运行增量；Kanban 以持续流动组织工作，用看板列和列容量限制控制在制品，交付随条目完成而持续发生。
选择时看三个条件。需求变化频率高、需要定期与业务方对齐方向，Scrum 的迭代评审提供了固定反馈点；需求以持续到达的运维、支持类任务为主，交付节奏由条目流动决定，Kanban 更贴近实际。团队规模较小、角色尚未完全分离时，Kanban 的规则负担更轻；团队达到可独立承担迭代目标的规模，Scrum 的角色与事件更容易形成稳定协作。交付节奏还受外部约束影响：如果业务方需要按固定周期拿到可演示版本，固定迭代更便于安排评审。
起步阶段只采用一种框架。常见问题是同时引入迭代规划和看板列容量限制，导致站会上既讨论迭代目标又讨论列拥堵，团队无法判断哪个机制在起作用。选定框架后，写一份框架选择说明，包含三项内容：所选框架、选择理由（对应上述哪个条件）、首轮明确不采用的机制。例如选择 Scrum 时，说明首轮不启用看板列的在制品限制，看板只用于展示任务状态；选择 Kanban 时，说明首轮不设固定迭代评审，改为按交付批次做演示。
框架确定后，事件与看板列要一次定义清楚。Scrum 至少明确迭代规划、每日站会、迭代评审、迭代回顾四个事件的时间与参与人；Kanban 至少明确看板列名称、每列的进入条件与退出条件。这些定义写在团队可见的位置，首轮不再改动，避免执行中反复调整规则。
角色怎么分：三类职责与交接边界
敏捷团队的三类角色分别对不同的结果负责：产品负责人对“做什么、先做哪个”负责，Scrum Master 对“流程是否按约定运转”负责，开发团队对“交付的增量是否满足完成定义”负责。角色可以兼任，但每项决定要有明确的拍板人。
| 角色 | 输入 | 主要动作 | 输出 | 必须由谁拍板 |
|---|---|---|---|---|
| 产品负责人 | 业务目标、用户反馈、待办条目 | 维护产品待办列表，按价值排序，为条目写验收标准，参与评审并确认反馈去向 | 排好序的产品待办列表、每个条目的验收标准、评审后的调整决定 | 条目优先级与范围取舍由产品负责人决定 |
| Scrum Master | 团队约定的事件安排、阻碍记录 | 组织规划会、站会、评审、回顾，记录并跟踪阻碍，观察流程偏差 | 事件记录、阻碍清单及处理状态、流程改进建议 | 流程规则调整由 Scrum Master 提出、团队确认 |
| 开发团队 | 迭代目标、选中的待办条目、验收标准 | 拆分任务、估算工作量、领取任务、交付增量、在站会同步进展 | 迭代待办列表、可运行增量、任务状态更新 | 任务如何拆分与技术实现方式由开发团队决定 |
交接边界要写进团队约定。产品负责人把条目放入迭代后，迭代内的任务拆分不再由产品负责人逐项指定；开发团队在规划会上对范围提出异议，由产品负责人决定是否调整，调整结果记录在迭代待办列表中。Scrum Master 不替开发团队分配任务，遇到阻碍时负责推动解决并记录状态。评审会上业务方提出的新需求回到产品待办列表，由产品负责人排序，不直接插入当前迭代。
兼任情形需要额外说明。产品负责人兼任开发任务时，优先级判断与任务执行容易混在一起，建议把排序动作固定在规划会前完成，迭代内只做验收确认。Scrum Master 由团队成员兼任时，站会主持与任务汇报分开进行，先同步进展再处理阻碍，避免流程职责被任务讨论淹没。
核心操作步骤：从待办列表到可交付增量
以下步骤按一个迭代的时间顺序排列，每步给出输入、动作、输出和完成标志，可直接作为首轮迭代的操作清单。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 建立并排序产品待办列表 | 业务目标、用户反馈、已有需求记录 | 把候选条目写成一句话描述，补充验收标准，按价值与紧急程度排序 | 一份有序的产品待办列表 | 每个条目有描述和验收标准，顺序无并列争议 |
| 2. 迭代规划 | 有序待办列表、团队可用工时、上轮回顾结论 | 选取本轮条目，写迭代目标，把条目拆成任务并估算 | 迭代目标、迭代待办列表 | 迭代目标一句话可读，每个条目都有任务和估算 |
| 3. 每日站会 | 迭代待办列表、任务状态 | 每人说明昨日完成、今日计划、遇到的阻碍，会后更新任务状态 | 更新后的任务状态、阻碍清单 | 站会控制在约定时长内，阻碍有跟进人 |
| 4. 迭代评审 | 满足完成定义的增量、验收标准 | 演示增量，逐条对照验收标准确认，收集反馈并记录去向 | 验收结论、反馈条目 | 每个选中条目有通过或未通过的明确结论 |
| 5. 迭代回顾 | 迭代数据、评审结论、团队观察 | 识别做得好的与需要改进的，选出少量改进项并指定负责人 | 改进项清单，进入下一轮规划 | 改进项有负责人和验证方式，下一轮规划会引用 |
第1步的关键是把“排序”落到可判断的依据上。价值高、依赖少、能独立演示的条目排在前面，便于首轮迭代产出可见增量。条目描述避免只写模块名，写成“谁在什么场景下完成什么动作”，验收标准随之可写。
第2步的规划会分两段：前半段由产品负责人说明条目与优先级，团队确认理解一致；后半段由开发团队拆分任务并估算，形成迭代目标。迭代目标用一句话描述本轮要达成的结果，例如“完成订单查询的筛选与导出，业务方可自助验证”。范围超出团队容量时，在规划会上就删减条目，不把超载带入迭代。
第3步站会只同步状态与阻碍，技术方案讨论会后单独进行。任务状态在看板上更新，未动的任务不标为进行中，避免进度失真。第4步评审以可运行增量为准，演示环境提前准备；未满足完成定义的条目不计入完成，回到待办列表重新排序。第5步回顾聚焦可执行的改进项，数量控制在团队下一轮能验证的范围内。
在工具承载上，ONES 支持产品负责人按需求优先级把产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队评审需求、就验收标准达成一致后，由设计、研发、测试人员用子任务拆分需求；迭代中团队通过敏捷看板管理任务状态，在每日站会中借助看板对齐进度与风险，并用燃尽图评估研发效率。这些能力对应上述第2至第3步的动作，团队仍需要自己完成排序判断与任务拆分。
工件与完成定义：让交付标准可判断
敏捷开发中有三类工件承担不同作用。产品待办列表是全部候选工作的有序集合，由产品负责人维护，条目可以增删和重排；迭代待办列表是本轮选中的条目及其任务拆分，迭代内范围调整需要记录；增量是本轮实际交付、满足完成定义的工作成果，评审以增量为对象。
| 工件 | 承载内容 | 维护人 | 更新时机 |
|---|---|---|---|
| 产品待办列表 | 全部候选条目、优先级、验收标准 | 产品负责人 | 评审后、需求变化时 |
| 迭代待办列表 | 本轮条目、任务拆分、估算、迭代目标 | 开发团队 | 规划会形成，迭代内随进展更新 |
| 增量 | 满足完成定义的可运行成果 | 开发团队 | 条目完成并通过完成定义检查时 |
完成定义约束所有条目的质量底线，写法要落到可验证的条件。笼统的“代码完成”无法判断，可改为逐项条件：代码已合并到主干；单元测试通过且覆盖新增逻辑；在测试环境完成验证并记录结果；相关文档已更新；产品负责人已确认验收标准。每条条件都能用“是/否”回答，评审前逐条核对。
验收标准针对单个条目描述业务上是否通过，完成定义针对所有条目描述工程质量是否达标，两者配合使用：条目先满足完成定义，才进入评审；评审时再对照该条目的验收标准判断是否被接受。完成定义由团队共同约定，首轮写五到七条即可，回顾时根据实际遗漏补充。完成定义写在团队可见的位置，规划会上逐条确认，避免评审时才发现标准不一致。
一个两星期迭代的示例
以下为演示情景，用于说明流程如何串联，不代表任何真实团队的实施结果。某产品团队选择 Scrum，团队包括一名产品负责人、一名兼任 Scrum Master 的成员和四名开发成员，迭代长度两周，迭代目标为“完成账户设置页的修改与保存，业务方可自行验证”。
第一周周一上午开规划会，产品负责人带来已排序的待办列表，选中三个条目：账户信息展示、修改表单、保存与校验。团队确认验收标准后拆出任务并估算，形成迭代待办列表。当天下午开发成员领取任务，看板建立“待办、进行中、待验证、完成”四列。
此后每天上午开十五分钟站会，成员说明进展与阻碍。第二天出现接口字段不一致的阻碍，Scrum Master 记录并协调对接人，第三天解除。看板上的任务状态随实际进展更新，燃尽图用于观察剩余工作量是否偏离。
第二周周四做评审，团队在测试环境演示修改与保存流程，逐条对照验收标准确认。产品负责人对保存后的提示文案提出调整，该反馈记入产品待办列表，不插入本轮。周五开回顾会，团队对照迭代数据讨论，选出两项改进：规划会前提前确认接口字段，评审演示环境提前一天准备，两项均指定负责人，进入下一轮规划会。
这个示例中完成定义在评审前被逐条检验：代码合并、测试通过、测试环境验证记录、文档更新均完成，才进入演示。可迁移的规律是：迭代目标保持一句话、范围调整走待办列表、阻碍在站会上暴露并有人跟进、回顾改进项数量少且有验证方式。团队规模、迭代长度和条目内容可按实际情况调整，这套串联顺序不变。
ONES 在迭代完成后可召开回顾会，通过燃尽图、工时日志、持续集成报告等数据报表复盘进度、质量与成本偏差，并用 ONES Wiki 沉淀经验形成团队知识库；ONES Project 提供敏捷等项目模板，支持建立需求池与规划迭代。回顾结论能否真正进入下一轮，仍取决于团队是否在规划会上引用改进项。
完成检查：首轮迭代结束看什么
首轮迭代结束后，用以下清单逐项核对，判断敏捷实践是否跑通。检查以事实记录为依据，不以主观感受代替。
- 角色是否到位：产品负责人、Scrum Master、开发团队均有明确人员，优先级、流程组织、任务拆分三类决定分别有人拍板。
- 事件是否按期发生：规划会、每日站会、评审、回顾按约定时间召开，站会时长在约定范围内，缺席有记录。
- 增量是否满足完成定义：本轮完成的条目逐条通过完成定义检查，未通过的条目回到待办列表，未计入完成。
- 待办列表是否保持排序与更新：评审反馈已进入待办列表并重新排序，条目描述与验收标准完整。
- 回顾改进项是否进入下一轮：改进项有负责人，下一轮规划会明确引用并安排验证方式。
常见偏差及调整方向：站会变成问题讨论会，调整为会后单独讨论，站会只同步状态与阻碍；迭代范围中途插入新条目，调整为反馈统一进入待办列表，由产品负责人排序；完成定义形同虚设，调整为评审前逐条核对并记录结果；回顾改进项过多无法验证，调整为每轮只保留少量可验证项。首轮的目标是跑通一轮完整流程，检查中发现的问题作为下一轮改进输入，不要求首轮所有指标达到稳定水平。
常见问题
团队第一次推行敏捷，应该先做规划会还是先整理待办列表？
先整理待办列表。规划会需要一份已排序、带验收标准的候选条目作为输入，否则会议容易变成现场讨论需求内容，无法形成迭代目标。建议在规划会前由产品负责人完成条目描述、验收标准和排序，规划会上团队只做理解确认、任务拆分和估算。首轮条目数量控制在团队能在一轮内交付的范围内，宁少勿多。
产品负责人和开发团队在范围上意见不一致时，谁来定？
范围取舍由产品负责人拍板。开发团队在规划会上提出容量或技术风险方面的异议，产品负责人据此决定删减哪些条目或调整顺序，调整结果记录在迭代待办列表中。迭代开始后，评审会上业务方提出的新需求统一回到产品待办列表，由产品负责人重新排序，不直接插入当前迭代。把这条边界写进团队约定，可以减少迭代中途的范围争议。
完成定义写多少条合适，什么时候补充？
首轮写五到七条即可，覆盖代码合并、测试通过、环境验证、文档更新、验收确认等可判断的条件。完成定义由团队共同约定，写在团队可见的位置，规划会上逐条确认。回顾时如果发现某类问题反复漏检，就在完成定义中补一条对应条件；条件过多导致评审前核对负担过重时，合并同类项。完成定义保持稳定，避免每个迭代重新讨论。
首轮迭代没跑顺，是否要停下来重新设计流程？
不需要。首轮的目标是跑通一轮完整流程，站会超时、范围中途变动、完成定义执行不到位都属于常见偏差。处理方式是在回顾会上把问题转成少量可验证的改进项，指定负责人，并在下一轮规划会上引用。连续几轮都出现同一类偏差时，再考虑调整事件安排或规则本身。流程调整以实际记录为依据，比一次性重新设计更容易落地。
用工具管理待办列表和迭代，能替代团队自己的判断吗？
不能。工具承载的是排序结果的记录、任务拆分、状态更新和进度视图，优先级判断、验收标准确认、任务如何拆分仍由团队完成。以 ONES 为例，产品负责人可按优先级把需求规划至对应迭代，团队在计划会议上就验收标准达成一致后用子任务拆分需求，迭代中通过敏捷看板管理任务状态、用燃尽图观察进度。这些能力对应流程中的记录与同步动作，判断环节需要团队自己承担。
