敏捷项目管理之KANBAN和极限编程

先认清缺口：别拿瀑布的脑子硬套敏捷

很多研发转岗者或初级项目经理的痛点是：天天把敏捷挂在嘴边，实际干法还是写死排期、强推节点。这门课解决的就是这种“伪敏捷”问题——把看板和极限编程这两个落地工具掰开揉碎，补上从理念到工程实践的断层。它适合两类人：一是写过几年代码但对项目管理流程稀里糊涂的开发者，二是刚接手敏捷团队但只会开站会、不懂底层逻辑的初级管理。你需要对软件研发周期有基本概念，不需要精通某门具体语言，但得知道代码是怎么从本地跑到仓库的。建议先啃透敏捷宣言与Cynefin框架这几块，搞清楚复杂自适应系统为什么不能用确定性思维去管，再进入看板和极限编程的具体规则，否则后面学在制品限制和测试驱动开发时，你会觉得这些都是脱裤子放屁的繁文缛节。

怎么练：看板算数学，XP敲键盘

资料里的内容不能光靠眼睛过一遍。看板部分的核心是流动效率，配套练习必须动手算：找你当前团队的真实任务，画出价值流映射图，用利特尔法则去推导交付周期。重点体会那个并行数字游戏——自己拿几个任务模拟并行推进和串行推进的差异，亲手算算多任务并行到底损耗了多少吞吐量，这比听十遍理论都管用。极限编程部分不能只当概念背，必须结合代码库练。比如学测试驱动开发，别去网上找现成教程，直接在自己当前项目里挑一个简单函数，严格走“红-绿-重构”循环写一遍；学持续集成，就自己去搭一套流水线，故意提交一段挂掉的测试代码，看看流水线到底怎么拦截。物理看板和电子看板的对比也要结合实际选型去思考，别盲目迷信电子工具，先想清楚团队是分布式还是坐在一起。

学完能答什么：别假装懂了

看完这套资料，你得能脱稿回答几个硬核问题，才算真正补上了这块能力缺口。第一，如果业务需求天天变，你到底该用Scrum还是看板？看板的在制品（WIP）限制到底卡的是人数还是任务数？第二，极限编程的四大核心价值观里，沟通和反馈怎么通过结对编程和持续集成落到具体的工程动作上？重构为什么必须和测试驱动开发绑死，单独做重构会死在哪里？第三，回到你自己的团队，如果明天让你推行这套东西，你会先限制哪个环节的并行任务？哪些极限编程实践能立刻上，哪些因为历史包袱必须暂缓？如果这些问题你支支吾吾答不出具体逻辑，只记得几个名词，那就把对应的章节倒回去重看。查漏补缺不是凑进度，缺什么补什么，别假装什么都会。