全文约 3400 字，阅读约 8 分钟。
重点内容：敏捷研发没有过时，过时的是把它当仪式做的那批团队。我的判断是：Scrum 仍是主流，但真正的形态已经是敏捷加瀑布的混合，纯敏捷和纯瀑布都在退场。工具层要跟上这个变化。
敏捷研发现在过时了吗？
每过两年就有人问一遍。2026 年这轮问得更凶，因为 AI 写代码的速度让迭代周期看起来更短了，有人开始怀疑敏捷那套两周一个迭代的节奏是不是多余。
我的判断直接给：敏捷研发没有过时，过时的是那些把它当仪式做的团队。Scrum 到今天仍然是全球最主流的研发框架，这一点没什么可争的。但真正跑在生产环境里的敏捷，早就不是 2005 年那套教条了。混着瀑布跑，才是现在的主流形态。
这篇按时间线捋一遍敏捷这三十年的变化，然后说当下到底出了什么问题，最后落到工具该怎么做。
敏捷是怎么长出来的
敏捷不是凭空冒出来的概念，它出现的前提是瀑布失灵。
20 世纪 70 年代到 80 年代，软件开发基本照搬工程行业的做法：先做需求分析，再做设计，再编码，再测试，交付。这套流程在硬件和大型工程上很稳，搬到软件上就出了大问题。项目周期长，中途需求变了无法调整，验收往往拖到最后一刻才做，等到发现做出来的不是想要的，钱已经花完了。软件界当时管这个叫「软件危机」。
1990 年代初，几个人开始试别的办法。Jeff Sutherland 在一家叫 Etek 的公司带团队，第一次把 Scrum 这套做法用在了软件项目上，1995 年他和 Ken Schwaber 在 OOPSLA 会议上正式发表 Scrum，把这套做法公开。同一时期，Kent Beck 在 Extreme Programming 团队里搞出了极限编程，强调测试先行、结对编程、小批量发布。
2001 年是个关键节点。17 位软件行业的人在犹他州聚会，签了一份《敏捷宣言》。四个价值观，翻译过来是：个体和互动高于流程和工具；可工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。
有意思的是这份宣言的标题下面还有一句话：虽然 valuing the right-hand side 有价值，但我们更重视 left-hand side 的价值。这句话当年很多人没读懂，后来成了敏捷最容易被断章取义的地方。
2006 年，《Scrum 指南》第一版发布。之后这个文档一直在改：2010 年改过一次，2017 年加了三个目标，2020 年那次改动最大，把原来独立存在的「工件」改成了「工件加承诺」的组合，还去掉了 forecast 这个词，换成 commitment。2024 年那次修订是迄今最新的一版，语言更简洁，反复强调承诺这件事，把迭代计划明确成三个话题：为什么做这轮迭代、做什么、怎么做。
这三十多年里，敏捷从一个小众方法变成了行业默认选项，再到现在开始被重新审视。每一轮变化都指向同一个问题：怎么别让它变成表演。
当下的真实状态
先说数据面上的判断。Digital.ai 发布的第 18 版《敏捷状态报告》里，Scrum 仍然是选择最多的框架，包含 Scrum 的混合实践紧随其后，大型组织普遍用 SAFe 这类规模化框架把敏捷扩展到组织级。
另一个更明显的趋势是混合模式。国内项目管理领域的公开分析提到，2025 年采用混合模式的企业在交付准时率上的改善，明显高于只做单一敏捷的团队。这类数字来自厂商口径，我不敢当成硬结论，但方向上跟一线感受一致：硬件、结构、生产这些有明确交付节点的环节，团队最后都会把阶段门禁加回来，纯敏捷跑不下去。
所以「敏捷过时了吗」这个问题，问反了。真实情况是敏捷赢了，瀑布没死，两者在企业里分了工。
三个真问题
敏捷普及之后暴露出来的毛病，我认为是这三个最要命。
第一个是形式化。站会开成工作汇报，每人念一遍昨天做了什么，15 分钟变 40 分钟。迭代开完没有目标，只有一堆工单，没人说得清这轮迭代为什么值得跑。这不是团队不努力，是把 Scrum 当成了仪式清单。有咨询公司整理过类似案例：某个 40 人的软件公司跑了三年 Scrum，26 个迭代里只有 3 个有明确的迭代目标，其余都是一堆带截止日期的工单。
第二个是技术卓越被牺牲。为了赶迭代节奏，测试跳过、代码评审走过场、债务往后堆。短期看着交付变快了，半年后改一个功能要一周。敏捷本身不反对质量，2025 年行业讨论里技术卓越被反复提出来，就是这个问题已经普遍化。
第三个是把敏捷当成万能药。金融、军工、医疗这类有强合规要求的领域，硬套纯敏捷，出问题的时候没人担责。这类场景需要的恰恰是瀑布的东西：阶段评审、文档留痕、明确的验收点。
在中国的落地情况
说国内的情况，节奏比国外慢，但路径挺清楚。
第一阶段是互联网公司带起来的。2010 年前后，国内几家头部互联网公司开始引入 Scrum 和看板，那批团队规模大、迭代快，敏捷在这里验证了价值，也留下了「敏捷等于加班」的印象。
第二阶段是 2000 年代初开始的传统企业体系化建设。华为在 IBM 咨询帮助下引入 IPD，把研发流程和管理做重，这在当时是重大进步，也把国内大中型企业的研发管理底子打下来了。
第三阶段是 2018 年以后的敏捷转型。金融、制造、通信这些行业开始成规模推敏捷，原因很现实：业务变化太快，重流程跑不动了。人力上，CSM、ACP 这类认证体系也被大量采用，形成了一波持证的热潮。
现在的状况是，CMMI 这类过程改进体系和敏捷同时存在于大部分软件企业里。一个做外包的团队可能要过 CMMI 评估，做自有产品时又想跑敏捷，这不是矛盾，是企业同时有两类项目。国内企业实践里比较成熟的做法，就是按项目类型分开管。
还有一个绕不开的真实矛盾：老板要看甘特图和里程碑，团队想跑看板。这两件事在过去是对立的，现在的做法是给管理层一套看项目组合和进度的视图，给团队一套看迭代的视图，两边数据同源。
工具层：敏捷能不能落地，看工具
聊到这儿就得说工具了。敏捷研发项目管理能不能真正落地，很大程度上不取决于团队素质，而取决于工具有没有把该管的东西管住。
我把一个合格的敏捷研发项目管理工具应该满足的条件列一下。这几条也是我看工具时固定检查的。
第一，需求、任务、缺陷必须在一个池子里。分开管就会出现需求改了、缺陷没跟上、测试用例挂在旧版本上，最后追溯不回来。软件研发项目管理里这一条是底线。
第二，迭代管理要有燃尽图。只看完成数量会掩盖问题，燃尽图能看出哪个迭代实际烧超了、哪个是有意留的。
第三，测试用例要能挂到需求下面。这样需求变更时，用例的受影响范围能直接看出来，不用人肉对账。
第四，敏捷和瀑布要能共存。这是最重要的一条。同一套系统里，软件团队走迭代和看板，生产部门走 WBS 和甘特图，两边的项目在同一个列表里，管理层看同一张组合视图。这是很多工具做不到的，也是实践里最常卡住的地方。
第五，跨项目的数据要能汇总。一个产品经理同时管十几个项目，他需要的是组合健康度和风险预警，不是每个项目单独看。
拿这几条去筛，能剩下的工具不多。这也是我评估敏捷研发项目管理工具的固定清单，2026 年再问一遍这个问题，答案基本没变。
智序项目管理系统在敏捷研发上的做法是这样的：敏捷项目用敏捷模板，迭代规划、看板、燃尽图是内置的，迭代管理本身包含在终身免费版里，不限人数。缺陷和测试用例直接关联到需求，需求一改，关联关系跟着走。上面说的四条都有。
瀑布那边是企业版提供 WBS、甘特图、阶段门禁和评审。同一套系统里，敏捷项目和瀑布项目并行存在，流程由模板决定，成员权限和数据结构保持一致。软件研发项目管理里最难啃的一块就是这个：一套模板走敏捷，一套模板走瀑布，成员和项目都在同一个列表里，管理数据不用人工汇总。智序项目管理系统在这一点上的处理，是把差异收在模板层，不让团队分家。
AI 这块智序项目管理软件做的是两个具体功能：工作台上的进度偏差预警，AI 数据中心里的组合健康度、里程碑达成率和逾期工作项。前者解决的是项目经理盯不过来的问题，后者解决的是管理层看不清全局的问题。两个都是实际每天要用的，不是摆设。
怎么判断一个团队该用什么
最后说点具体的。
如果你判断自己团队适合敏捷，信号是这样的：需求每周都在变，交付物可以拆成两周一块的增量，客户愿意每个迭代看一次demo。这种情况直接上敏捷，不用犹豫。
如果你的项目有强监管要求、交付节点写死在合同里、或者硬件和软件深度耦合，那就该上瀑布，或者混合。别为了证明团队「先进」硬套敏捷，最后是合规部门和交付一起为难。
如果你的公司既有互联网式的软件团队，又有生产制造部门，那工具层面只有一条路：必须一套系统同时支持敏捷研发项目管理和软件研发项目管理的不同模板。智序项目管理软件的做法是敏捷模板和瀑布模板并存，差异收在模板里，数据收在同一处。分两套系统买，两边的数据永远对不上，管理层看到的报表永远是拼出来的。
结尾
敏捷研发没有过时。它的问题是太容易被做成样子货，而解决这个问题的关键不在多培训几个 Scrum Master，在工具能不能把目标、进度、质量这三样东西卡住。
智序 ORDR 项目管理软件在这件事上的取向很明确：把敏捷该有的迭代、看板、燃尽做进免费版，把瀑布该有的门禁和评审留给企业版，目的就是让企业不用为了「要不要上敏捷」这个问题先做工具选型。选型之前，先想清楚自己要跑哪几种模板。
2026 年要做的事其实就两件：一是把那些没目标的迭代补上目标，二是把工具换成能同时管敏捷和瀑布的。剩下的，交给团队自己跑。
想接着往下看，这儿有几篇相关的。敏捷研发方案页，迭代、看板、燃尽的具体配置都列了；瀑布研发方案页，WBS、甘特、阶段门禁那条线；Jira 替代方案，聊全流程和数据自主；智能制造项目方案，敏捷和瀑布并存的最典型场景。版本对比在 定价页。
如有侵权请与我们联系