迭代与增量：按可验证能力推进

迭代强调通过反馈反复完善同一能力，增量强调逐步增加可用能力。订单导出的按钮经过三轮试用调整，是迭代；先支持小批量 CSV，再增加异步任务和导出历史，是增量。实际开发通常同时使用两者。

“第一周后端、第二周前端、第三周测试”只是分阶段工作，不一定产生可用增量。如果前三周都无法完成一次真实导出，团队仍然要等到最后才知道接口和交互能否配合。

以业务闭环切分

第一批可以只支持受控范围内的 CSV，但仍要贯通入口、权限、查询、生成和下载。文件不含敏感字段，数据量有明确上限，失败可见。第二批再增加异步任务，第三批补历史和恢复能力。每一批都能被单独试用和验证。

增量	用户获得的能力	每轮需要验证的行为
受控 CSV	授权用户下载有限范围的订单明细	租户隔离、字段白名单、文件格式、超限提示
异步导出	大批量请求生成任务并查询进度	重复提交、任务超时、资源上限、下载鉴权
导出历史	找到已完成任务并处理失败	文件过期、失败重试、审计记录、清理机制

权限和隔离不是等“功能做完”再加入的高级特性。增量可以缩小业务范围，但不能让已开放的路径缺少必要约束。没有权限的导出按钮可以是测试原型，不能作为生产增量。

一轮开发如何结束

每轮开始时选择一个能够说明价值的目标，例如“财务能导出最近一天的已支付订单”。把目标落实成验收场景，再实现和检查。评审不仅展示页面，还核对实际文件、失败状态和相关测试；回顾再分析等待、返工或未完成事项。

反馈改变下一轮计划或当前轮的局部方案。如果财务发现必须按支付时间筛选，应先判断是否改变本轮目标；字段顺序调整可以局部修正；退款明细则应独立评估，不应不断扩大当前批次。

迭代长度取决于反馈成本和团队环境，不由模型固定为两周。采用 Scrum 时 Sprint 为一个月或更短；持续流动的看板也可以不使用固定 Sprint。共同要求是反馈及时，改动足够小，完成标准清楚。

规格和代码一起演进

增加异步任务后，“请求成功”只代表任务已接受，不代表文件已生成；界面、接口、测试和文档都要反映这个变化。不能只修改后端，再让旧界面继续显示“导出成功”。

一份轻量任务记录可以包含目标、非目标、验收和反馈：

本轮目标：授权财务用户可下载最近一天的已支付订单 CSV。
非目标：不做退款明细，不做大批量异步任务。
验收：租户隔离；金额一致；无手机号；超限时返回明确错误。
反馈：观察字段顺序和筛选习惯，决定下一批能力。

AI 参与时，每次委托一个这样的切片，交付后查看差异并运行检查。让 Agent 一次性实现全部路线，往往失去了中途发现需求错误的机会。

如何识别无效迭代

如果每轮都展示未接数据的界面，接口风险仍被留到最后；任务一直“完成 90%”却无法验收，批次可能过大；新功能不断叠加但回归越来越慢，验证和架构边界可能没有随增量维护。

检查成效，应看可验收能力、从开始到完成的时间、返工原因和运行问题。故事点适合团队内部规划，不能跨团队比较生产率，也不能证明业务价值。真正的推进是下一轮能够基于已经验证的能力继续工作。

→ 敏捷、Scrum 与看板 · 方法组合实践