软件工程专业的课堂上，“瀑布模型”“CMMI 流程” 是标配。学生被训练成 “按文档写代码的机器”：需求分析写 PRD，设计阶段画 UML，编码严格遵循编码规范，测试走流程找 BUG。但当他们进入互联网公司，面对 “需求天天变、两周一个迭代” 的敏捷开发，直接陷入崩溃 —— 这种 “流程化” 培养模式，正在批量生产 “敏捷开发的叛逆者”，抱怨需求不靠谱，却不懂如何用敏捷思维拥抱变化。
被 “流程” 锁死的创新力
某高校软件工程课程，用 CMMI 五级标准设计培养方案：从需求管理到配置管理，每个环节都有严格文档要求。学生做项目，先花两周写需求文档，再花三周画架构图，编码时发现需求不合理，老师却说 “按文档来，流程不能变”。
企业里，这种 “流程依赖症” 让毕业生水土不服。某互联网公司研发总监吐槽：“招个软件工程的，需求变更时只会说‘不符合流程’，却不懂用用户故事地图梳理需求；迭代开发时，还在坚持写详细设计文档，拖慢整个团队节奏。”
教育界的 “流程至上” 逻辑，忽略了软件工程的本质。软件工程是 “用工程化方法解决软件问题”，核心是 “灵活应对变化”，而非 “死守流程文档”。但课程把 CMMI 等流程框架当 “金科玉律”，培养出的学生，遇到敏捷开发的 “快速试错、持续改进”，本能地抵触 —— 觉得需求频繁变更 “不专业”，却没意识到这是互联网产品迭代的常态。
实验室项目与真实敏捷的 “错位”
高校的 “软件工程项目”，和企业敏捷开发完全是 “两个世界”。学生做的 “图书管理系统”，需求明确、周期固定，按瀑布模型走一遍流程就能交差；而企业的敏捷项目，需求模糊、变化频繁，需要天天和产品经理对齐，用最小可行性产品（MVP）快速验证。
某科技公司新人适应期数据：软件工程专业毕业生，平均需要 2 个月克服 “流程依赖”，学会用敏捷看板、用户故事地图等工具。更尴尬的是，那些非软件工程专业、但有编程经验的开发者，反而能更快融入敏捷团队 —— 因为他们没被 “流程框架” 束缚，更懂 “解决问题优先”。
重构培养：让流程服务于敏捷
软件工程教育需要重塑逻辑：流程是工具，不是目标。顶尖 IT 企业的软件工程实践，早已从 “流程驱动” 转向 “价值驱动”。高校应减少对 CMMI 等重型流程的灌输，增加敏捷开发、DevOps 等实战内容。
对学生而言，别把 “流程合规” 当能力。多参与真实敏捷项目，感受 “需求快速迭代、团队紧密协作” 的节奏；学习用用户故事梳理需求，用测试驱动开发（TDD）保证质量，用持续集成 / 持续部署（CI/CD）加速交付。真正的软件工程能力，是 “用最适合的流程，解决当前的问题”，而非 “拿流程当借口，逃避变化”。
软件工程的价值，在于 “用技术创造价值”。当高校还在训练学生 “按流程写文档” 时，企业要的是能 “在敏捷节奏中交付价值” 的开发者。这场教育与产业的脱节，终会推动培养模式变革：让流程服务于敏捷，让学生学会拥抱变化。