AGILE · Scrum / 看板 / 迭代实践
敏捷协作速查
从 Scrum 三角色三工件五事件、看板 WIP 限制，到用户故事与估算方法、迭代仪式实操，再到度量指标的正确用法、高频反模式纠正、迭代启动清单与流动效率提升动作，敏捷落地全流程的 47 条实操要点一张表收齐，开箱即用。
47条速查
8大板块
∞持续更新
📖 速查表
点击展开各小节
🏛️ Scrum 框架
| 名称 | 说明 | 要点 |
|---|---|---|
| PO 产品负责人 | 定优先级、定方向，对产品价值负责 | 唯一有权调整 Backlog 排序的人；要随时找得到、答复快 价值守门人 |
| SM 敏捷教练 | 保障流程落地、移除障碍、守护团队节奏 | 不是项目经理换皮：不派活、不追进度，管流程不管人 流程守护者 |
| Team 开发团队 | 跨职能自组织，对交付质量共同负责 | 5~9 人为宜；估点与承诺都由团队自己做主 |
| Product Backlog | 有序的需求清单，唯一需求入口 | 顶部细、底部粗（DEEP 原则），持续梳理而非一次定稿 |
| Sprint Backlog | 本次迭代认领的条目与实施计划 | 团队自领不分配；迭代中途 PO 不得擅自改动 范围受保护 |
| 增量 Increment | 每个迭代结束时可交付、可用的产品部分 | 满足完成的定义（DoD）才算增量，半成品不算 可交付标准 |
| Sprint 冲刺 | 固定时长（1~4 周）的迭代容器，期间范围保持稳定 | 周期一旦定下不改；中途加急需求放下一迭代 节奏稳定 |
| 五事件目的 | 计划会对齐做什么、每日站会同步并暴露障碍、评审会验收价值、回顾会改进过程 | 每个会议各答一个核心问题，别全开成汇报会 |
📋 看板方法
| 名称 | 说明 | 要点 |
|---|---|---|
| 可视化流动 | 把工作流画成列（待办 / 进行 / 评审 / 完成），卡片流动即进度 | 墙上的状态 = 真实状态，一图暴露全部瓶颈 一图看全局 |
| WIP 限制 | 每列并行数量设上限，满了就先收尾、不接新活 | 多任务切换是效率杀手；WIP = 人数 × 1~1.5 起步 少即是多 |
| 泳道分类 | 按紧急通道 / 常规 / 技术债分行管理 | 泳道不超过 3 条，多了看板反而看不清 |
| 流动效率 | 工作时间 ÷ 总周期时间 × 100%，衡量等待占比 | 多数团队低于 40%；减少等待比加班有效 等的人越少越快 |
| 拉动式生产 | 上游有空位才接新需求，由下游产能拉动 | 与推送式相对：先清库存再造货，避免半成品堆积 |
📝 需求与估算
| 名称 | 说明 | 要点 |
|---|---|---|
| 用户故事模板 | 作为<角色>，我希望<功能>，以便<价值> 三段式 | 三段缺一不可；写不出「价值」的需求多半不该做 价值导向 |
| INVEST 原则 | 独立、可协商、有价值、可估算、足够小、可测试 | 六条全满足才算合格故事；不满足就先拆分 拆分检查表 |
| 故事点 vs 工时 | 点估相对复杂度与工作量，时估绝对耗时 | 点数不换算成天数（各团队速率不同）；点估抗估算偏差 点不等于天 |
| 规划扑克 | 全员同时亮牌估点，分歧大的条目各自陈述理由后再估 | 用讨论消灭理解偏差，防止资深者报数带节奏 消灭锚定 |
| 验收标准 | 每条故事配可验证的 Given-When-Then 条款 | 没有验收标准的故事不能进迭代 |
| 拆分技巧 | 按业务流程步骤、数据维度、接口先行等方式切小 | 目标一个迭代内能完成，单条以 2~3 天为宜 |
🔁 迭代仪式实践
| 名称 | 说明 | 要点 |
|---|---|---|
| 每日站会三问 | 昨天做了什么、今天计划做什么、有什么障碍 | 聚焦同步与求助，15 分钟封顶，问题会后单聊 15 分钟封顶 |
| 站会不是汇报 | 面向团队讲而不是面向领导讲，禁止逐人念流水账 | SM 引导大家围着看板讲卡片流动，讲障碍比讲成果重要 |
| 评审会要点 | 演示真实可用的增量，收集反馈而非走流程 | 演示环境提前备好；PO 当场确认是否达成验收标准 |
| 回顾会四问 | 继续做 / 停止做 / 开始做 / 尝试做，各收集若干条 | 每次只选 1~2 项落地，下个迭代验收效果 少改才落地 |
| Backlog Refinement | 每迭代固定 1~2 次梳理会，对顶部条目拆分与估算 | 约占团队 10% 工时；梳理跟上，计划会才不拖堂 |
| 迭代长度选择 | 一周反馈快、节奏紧，四周适合需求稳定期 | 新团队从两周起步；定下后不随意变更 |
📈 迭代度量
| 名称 | 说明 | 要点 |
|---|---|---|
| 燃尽图解读 | 剩余工作量随日期下降的曲线，与理想斜率对比 | 曲线长期平缓 = 障碍没消化；翘尾 = 最后赶工 看趋势不看单点 |
| Velocity 速率 | 团队每迭代稳定完成的点数，用于容量预测 | 只做团队自用排期；禁止跨团队比较、禁止当 KPI 当 KPI 必注水 |
| 周期时间 Cycle Time | 从开始处理某条到完成所花的天数 | 反映单条流动速度；优化 WIP 与阻塞即可缩短 |
| 前置时间 Lead Time | 从需求提出到交付的全程时间 | 客户视角的真实等待，比周期时间更贴近业务体感 |
| 累积流图 CFD | 各状态条目数随时间堆积的分层曲线 | 某层带宽变宽 = 该环节堆积成瓶颈，一眼定位卡点 瓶颈探测器 |
⚠️ 反模式清单
敏捷翻车很少是方法不对，多是执行走样：六个高频病灶各配一条可执行的纠正动作，对号入座。
| 名称 | 说明 | 要点 |
|---|---|---|
| 站会变汇报 | 表现：逐人对着领导念进度，15 分钟刹不住车 | 纠正：面向团队围板讲流动，障碍会后跟进 高频病灶 |
| 回顾不落地 | 表现：问题写满白板，迭代一忙全忘 | 纠正：改进项写进下一迭代 Backlog 占一个坑，下次回顾先验收上期改进，不验收等于没改 改进可验收 |
| 需求中途强插 | 表现：迭代中途插「紧急」需求，承诺形同虚设 | 纠正：走换入换出协议，等量置换并记录插单原因 |
| PO 缺位 | 表现：需求没人拍板，优先级三天一变 | 纠正：指定唯一 PO 并授予排序权，重要决策限时答复 |
| 为敏捷而敏捷 | 表现：仪式全开、站会机械执行，交付节奏依旧混乱 | 纠正：先改流动（WIP / 拆分）再调仪式，价值交付是唯一标尺 |
| 度量变武器 | 表现：速率被用于绩效排名，团队开始虚报点数 | 纠正：度量只用于团队自我改进，数据透明但不挂钩绩效 信任第一 |
🚦 迭代启动清单
计划会开完不等于迭代启动了：下面 6 项逐一过一遍，全打勾才算真正启动。启动阶段多花 30 分钟，能为整个迭代省下数天的返工与等待。
| 检查项 | 做法 | 达标标准 |
|---|---|---|
| 目标一句话 | 把迭代目标压缩成一句话，写在看板最上方 | 全员能脱口复述；说不出来就是没对齐 北极星上墙 |
| 容量核算 | 用团队平均速率扣减请假、会议、on-call 折算点数 | 承诺容量 ≈ 速率 × 0.8，给突发留缓冲 别按满血排 |
| 故事拆到 2 天内 | 任何超过 2 天的故事继续按流程步骤、数据维度切小 | 站会上每张卡每天都要有动静，卡住即暴露 小才能快 |
| 依赖与风险标注 | 跨团队联调、三方依赖、审批节点写进票并 @ 对应人 | 每条外部依赖都有责任人和期限，无悬空项 等待要留名 |
| 验收标准写进票 | Given-When-Then 条款直接写在票的描述里 | 评审会当场对标准，不靠事后口头约定 白纸黑字 |
| 对齐 DoD | 重申完成的定义检查单：代码评审、测试、文档、部署 | 差任何一项都不算完成、不计入速率 完成才计数 |
📉 流动效率提升动作
团队很忙但交付很慢，问题多半出在流动而非努力：5 个动作按性价比排序，从上往下逐个落地，每个都能直接压缩周期时间。
| 动作 | 具体做法 | 预期效果 |
|---|---|---|
| 限制 WIP | 从「进行中 ≤ 4」这类具体数字起步试行两个迭代，到顶停拉新卡，再按阻塞数据上下调整 | 在制品降下来，半成品不再无限堆积 少即是快 |
| 拆小任务 | 大于 2 天的任务继续切，切到一张卡一天能推进完 | 卡片天天流动，阻塞当天可见 粒度决定反馈 |
| 每日清阻塞 | 站会先过阻塞清单，超 1 天未解的升级到 SM / PO | 让「等人」浮出水面而不是泡在看板上 阻塞不过夜 |
| 减少在制品切换 | 一人一卡为理想；接新活前先问「有没有卡在评审、测试的旧活」 | 切换损耗趋近于零，完成率明显上升 收尾优于开工 |
| 度量周期时间 | 统计每条从开工到完成的日历天数，按周回顾趋势 | 管流动别管忙闲：人忙不等于货在动 看流动不看工时 |