在华为干过几年项目经理（PM）的，都懂一个理儿：别试图用 PPT 的排版去框住复杂的业务混沌，也别指望先拍脑门再调代码。敏捷不是那种让你坐在会议室里听老板念 PPT 的会议型管理，它是把“人”重新武装起来的过程。
那会儿我们认定敏捷就是敏捷开发加上看板，那绝对是拜偶像供的。目前的敏捷，核心实际上是让业务方认定你是在帮他们干活，而不是在监控他们。 技术上来讲，敏捷没那么复杂。它不是为了写代码而写代码，而是为了在快速变化的市场里，把“需求”变成“价值”。
那会儿我们习惯按里程碑交付，结局往往是交付了个半成品，上线之后客户说“没这功能”，开发还得改三个月。目前咱们搞“小步快跑”，哪怕每天只改一个需求模块，只要这个模块能拿个小胜仗，客户就能给红包，团队士气就高了。
这就叫迭代，不是单纯的代码循环，是价值循环。 记得那我带队的那个项目，市场突然变冷了，原定要推的电视полоvce，客户说配件忒贵。我直接拉上产品总监和运营，用敏捷思维拆解一下：能不能换个线谱？能不能和竞品做差异化？没搞明白之前，我们还在为卖不出去的心疼。结局我们调整了策略，推出了个带有智能健康监测功能的云台。软件用上了云端的算法，硬件去掉了沉甸甸的支架。上线前一周，客户拿着数据报告说：“这半年来了，设备故障率降了 30%，APP 用户多了 20%，咱们目前不亏。”那一刻，我明白了，敏捷的价值就在于用数据证明“改得值”，而不是用“改得快”来忽悠人。 说到团队，别总想着培养“超级英雄”型的 PM。在.devops 和 SAID 体系里，实际上每个人都是专家。
那会儿我总想把自己包装成全能型，结局被各种突发状况打懵了。
后来我意识到，真正的敏捷团队，是准有人专注于后端架构，有人盯着接口文档，有人琢磨用户故事。
只要大家各司其职，互不干扰，那个项目部的效率就出来了。有一次我让后端专门负责把数据库重构，结局他搞错了表结构，害得上线那天数据库挂了。
当时我认定他是不是不配干敏捷？后来我复盘发现，这不是难题，而是职责边界不清楚。敏捷需求的是“专才”和“广度”，不是每个人都得面面俱到。
只有找个靠谱的架构师负责核心层，其他人跑通了流程，大家才能从“救火”模式切换到“防火”模式。 另外，文档也不能忒死板。
那会儿我们写需求文档写到万字，出了事还得翻几页找灵感。目前咱们搞文档驱动开发，但重点不是文档本身，是文档能不能直接变成代码。
比方说，要是前端拿到后端接口定义，能直接写出测试用例；要是后端拿到用户故事，能瞬间画出原型。签字就签字，敲定就敲定。别再用那种让人“改改这个，改改那个”的沟通方式拖泥带水。
有时候，跳过中间环节，直接上代码，反而能找回节奏感。
这就是为啥我们要推崇“黑盒”测试，出于在这个体系里，测试才是质量的最终守护者，而不是开发者的自嗨。 再说说沟通，别搞那种大群聊、小群聊的混乱。真正的敏捷沟通，是“对事不对人”。当接口不稳定时，别在群里互相甩锅，直接拉上相关方，拿着毛病日志和复盘方案去开复盘会。数据讲话，难题当场定。别看有时候会挺累，就连有点“鸡飞狗跳”，但这是务必的。出于敏捷的本质就是暴露难题，不暴露难题，团队就一辈子认定自己在“流动”中保险，实际上只是在原地踏步。 最终说说心态。干敏捷项目，最大的坑往往是“过度承诺”。客户说“这个月一定交付”，结局拖到了下个月，团队崩了。
这时候别急着推辞，也别嘟囔客户。要冷静下来，用数据复盘：需求变更了多少？工夫延误了多久？
哪儿出了难题？然后把这原本可能几百人的团队拆分成若干个敏捷小组，每个人只负责一个小的、可控的目标。
这样就算延期，每个人只负责推进自己的小目标，整体项目也不会立马烂尾。 故此，做敏捷管理的，别追求完美，要追求“充足好”且“可交付”。别想着把整个世界塞进一个月，也别指望一次开发就完美无缺。
只要过程是透明的，价值是可视的，节奏是可控的，那这个项目就是成功的。
这就是我们常说的：别怕费事，只怕没方案。方案不出来了，再完美的代码也是空的。