先说我待过的两个团队，一个Scrum一个Kanban
2019年我在一家做跨境电商ERP的公司，团队12个人，算上产品、开发、测试。我们老老实实跑Scrum，2周一个Sprint。头三个月还行，后来需求方像疯了一样改需求。我翻了一下Jira记录，一个Sprint内平均有7.3个需求变更，Sprint Goal基本是摆设。每次回顾会就变成了甩锅会，产品怪开发慢，开发怪产品乱改。后来我跳槽到一家做SaaS的，团队6个人，用Kanban，没有Sprint，直接按列流动。发布频率从每月1次变成每周2.3次。但问题也来了：没有固定节奏，大家不知道什么时候该收尾，技术债越堆越多。
对比下来，Scrum适合需求相对稳定、团队想要固定节奏的；Kanban适合需求碎片化、支持型或者运维型团队。但大多数团队其实介于两者之间，硬套任何一个都难受。我见过一个20人的团队用SAFe，搞了三个层级，结果每天站会要开1小时，最后大家偷偷在会议室吃早餐。
深度对比：Scrum、Kanban、Scrumban到底差在哪
别信那些咨询公司给的漂亮矩阵，我按实际用下来的感觉列几个硬指标。Scrum典型Sprint是2周，每日站会15分钟，Sprint Review 1小时，Retro 45分钟。角色有PO、SM、Dev Team。度量用故事点和速度。Kanban没有Sprint，站会可以每周2次，每次10分钟。角色没有强制，度量用Cycle Time和WIP限制。Scrumban就是混合，保留Sprint但用WIP限制，我们试过，Sprint长度改成1周，WIP设为3。
具体数字：我们团队WIP限制设为3的时候，平均Cycle Time从6.2天降到3.8天。但WIP设太死，有人闲着也不拉新任务，反而浪费。后来改成动态WIP，初始值=团队人数×1.5，比如6个人就设9。故事点估算更坑，我们团队速度从32点降到18点，因为大家发现估点没意义，干脆往大了估。所以我的建议是：如果团队小于8人，别用故事点，用任务数或者直接数卡片。
| 维度 | Scrum | Kanban | Scrumban |
|---|---|---|---|
| 迭代长度 | 1-4周，通常2周 | 无 | 1周 |
| 变更策略 | Sprint内不变 | 随时可加 | Sprint内限制WIP |
| 会议 | 站会、计划、评审、回顾 | 站会（可选） | 站会+回顾 |
| 度量 | 速度、燃尽图 | Cycle Time、吞吐量 | 两者混用 |
| 适合场景 | 产品需求较稳定 | 运维、支持、bug流 | 需求半稳定 |
用户常搜的问题：站会说什么？需求变更怎么办？
我搜过“敏捷开发站会说什么”，答案全是三个问题。但实际执行，你让每个人站着回答三个问题，一圈下来15分钟打不住。我们试过走查板子的方式：从右往左，每个人只说自己卡在哪，不超过2分钟。站会从40分钟压到12分钟。步骤是：第一步，先别买Jira，用白板+便利贴跑两周。第二步，测量四个数：需求变更频率、发布频率、缺陷逃逸率、团队满意度（1-5分）。如果变更频率>3次/周，别用Scrum，用看板。如果发布频率<1次/月，先搞CI/CD，别谈敏捷。
第三步，回顾会别只吐槽，每次只改一个流程，下个迭代验证。我们连续改了8个迭代，才把部署时间从4小时降到25分钟。第四步，站会超时怎么办？设一个计时器，到点就停，没说完的会后说。别小看这个，我们试了之后，会议总时长每周少了3.5小时。
一个反常识的观点：敏捷不是快，是早失败
我觉得敏捷开发最大的谎言是“自组织团队”。在大多数公司，团队根本没有权力决定做什么，只能决定怎么做。所以与其追求自组织，不如追求“透明化”。把所有的阻塞、依赖、技术债都可视化，让管理层看到。另一个观点：敏捷不是快，是早失败。我们做过一个实验，两个团队做同一个需求，A团队用Scrum，B团队用瀑布。A团队第3天就出了可演示版本，虽然只有30%功能，但发现了3个关键假设错误。B团队第20天出完整版，结果需求方向错了，重做花了15天。所以敏捷的价值在于反馈周期，不在于速度。
如果你团队正在搞敏捷，先别急着买工具，先问三个问题：谁决定优先级？多久能拿到用户反馈？阻塞问题平均多久解决？答不上来，什么框架都没用。我现在的做法是：每两周跟团队吃一次饭，饭桌上问他们“最近什么最烦”，比回顾会管用。