迭代开发实践指南：如何跑好第一个迭代

团队第一次跑迭代，目标不是一次交付多少功能，而是让所有人建立对迭代开发的共同手感：按固定节奏承诺、执行、交付和复盘。第一个迭代跑顺，团队会认可这套方法；跑乱，敏捷很容易被当成走形式。

这篇文章按一次迭代的生命周期展开，覆盖开跑前的准备、计划、执行、收尾，以及最常见错误。项目经理或研发负责人可以直接对照执行，把第一个迭代完整走一遍。

跑第一个迭代之前，先确认四个前提

第一个迭代的失败点，大多在开跑前就埋下了。排任务之前，先确认四件事。

• 统一对“迭代”和“完成”的认知。迭代是敏捷开发里固定时长的交付周期，常见 1 到 4 周。开发、测试、产品对“本轮做什么、做到什么程度算完成”必须一致。完成定义各说各话，后面的节奏都会变形。
• 关键角色到位。产品负责人负责需求排序和验收，研发团队负责承诺与交付，流程由 Scrum Master 或项目经理维护。需求方缺席，计划会很容易变成研发内部讨论。
• 需求梳理到可进入迭代。进入迭代的需求要写清业务背景、目标用户和验收标准，能估算、能拆分。梳理不充分的需求继续留在待办需求里，不放进第一个迭代。
• 周期和容量都设得保守。第一次跑迭代建议从 3 到 4 周起步，留出学习缓冲。容量按可用人天折算，扣掉会议、节假日和事务性占用，宁可少装，不靠加班兜底。

如何跑好第一个迭代：五个步骤

前提确认后，把一个迭代拆成五个动作逐个落地。下面顺序也是迭代开发的通用推进节奏。

图 1：Scrum 迭代流程示意。来源：Wikimedia Commons · Scrum process zh.svg（GFDL / CC BY-SA）

第一步：明确迭代目标，排好需求优先级

计划的第一步不是分任务，而是回答这一轮为什么做。把迭代目标写成一句话，说明迭代结束后业务或用户能得到什么变化，而不是“完成若干需求”。范围从待办需求里按业务价值和依赖关系挑选，优先放高价值、低依赖、团队有把握交付的内容。

第二步：用迭代计划会敲定范围与团队承诺

计划会要产出三样东西：迭代目标、本轮纳入范围的需求、团队承诺。会前先完成需求评审和优先级排序，会上不为模糊需求补课。第一个迭代没有历史速率，承诺容量按可用人天折算后再留出缓冲。承诺总落空，多数原因是装得太满。

第三步：把需求拆成可独立交付的任务

每个需求拆到能独立实现、可验收的任务，粒度半天到两天为宜，任务描述里写明验收标准。拆不开、估不准，说明需求还是太大，回到梳理环节继续拆。任务粒度越细，执行期进度偏差暴露得越早。

第四步：执行期用每日站会和变更规则守住节奏

迭代执行期间，每日站会控制在 15 分钟内，每人只讲三件事：昨天做了什么、今天做什么、有什么阻塞。站会做同步，不做汇报。第一个迭代对需求变更要保守：确需插入时走评估流程，最好按“一进一出”来换，也就是插入一个需求，就移出一个工作量相当的需求；线上故障等例外插队要评估影响并留痕。进度偏离时优先砍范围，而不是延长时间。

为了让站会有共同画面，可以把任务状态放到可视看板上：待办、进行中、待验证、完成各占一列。每天对照看板同步，谁在等依赖、哪项任务卡住，当场就能暴露，不用会后翻聊天记录。

图 2：任务看板示例，让执行进度与阻塞一目了然。来源：Wikimedia Commons · Simple Task Kanban（Rakuten, Inc.，CC BY-SA 3.0）

第五步：用迭代评审和回顾收口

迭代结束时先开评审会，向干系人演示可运行的结果、收集反馈，反馈是下一轮排期的输入。随后开回顾会，对事不对人，用“继续做、停止做、开始做”三栏收集改进项，落到具体责任人和时间，并写进下一轮计划会。没有行动项的回顾等于没开。

用禅道把第一个迭代落到系统里

方法要落地，最好让过程留痕。禅道项目管理软件把产品管理、项目管理、质量管理、文档管理和事务管理放在同一平台，用需求、任务、Bug、用例等核心对象承接研发流程，并通过项目集、项目、产品、执行的层级结构承载不同规模的管理对象，支持稳态与敏态双模研发管理。

• 需求梳理：使用禅道的产品需求模块维护待办需求，记录业务背景、验收标准和优先级，迭代范围从已就绪需求中选取。
• 迭代执行：把一次迭代作为独立的执行周期纳入禅道管理，关联本期需求、拆分任务并指派到成员，进度随任务更新持续可见，阻塞也能及时暴露。
• 质量闭环：对开发过程中出现的 Bug 进行跟踪闭环，让测试用例、用户反馈沉淀回同一需求链路；评审结论和复盘改进项成为下一轮迭代的输入。
• 规模化协作：多个团队在同一产品线并行跑迭代时，禅道通过项目集、项目、产品、执行的层级结构，把各团队迭代纳入统一的研发管理框架。代码托管如选用禅道生态的 GitFox，研发资产与项目管理也能保持在同一个协作体系里。

第一个迭代最容易踩的坑

团队第一次跑迭代时，问题通常集中在下面四类。

• 装得太满。计划时对容量乐观，靠加班消化承诺，结果质量和节奏一起崩。
• 中途“顺手”插需求。口头答应、不评估不记录，范围悄悄扩大，原承诺完不成。
• 任务拆太粗、验收口径不一致。开发说提测算完，产品说上线算完，复盘时各说各话。
• 站会开成汇报，回顾没有行动项。会议照开，但既没暴露阻塞，也没沉淀改进。

关于第一个迭代的高频疑问

问：迭代和版本是一回事吗？

答：不是一回事。迭代也叫冲刺，指敏捷开发中固定时长的执行周期，时间一到就结束；版本是面向用户或客户的发布口径，一个版本可以由一次或多次迭代组成。第一个迭代结束时不一定立刻对外发版，但应产出一段可演示、可验收的增量。迭代周期决定做事节奏，版本边界决定对外交付的范围。

问：测试人员什么时候介入迭代比较合适？

答：不要等开发做完再让测试介入。第一个迭代建议让测试从需求梳理阶段就参与，一起澄清验收标准、补充关键用例，并把测试工作量计入迭代容量。开发在提测前先在测试环境自测一遍，能减少评审阶段才暴露的返工。

问：技术债、重构、环境搭建这类任务要不要放进第一个迭代？

答：要放，但必须显式规划，而不是“顺手做”。第一个迭代可以拨出约两成容量给基建、技术债和测试环境类工作，并作为正式任务排入迭代、接受评审。这样既不会让它们悄悄挤占需求时间，也能避免后续迭代被环境问题反复打断。

问：迭代结束时还有任务没完成，怎么办？

答：先判断原因，是范围装多了，还是中途出现意外阻塞。未完成任务退回待办需求里重新排期，不要在评审会上临时加时硬做，为“凑完”牺牲交付质量。把没完成的原因记入回顾会，作为下一轮压缩范围或进一步拆细任务的依据。

第一个迭代的价值不在交付量，而在让团队找到属于自己的节奏。把范围控制住、把变化管起来、把复盘做下去，迭代开发才会从一套流程变成团队的真实能力。