敏捷、Scrum 与看板：组织反馈和工作流
敏捷强调通过工作的软件、业务合作和及时反馈调整计划。它并不取消文档、设计和验收，而是要求这些工作服务于交付。Scrum 提供围绕目标和 Sprint 的协作框架，看板方法关注可视化工作流、拉动和在制品限制；两者都可以结合测试、持续集成和 AI 编程。
订单导出可能同时收到财务、运营和客服的请求。若每个请求都立即开工，开发者会频繁切换，评审者无法及时检查，最后没有一项真正上线。组织工作的重点是共同确定优先级、控制承诺、暴露阻塞，而不只是每天开会。
Scrum 围绕目标推进
Scrum 的 Product Owner 对产品价值和 Product Backlog 管理负责，Developers 对形成可用增量负责，Scrum Master 对建立和改进 Scrum 的有效运作负责。这些是责任划分，不是“产品派任务、开发执行、主持人催进度”的流水线。
Sprint 为一个月或更短，围绕 Sprint Goal 组织工作。规划确定目标和执行计划，Daily Scrum 检查目标进展并调整计划，Review 与利益相关者检查结果和后续方向，Retrospective 改进工作方式。Review 不是只能在 Sprint 最后才能发布的审批门。
对订单导出，Sprint Goal 可以是“财务能获得可对账的受控 CSV”，而不是“完成十张任务卡”。开发者可根据新事实调整具体任务，但不能随意把目标改成客服数据平台。紧急事故要显式处理容量和目标影响，不能既插入大量工作又要求原承诺完全不变。
Definition of Done 描述增量必须达到的质量状态，例如相关测试通过、权限验证完成、能够构建、文档已同步。它与单个功能的验收条件不同：验收说明某功能做什么，Done 说明团队交付的工作达到什么共同质量要求。不满足 Done 的工作不能算作完成增量。
看板控制流动和排队
看板先定义真实工作流：待澄清、可开始、实现中、评审中、验证中、完成。明确各状态的进入和退出条件，再对关键阶段设 WIP 上限。下游没有容量时，上游先协助解除阻塞，而不是继续启动更多任务。
例如评审中最多允许两个变更。这只是团队初始策略，不是通用标准。当两项已满，工程师应协助补证据、拆小差异或处理反馈。若只是把未评审代码移到“待验证”规避上限，排队并没有消失。
| 观察项 | 它回答的问题 | 发现异常后的动作 |
|---|---|---|
| WIP | 同时有多少项已开始未完成 | 停止拉入新任务，检查容量和阻塞 |
| 工作项年龄 | 尚未完成的任务已持续多久 | 优先检查老任务，明确下一动作 |
| 周期时间 | 从约定开始点到完成点用了多久 | 区分实现、评审、等待和返工 |
| 吞吐量 | 固定时间内完成多少工作项 | 结合任务切分和质量解释变化 |
度量时固定起止口径，保留阻塞时间。把等待从数据里删除，会让仪表盘变好却不能解释真实交付。可基于历史周期时间建立服务水平预期，但它是用于预测的经验数据，不是对每个任务的保证。
如何选择与组合
有稳定产品目标、能进行短周期反馈的团队，可以使用 Scrum 组织迭代；任务到达不规则、故障与维护较多的团队，可以用看板管理持续流动。Scrum 团队也可使用 WIP 和流动度量改善 Sprint 内部工作，两者不必互斥。
无论采用哪种方式，都要保留业务验收和技术验证。没有测试的快速迭代会积累回归风险；没有反馈的严格排期会稳定交付错误方向。XP 和 工程验证 补的是实现质量，DevOps 补的是交付与运行能力。
AI 加速后为什么更需要控制批次
AI 可以在短时间产生大量差异，人的评审容量却不会同比增加。如果只提高编码量，评审队列和返工可能更严重。对 Agent 任务同样设范围和在制品限制，一次提交一个可解释的能力，附上测试结果和未覆盖边界。
每日检查可以围绕“哪个任务阻碍目标、谁能帮助完成”展开，而不是汇报生成了多少代码。检查敏捷是否有效，应看目标达成、反馈是否改变计划、交付等待与缺陷是否下降。会议次数、故事点和 AI 代码比例不能单独证明成效。