案例分享|当Scrum沦为“精致的”形式主义
引言：那块“完美”却毫无生机的Scrum板
我还清晰地记得多年那个下午，我走进一家国际顶尖通信设备公司的“敏捷作战室” ，墙上挂着一块巨大的电子Scrum板: 泳道清晰，用户故事卡片五彩斑斓，燃尽图平滑下降，一切都显得那么 “井然有序” 、 “敏捷高效” 。团队的Scrum Master正意气风发地向来访的领导介绍他们 “教科书般的” Scrum实践。
然而，当我与一线工程师私下交流时，听到的却是另一番景象：
“站会？就是轮流向经理汇报昨天干了什么，今天准备干什么，谁敢说自己有障碍，不是显得自己能力不行，就是给领导添麻烦。”“迭代？软件团队的迭代跑得飞快，但我们的硬件板卡三个月才能出来一版。软件做的东西全是在模拟器上跑的，一到真实环境，bug多到改不完。”“故事点和速度？哈，那已经成了我们团队和隔壁团队’军备竞赛’的数字游戏了。月底为了凑够Velocity，我们就把一个大需求拆成十个小卡片，看起来做了很多事，其实呢？”
那一刻，我深刻地感受到了一种“精致的形式主义”所带来的寒意。这家公司投入了巨额资金进行敏捷转型，但最终，敏捷的“魂”——那种拥抱变化、持续交付价值、以人为本的内核，却消失得无影无踪。
这个故事，在今天中国的许多高科技企业，尤其软硬件强耦合、系统复杂度极高的领域，正在反复上演。本文将结合我在通信产品研发中的真实见闻，深度剖析敏捷实践是如何一步步陷入“形式主义”陷阱的，重点拆解站会疲劳、迭代空转、KPI异化这三大典型症状，并最终尝试给出如何寻回敏捷“心法”的破局之道。
一、一个案例的复盘：“5G基站”的敏捷幽灵
为了让大家有更切身的体会，我们先来完整复盘一个我深度参与过的、典型的敏捷转型失败案例，我称之为“‘5G基站’的敏捷幽灵”。
背景：
这是一家在5G时代占据技术高地的通信设备巨头。其核心项目是研发一款全新的、具备革命性功能的5G微基站。该产品软硬件高度集成，涉及射频、基带、传输、网管等多个技术领域，由超过10个团队、近200人并行开发。为了应对5G市场的瞬息万变，公司高层决定引入 “原教旨主义” 的Scrum框架。
- “完美” 的敏捷导入：
公司聘请了外部敏捷教练，对所有团队进行了为期一周的Scrum封闭培训。每个团队都配备了专职的Scrum Master和Product Owner。他们采用了标准的两周一个Sprint的节奏，并严格执行所有Scrum事件。
- 崩坏的迹象：
第一阶段（1-3个月）：蜜月期的假象
初期，一切看起来都很美好。团队士气高涨，Jira上的任务卡片飞速地从“To Do”移动到“Done”。在每次Sprint Review上，他们都能在模拟环境中演示出炫酷的UI界面和功能逻辑。管理层看到报表和Demo，感到非常满意，认为敏捷转型取得了初步成功。
第二阶段（4-6个月）：依赖的“地雷”开始引爆
问题首先在底层软件和硬件团队中暴露。
●硬件团队的困境：对于FPGA和芯片设计团队来说，他们的工作周期天然就是以“月”甚至“季度”为单位的。流片一次需要三个月，PCB打样和制作需要一个月。让他们按照两周的节奏交付一个“可工作的增量” 几乎是不可能的。于是，他们的 “Sprint” 变成了将一个长周期的瀑布任务，强行切割成一个个两周的 “伪任务”。
●软件团队的“空转”：基带处理软件团队，他们的代码强依赖于特定的处理芯片和物理层协议。在硬件就绪之前，他们只能基于一份随时可能变化的硬件Spec文档进行开发和单元测试，实际上是 “在模拟器上编译通过” ，离真正的 “可工作” 相去甚远。这就是典型的 “迭代空转” ——团队很忙，燃尽图很好看，但交付的价值被锁在了一个无法验证的 “黑箱” 里。
第三阶段（7-9个月）：系统集成的“审判日”
当第一版硬件单板终于千呼万唤始出来，系统集成测试开始了。这本应是敏捷成果的展示会，却变成了一场灾难。
●接口的噩梦：软件团队基于旧版Spec开发的驱动程序，与新硬件的寄存器地址完全对不上。
●性能的鸿沟：在模拟器上运行流畅的算法，在真实的硬件资源（内存、CPU主频）约束下，性能下降了几个数量级，根本无法满足协议要求。
最终，本应小步快跑、持续集成的敏捷开发，退化成了一场长达三个月的、痛苦不堪的“瀑布式集成会战”。项目延期超过半年，团队士气跌入谷底。
二、深度剖析：僵尸敏捷的三宗“罪”
“5G基站” 的案例并非孤例。它集中体现了敏捷实践在复杂产品研发中，最容易犯下的三宗 “罪” ，它们将充满活力的敏捷躯体，变成了行尸走肉般的 “僵尸敏捷” （Zombie Scrum）。
- 第一宗罪：站会疲劳——从“作战同步”到“灵魂拷问”
敏捷的初心：每日站会的目的极其单纯——不超过15分钟，团队成员互相同步进度、协调配合、暴露障碍，以便快速调整当天的“作战计划”。这是一个服务于团队的内部沟通机制。
异化的现实：
1） “汇报会” ：在强层级文化的组织里，站会迅速演变为向领导（通常是潜伏在团队中的项目经理或部门经理）的每日汇报。每个人发言时，眼睛都看着领导，关心的不是如何与同事协作，而是如何让自己的 “汇报” 听起来更漂亮。
2） “批判会” ： “你昨天为什么没有完成计划的任务？” 、“你说的这个障碍，为什么不早点想办法自己解决？” 当这样的质问出现在站会上时，它就成了变相的“每日绩效考核”。从此，再也无人敢暴露问题，“一切顺利”成了标准答案。
3） “超时马拉松” ：由于变成了汇报和问题解决会，15分钟的站会轻松拖到半小时甚至一小时。成员们站得腿脚发麻，心里却想着 “赶紧结束，我好回去干”，会议效率极低。
站会的质量，是衡量一个团队心理安全感的“晴雨表”。当站会变得形式化、令人疲惫时，根源不在于会议本身，而在于组织文化。一个健康的站会，应该是轻松、聚焦、能量满满的，它是一个团队每日冲锋前的“集结号”，而不是审判台。
- 第二宗罪：迭代空转——在“伪增量”中制造繁忙的假象
敏捷的初心：每个迭代（Sprint）的核心产出，是一个“潜在可交付的产品增量”（Potentially Shippable Product Increment）。这意味着，这个增量是集成的、可验证的、高质量的，并且真正为产品的最终形态增加了可感知的价值。
表现一：不同步的节奏导致的“硬件之困”与“软件之盲”
●硬件团队的困境：他们被强行塞进两周的Sprint盒子里。对于需要三个月才能流片的芯片设计团队，他们的“Sprint任务”变成了“完成15%的逻辑设计”这类无法独立验证的“伪任务”。
●软件团队的“空转”：他们在模拟器里“奋笔疾书”，每个Sprint都能交付大量功能。但这些功能是建立在对硬件行为的“假设” 之上的空中楼阁。
这种脱节的根本原因，是用一种单一的、为纯软件设计的敏捷节奏，去生硬地套用在工作属性和周期完全不同的多类型团队上。这违背了敏捷“因地制宜” 的精神，是一种典型的 “拿着锤子看什么都是钉子” 的教条主义。
引入“同步但异步”的开发节奏：
我们不能强求所有人的步伐完全一致，但必须确保他们在关键节点上能够“对上表”。
-
建立一个宏观的“规划间隔”（Planning Interval, PI）：借鉴SAFe规模化敏捷框架的思想，设定一个更长的、统领全局的规划周期，明确未来一个季度的共同目标，并将跨团队的依赖关系作为核心议题进行梳理和承诺。
-
允许团队内部的“异步迭代”：在这个大的PI框架内，允许不同团队采用适合自己的节奏。
软件团队可以继续采用两周的Sprint。硬件团队则可以采用基于里程碑的Kanban模式。他们的工作流不是时间盒，而是状态流（如：设计中 -> 评审中 -> 布局中 -> 打样中 -> 就绪）。他们的关键里程碑被所有软件团队所知晓。
3.设定强制的“系统同步点”：在PI内，设置几个固定的、不可动摇的“系统集成与演示日”（System Demo）。在这一天，所有团队必须将他们现阶段完成的成果集成到主干上，并在最接近真实环境的平台上进行端到端的业务场景演示。
表现二：“集成审判日”的降临
当一个项目累积了半年的“集成债” 之后，指望一次性还清是不现实的。缺乏一个共同的、有意义的、包含集成的“完成的定义”（Definition of Done, DoD）。
打造“集成优先”的文化和技术基础设施：
- 锻造一份“系统级DoD铁律”：这份DoD应由所有团队共同制定，并由系统架构师或一个专门的“系统团队”来捍卫。一份强有力的DoD可能包含：
●代码已合并到主干分支。
●单元测试覆盖率不低于80%。
●已在最新的硬件在环（HIL）仿真平台/FPGA原型上集成并通过。
●关键的端到端场景自动化测试已通过。
●相关文档（接口、配置）已更新。
一个用户故事，只有满足了所有这些条件，才能被标记为“Done”。
- 组建“系统团队”或“集成先锋”：对于大型复杂项目，可以考虑设立一个专门的系统团队。他们不负责开发具体的功能，而是负责构建和维护自动化测试框架、CI/CD流水线以及那个宝贵的“早期集成平台”。
第三宗罪：KPI异化——当“速度”成为“价值”的敌人
敏捷的初心：速度（Velocity）、故事点（Story Point）等是敏捷团队用来进行估算和容量规划的内部工具，绝非绩效考核指标。它的作用是帮助团队预测在下一个迭代中大约能“吃下” 多少工作，从而做出更靠谱的承诺。
异化的现实：
1.“速度竞赛” ：管理层将Velocity作为衡量团队生产力的 “金标准” ，并进行跨团队排名。这直接导致了团队间的恶性竞争和 “故事点通胀” 。团队不再关心交付的质量和价值，而是想方设法在数字上做得更好看。
2.“个体绩效量化” ：更有甚者，将故事点分解到个人，考核每个工程师每个迭代完成了多少点数。这彻底摧毁了团队协作，每个人都倾向于抢那些 “点高事少” 的活，而对于需要多人协作攻关的难题则避之不及。
●对产出指标（Output Metrics）的过度迷恋，是管理者在不确定性面前寻求控制感的体现，但这是一种有害的幻觉。我们必须将管理的焦点从“团队有多忙”（Output）转移到“团队创造了多少价值”（Outcome）。
●拥抱成果指标（Outcome Metrics）：你的团队这个迭代交付的功能，是否让产品的“用户活跃度”提升了？是否让系统的“崩溃率” 下降了？这些面向业务和客户价值的指标，才是指引团队前进的 “北极星” 。
将Velocity归还团队： Velocity是团队的“私有财产”，管理者应该信任团队会用好它。领导者的职责是创造环境、移除障碍，并和团队一起定义并关注那些真正重要的成果指标。
三、寻回敏捷“心法”：通信行业的破局之道
看清了陷阱，我们更需要找到出路。在通信这类复杂产品领域，简单地喊“回归敏捷本源”是苍白的。我们需要结合行业特点，修炼真正的敏捷“心法”。
心法一：从“命令与控制”到“服务与赋能”——重塑领导力
敏捷转型的成败，70%取决于领导力转型。管理者必须完成从“监工” 到 “园丁” 的角色转变。
●培育心理安全：领导者要公开表彰那些勇敢暴露问题、甚至承认失败的团队和个人。在回顾会上带头反思自己的决策失误。只有当说“我不知道”和“我需要帮助”是安全的时候，真正的透明和协作才可能发生。
●授权边界：清晰地定义团队的目标（Why）和边界（Constraints，如预算、合规要求），然后放手让团队去探索如何达成目标（How）。不要再介入团队的日常任务分配和技术细节决策。
心法二：从“割裂的冲刺”到“同步的节奏”——系统级规划与集成
在软硬件强耦合的环境中，强求所有团队都用一个两周的节奏是不现实的。我们需要在顶层引入一个更大的、能够协同所有依赖的节奏。
●引入规划间隔（PI）：这是规模化敏捷框架（如SAFe）中的核心概念。我们可以设定一个更长的规划周期，比如一个季度。在每个PI的开始，所有相关团队（软、硬件、测试、系统）共同参与一个为期1-2天的 “PI规划会议” 。
●建立“系统集成与演示”的固定节奏：在一个PI内，即使各个子团队的迭代节奏不同（软件两周，硬件一个月），但必须定义一个固定的、不可动摇的“系统集成点”。
心法三：从“功能的工厂”到“价值的实验室”——拥抱假设与度量
敏捷的精髓在于通过快速反馈来学习和调整。因此，我们交付的每一个功能，都不应被视为“任务的终结”，而应被看作是“一个待验证的价值假设”。
定义“假设-实验-度量”卡片：在需求设计阶段，就要求产品负责人（PO）写清楚：
●我们相信（假设）：通过实现“某个功能”。
●将会为[某类用户]带来“什么价值”。
●我们通过度量“某个指标”来验证它。
总结：从“做敏捷”到“是敏捷”
回到开头的那个场景，那块“完美” 的Scrum板，正是 “做敏捷” （Doing Agile）的极致体现——拥有敏捷所有外在的形式。但真正的敏捷，是 “是敏捷” （Being Agile）——是将敏捷的价值观和原则内化于心、外化于行的一种状态。
对于身处通信行业这样“重型”领域的我们来说，敏捷转型之路注定不会平坦。我们不能盲目照搬互联网行业的“轻模式” ，而是要在理解敏捷核心 “心法” 的基础上，因地制宜，创造性地解决软硬件依赖、系统集成等核心矛盾。抛弃那些 “精致的” 形式主义吧，让我们回到敏捷的起点，关注人与人的互动，胜过流程与工具；关注可工作的软件和硬件，胜过详尽的文档。这才是敏捷之道。
文章来源于才聚学员原创