新来的项目经理宣布团队全面敏捷，开的第一件事是每天 9 点开站会、每两周一个迭代。跑了两个月，加班反而多了，版本交付还是卡在测试手里，流程一个没少，产出一点没快。

交付可用软件才是硬标准

敏捷宣言 2001 年在雪鸟城由 17 个人写出，开头就定了价值观：个体与交互胜过流程和工具，可工作的软件胜过详尽的文档，客户合作胜过合同谈判，响应变化胜过遵循计划。每两周拿出一个能跑、能演示的版本，胜过攒三个月交一份漂亮的文档。状态会的重点也是阻塞列表，不是汇报进度。

三类角色各守一条线

  • 产品负责人：守需求清单，按价值排序，一个迭代只锁当前清单，优先级由价值说了算。
  • Scrum Master：守节奏，清扫协作阻塞，不当任务分派员。
  • 开发团队：守质量承诺，工作量自己认领，不接受从外面塞进来的deadline。

拆分需求时用拆分故事的思路，一个故事最好控制在两三天可交付。故事写好验收标准先行，测试能照着它写用例。

每次迭代必须发生的四件事

计划会定好本次目标和验收线。每日站会只说三句：昨天完成了什么、今天干什么、卡在哪里，超过 15 分钟就砍。评审会给业务方演示能跑的功能，收集反馈改清单。回顾会只抓一条最痛的问题定改进动作，贪多等于没有。

什么时候它不适用

需求极其稳定、交付物是固定标书的项目，用瀑布反而划算。监管要求全套过程文档的场合，敏捷的轻文档也得打补丁。团队不足五个人时，角色分工全是形式，按清单执行即可，不必硬凑仪式。

  • 判断提醒：迭代能稳定交付可用版本，说明原则落地了；若迭代内容永远做不完，先砍范围，再补测试，别靠加人头。