“这事儿都有什么风险？”

“这事你还需要什么资源？”

“什么时间你预计可以完成？”

这是我初入IT Infra项目实施管理领域时，最常被上级追问的三个灵魂问题。彼时的我，只觉得管理者专业至极，句句直戳项目的核心。在尚未接触敏捷思维模式之前，我也下意识地照搬这套话术，对团队成员灵魂三问，自我感觉这是项目管理的全部要义。

直到2022年我加入一家外企，这套根深蒂固的管理沟通逻辑，被彻底颠覆了。在项目实战中上演了敏捷项目管理的“倒反天罡”，让我真正读懂了敏捷的真谛——从来不是照搬方法论，而是学用相融、业务共生，要敢于挑战“最佳实践”、大胆尝试新的实践。

我接手的第一个项目，是一个陷入混乱、仓促上线的VDI（Virtual Device Infrastructure）项目。简单来说，就是搭建云端电脑终端，让员工可通过任意设备接入公司内网应用系统。当时的项目状况百出：平台漏洞频发、运行极不稳定，直接导致业务部门负责人对项目极度不满，项目后续推进举步维艰。

更为棘手的是，项目没有留存任何配套文档，核心开发团队分布在海外，沟通成本高。该项目属于全球通用解决方案在中国区落地，需要针对性适配国内业务场景与网络环境，难度可想而知。

按照大多外企一贯的组织惯例，中国区作为本地团队，向来只是全球方案的被动执行者：只需要按部就班落地Global现成的Solution即可。这是大家默认的协作规则，最安全、最稳妥、按照传统流程行事。从来没有本地团队敢于反过来主导、打破层级壁垒，实现带着全球团队调整方向的逆袭先例，

那时候的我，刚刚接触敏捷不久，对敏捷的认知还停留在表面上。仅懵懵懂懂知晓Scrum、Sprint、PBI、Time-boxed这些专有名词，还算不上真正的入门。 我记得有一天，前任项目经理抛给我两个问题：
“这个项目一团乱麻，你打算怎么推进？”

“如果用敏捷思路，你每两周团队能给业务端交付什么成果？”

这两个问题直接点醒了我：

第一个问题，我还能凭着粗浅的认知勉强应答：“我们原本就有两周一次的评审会议，刚好和Scrum模式实践(Pattern) 中2周一个Sprint的周期契合，直接用Scrum框架落地项目，应该可行。” 当时我暗自窃喜，靠着这点皮毛知识，侥幸“装成” 敏捷管理的专业人士。

但是第二个问题，我瞬间哑口无言。我满心琢磨着只是修复漏洞、稳定平台，从未考虑过迭代交付、价值落地的真正含义。敏捷不是纸上谈兵的术语堆砌，而是要在实践中边学边用、以用促学。这次“露怯”，激发了我深耕敏捷项目管理的决心，开启了我的Scrum实战进阶之路。

巧合的是，我的Scrum学用之路，刚起步就迎来了绝佳的实践契机——该项目VDI恰逢云机房迁移与Win11系统升级同步推进。我心里笃定：“这绝对是改变项目现状、践行敏捷的最好机会。”

作为中国区唯一的对接人，我顺理成章地承担起国内需求梳理与落地推进的核心职责。我没有再遵循“本地执行全球方案”的旧规矩，而是贴近中国业务实际场景；专注国内物理笔记本配置、原有VDI使用痛点、业务端真实的使用诉求，一步步梳理出了第一版最小有价值的产品待办列表（PBI）。把模糊的项目诉求、本土化的适配需求，拆解成可落地、可评估、可迭代的细化任务。

正是这份立足本土业务的PBI，让全球VDI产品负责人（PO）看到了中国区落地的核心价值，也彻底打破了“全球定方案、本地只执行”的固有模式，不仅给予了充分信任，还专门为项目调配了4名DevOps团队成员支持项目推进。这便是我所说的“倒反天罡”：原本本该被动落地全球方案的中国本地团队，凭借贴合业务的敏捷实践，反过来主导方案适配方向，带着全球团队围绕中国业务需求调整节奏、推进迭代，彻底扭转了本土团队的协作定位，这正是业务敏捷的核心力量——一切以业务价值为核心，打破层级与地域壁垒，让适配业务的方案落地，而非僵化遵循计划和执行既定规则。

接下来的团队协作，更坚定了我践行敏捷的信心：这4名来自海外的团队成员，全都具备成熟的敏捷实战经验，对于每日站会（Daily Standup）的Time-boxed机制、迭代节奏全然接受，这是项目高效推进的基础；反观国内临时协作的团队，大多还停留在传统项目管理认知里，觉得项目就是按部就班执行计划，对敏捷迭代、快速响应的理念没有概念，也不敢打破既有规则去大胆实践。

在VDI新平台组件落地实施过程中，我深刻地领悟到：脱离业务的敏捷，只是无源之水；没有体验实践的敏捷理论，永远只是空中楼阁。平台好不好用、漏洞有没有解决、适配是否到位，从来不是开发团队说了算，而是要靠业务团队真实的使用的快速反馈来验证，检视和调整。这是业务敏捷的核心——让业务深度融入项目的全流程，让敏捷方法服务于业务落地。

同时，我们快速组建了内部业务QA团队，专门负责功能测试、易用性反馈与问题自报。但两个团队的核心目标存在差异：开发团队聚焦功能迭代与问题修复，业务QA团队聚焦体验反馈与需求提报，若混为一个团队推进，极易出现目标混乱、效率低下的问题。

基于Scrum团队管理逻辑，我们将两支队伍拆分为两个独立的Scrum Team，各自遵循迭代周期开展工作；同时，定期召开Scrum of Scrums（SoS）会议，把SoS作为跨团队同步测试反馈、传递新增业务需求、对齐项目目标的核心纽带，彻底打破团队壁垒，让业务诉求彻底融入到敏捷项目执行的每一个环节。

在这里，我也想对正在学习敏捷、刚接触敏捷的同学分享一句密钥：“不要害怕、大胆去试！”我猜测，很多人和我当初一样，刚接触Scrum，只懂术语、没有实践，总担心自己不够专业、怕做错、不敢打破原有的游戏规则。结果是一直停留在学习阶段，不敢落地到实际工作中。但敏捷的核心从来不是完美的理论，而是小步快走、快速试错、随时调整，敏捷本身就允许我们在迭代中优化方向，在实践中补齐认知。

哪怕你只懂一点点Sprint、PBI的基础概念，哪怕你刚了解Scrum框架，都可以结合工作场景大胆尝试。不用追求一步到位，不用纠结流程是否百分百标准，把学习融入工作，在工作中验证敏捷方法。就像我们在实践中打破常规、实现“倒反天罡”一样；正是敢用敏捷思路梳理业务需求，敢于带领全球团队迭代调整，才让混乱的项目重回正轨，才让业务敏捷真正发挥价值。

这段经历让我领悟到敏捷的真正魅力：

1. 敏捷项目管理不是先学透再应用，而是边学边用、工作与学习深度融合，在项目实践中理解Scrum框架的精髓，在迭代推进中优化管理方法；

2. 真正高效的敏捷，必然是业务敏捷，以业务价值为核心导向；

3. 怀揣勇气，打破固有流程与层级偏见，大胆践行敏捷理念，放下“怕出错”的顾虑，小步快走、围绕目标随时纠偏；

这是我们每一个敏捷学习者和实践者最该坚守的初心。

作者: Roc Xie (CSP-SM)

审核: Jim Wang (CST)