敏捷研发

上周三早上 9：02，我参加了一个让我彻底决定写这篇文章的站会。21 个人，轮流报“昨天做了什么、今天打算做什么、有没有阻塞”，耗时 47 分钟。站会结束后，产品总监拉着架构师在走廊里又开了 15 分钟的小会，因为站会上“暴露的问题”根本没时间讨论。我在旁边算了笔账：21 人 × 47 分钟 = 1…

一、先给结论：这不是一道“对错题”，而是一道“站位题” 我经历过一个非常典型的场景。 某年Q3，我作为Scrum Master接手了一个120人规模的金融科技产品团队。当时团队正在进行敏捷转型，Sprint周期设定为两周。前3个迭代，每个Sprint的“需求冻结率”不到30%。什么叫冻结率？就是Sp…

引言：一个真实场景，把我们逼到了墙脚 去年第四季度，我主导的一个 SaaS 产品迭代差点崩盘。不是技术问题，不是资源问题，而是紧急需求像拳头一样，一拳一拳砸进我们的 Sprint。最夸张的一周，原定 43 个 Story Points 的迭代容量，被 6 个“最高优先级”的紧急插入项挤占到只完成了 …

一、测试左移半年，我们的迭代速度反而下降了 12% 2023 年第三季度，我所在的团队做了一个决定：全面推行测试左移。当时的背景并不复杂，每个迭代末期，测试团队的加班时长突破了人均 42 小时，而仍然有 4 个严重缺陷漏到了生产环境。产品负责人拍着桌子问：能不能让测试早点介入？ 于是我们开始了左移。…

一、先说清楚一件事：流动度量不是“更准的预测工具”，而是“放弃预测后的替代方案” 大多数研发管理者第一次听说“流动度量”时，问我的第一句话是：“这东西能让我预测得更准吗？” 我的回答让他们很失望：不能。流动度量的核心价值不是让预测更精准，而是让你认识到，在知识工作领域，精确预测本身就是一种幻觉，然后…

一、一个反常识的结论：越短的计划会，越能保护Sprint的质量 2024年第四季度，我在PingCode内部做了一次针对92个中大型研发团队的敏捷实践审计，结果有一个数据让我和团队沉默了很久： Sprint计划会时长超过90分钟的团队，其Sprint目标达成率平均只有61%；而控制在30到45分钟以…

“我们团队的回顾会，很像一场集体冥想。”去年我在一家SaaS公司做敏捷咨询时，研发总监这样形容他们的回顾会。每个迭代结束，十几个人围坐一圈，Scrum Master问“这个迭代哪里做得好？”，沉默；“哪里可以改进？”，更长的沉默。唯一出声的环节，是大家用手机给会议满意度打分：平均2.1分（满分5分）…

一、核心结论：报告改的不是格式，是活着的证据链 我做了快十年研发管理咨询，最常被问到的问题就是：“我们从瀑布转了敏捷，但老板/客户还是要求每周交项目报告，这报告到底怎么写？” 我的答案一直很明确：你不需要改报告格式，你需要改的是“什么叫项目进展”的定义。 瀑布模式下的项目报告本质上是合规文件。它回答…

一、先讲清楚一个反常识的核心结论 绝大多数技术管理者嘴上说“依赖管理很重要”，但真到了执行层面，用的还是微信群喊话、邮件抄送、每日站会口头确认三件套。我们团队在2022年做过一次内部审计，翻看了连续四个迭代的延期工单，结果发现83%的延期根因不是技术难点没攻克，而是被其他团队卡住了。接口没ready…

一、我们错了：故事点把复杂度变成了一个可以讨价还价的数字 2024年第三季度，我们在 PingCode 内部对 200 人以上的产品线做了一次深度复盘。结果让我们很难堪：在 Sprint 规划会议中，团队平均花费 47% 的时间在故事点估算上，而真正讨论“这个需求到底解决什么问题”的时间，只有 18…