什么是交付项目的敏捷之道？

很多项目嘴上说敏捷，实际干法还是瀑布，只不过把需求评审改名叫 Sprint Planning，把周会改成站会，再买一块看板，仿佛工具一换，项目就能自己跑起来。

没那么神。

敏捷宣言写得很直白：能工作的软件高于面面俱到的文档，和客户合作高于合同谈判，响应变化高于照计划执行。注意，它没说不要文档、不要合同、不要计划；它说的是两边撞车时，先保哪一边。

交付项目真正麻烦的地方，也就在这个「撞车」。合同通常希望范围确定，研发面对的需求却一直在变。于是团队很容易干出一件怪事：明明知道方向变了，仍然按照三个月前的需求继续做，因为流程上它已经签字了。

最后得到一个按时完成、没人想用的东西。

我理解的敏捷交付，核心不是站会，也不是把任务切成两周一轮，而是尽早拿出可以运行的东西，让客户有机会说「这不是我要的」。这句话越早听见越便宜，拖到验收时再听见，前面写的代码、接口和数据结构都可能跟着返工。

所以迭代要切小，但不能切成一堆看不见结果的技术任务。客户不关心「数据库表建完了」「接口写了六个」，他需要看到一个哪怕很窄、但确实能走通的业务流程。支付系统可以先跑通一种支付方式，报表可以先把一个最常用的指标算对。先能用，再往外长。

还有一件经常被忽略的事：敏捷并不等于需求随便改。需求可以变，但每次变化都要把代价摆出来。改一个按钮和改一套结算规则不是一回事，不能都扔进待办列表里装作只是多了一张卡片。

说到底，敏捷不是让团队跑得更快，而是让错误更早露出来。项目经理要是只盯着燃尽图一路向下，却不敢把能运行的东西拿给客户看，那块图画得再漂亮，也只是给延期事故提前做遗照。