一、敏捷被玩坏了吗
「我们敏捷了」——很多团队嘴上说敏捷，实际是：站会变成了汇报会、迭代成了赶工期、看板只是好看的墙。敏捷不是一套流程模板，而是一组应对变化、持续交付价值的原则。
二、敏捷真正在解决什么
传统瀑布的问题是：需求变了，前面全白干。敏捷的核心假设是「需求一定会变，所以我们小步快跑、频繁验证」。它的敌人不是文档，是「长时间不交付可用软件」。
三、三个核心仪式（别走过场）
1. 迭代计划会（Sprint Planning）
- 从 backlog 挑本迭代能做下的（按优先级 + 容量）。
- 把需求拆成「做完即上线」的小颗粒。
- 团队自己估点，别由 PM 拍脑袋定 deadline。
2. 每日站会（Daily Standup）
只回答三句：昨天做了啥、今天做啥、有啥阻塞。不超过 15 分钟，不展开讨论，阻塞会后单聊。
3. 迭代回顾会（Retrospective）
最被忽视却最重要。问：哪些做得好、哪些要改、下个迭代试一个小改进。没有回顾，敏捷不会进化。
四、常见的六大误区
- 没有 Product Owner：需求谁都能提，优先级谁说了都不算，迭代乱成一锅。
- 迭代成了 mini 瀑布：设计一周、开发一周、测试一周，毫无增量。
- 估算当承诺：「估 5 天」被理解成「必须 5 天交」，于是加班造假。
- ** story 太大**：一个 story 跨两个迭代，永远「快好了」。
- 忽视技术债：只加功能不重构，速度逐迭代下降。
- 看板不更新：信息滞后，站会沦为猜谜。
五、度量什么才有用
- 交付速率（Velocity）：观察趋势，别跨团队横向比。
- 前置时间（Lead Time）：从需求到上线要多久，越短越灵敏。
- 逃逸缺陷率：上线后发现的 bug 占比，反映质量。
- 累计流图（CFD）：看在制品是否堆积，瓶颈在哪列。
六、落地建议
- 小团队先从「双周迭代 + 看板 + 回顾会」三件套起步，别全套照搬。
- 固定节奏比工具重要：时间盒（timebox）守住，迭代长度别随便改。
- 给团队「说真话」的安全感，回顾会不追责。
- 敏捷教练（SM）要保护团队不被外部打断，而不是催进度。
七、结语
敏捷不是银弹，它是一种「承认无知、用反馈逼近正确」的谦逊工作法。落地得好，团队会感觉「每一步都踩在实地上」；落地得差，只是把混乱包装成了仪式。关键不在 Scrum 证书，在团队是否真的在持续学习和交付。