敏捷研发

别再把故事“拆稀碎”了：信息浓度高，读者反而跑得快 去年我在给一个 SaaS 团队做内容诊断时，产品经理把一页需求文档摊到我面前。上面密密麻麻画了 14 个用户触点，每个触点旁边标注了 3-5 个细分场景，每个场景又拆出了 2-3 条故事线。他说：“我们把用户故事拆得特别细，每个分支都覆盖了，但转化…

PO不在现场，需求如何不跑偏 去年帮一个 60 人的SaaS团队做敏捷诊断，他们PO在深圳，研发中心在成都。前三个迭代的跑偏率，我指验收时发现“做出来的功能与原始需求意图存在实质性偏差”，高达 42%。一个功能平均返工 1.7 次。CTO 跟我说，每次 Sprint Review 都像开盲盒。我问他…

我们曾经以为，站会的问题出在“不会开”上。一群人站了四十分钟，各自念一遍昨天干了什么、今天打算干什么，像轮流播报的新闻联播，没人关心别人说了什么，也几乎没人提出任何真正需要团队解决的问题。Scrum Master 按了三次计时器，最后放弃了。会议室里的能量，从第二个人说话开始就在匀速流失。 这是我们…

引言：那个让所有人沉默的Sprint Review 去年第三季度，我坐在一家SaaS公司的Sprint Review现场，亲眼目睹了一场“集体表演式工作”的崩塌。产品负责人打开需求看板，三个迭代共127个用户故事，完成度不到40%，但每个故事的状态都是“已完成”。测试负责人站起来说了一句让我记到现在…

引言：我们连续三个 Sprint 都没能交付，问题不在代码，在等待 去年年底，我接手了一个已经在交付上“慢性失败”两个季度的产品组。表面症状非常统一：每个 Sprint 结束时，认领的用户故事大概只完成了一半；燃尽图永远是一条“前平后陡”的曲线；站会上大家说的话越来越短，气氛越来越沉闷。产品负责人以…

一、先说清楚一件事：我为什么不再迷信“快”这个词 2021 年，我亲眼看着一个 200 人的研发团队在三个月内“高效”地交付了一个新功能模块。迭代速度很快，每两周一个稳定的版本，燃尽图漂亮得像教科书。但上线后第三周，客户开始反馈严重的数据不一致问题。排查结果让所有人沉默：这个功能所依赖的基础数据模型…

做敏捷两年，最不该省的是回顾 去年年底，我在一个两百人规模的产品研发团队做敏捷成熟度评估，结果让我沉默了很久。各项数据都挺漂亮：需求吞吐量稳定、迭代交付准时率超过85%、测试自动化覆盖率也在持续提升。但有一个指标低得离谱，改进项闭环率只有12%。也就是说，团队在回顾会议上提出的改进计划，十件事里有将…

一、一个让我彻底放弃“估算总偏差”的真实时刻 2023年第三季度，我负责的一个产品线连续四个Sprint的估算总偏差都超过了40%。在回顾会议上，团队成员疲惫地坐在屏幕前，Scrum Master打开燃尽图，那条本该平滑下降的曲线在中段突然拉出一道刺眼的平直线。有人小声说了一句：“我们花在估算上的时…

一、先说结论：我们不是为了换而换 2024年第三季度，我所在的产品研发团队完成了一次彻底的工作流重组，从运行了三年半的Scrum模式切换到Kanban。这个决策在团队内部吵了整整三周，中间经历了两次投票、一次为期两周的并行试验，以及一次几乎导致核心开发离职的激烈冲突。 很多人以为我们又是一个“Scr…

一、核心结论在开头就说清楚 团队自组织是 Scrum 敏捷开发中最危险的一个承诺。 我见过太多技术管理者，尤其是那些刚从 CSM（Certified Scrum Master）认证课出来、热血沸腾的 Tech Lead，他们迫不及待地在团队里推行“自组织”，取消项目经理、淡化层级、鼓励每个人自主认领…