这是什么
传统做法是：花3个月写需求文档，再花6个月开发，再花3个月测试，一年后终于发布了——然后发现用户根本不要这个。敏捷迭代完全反过来：两周内做出一个最小可用版本，给用户用，收集反馈，两周后再改进。核心思想是：你不可能在办公室里猜到用户要什么，只有让产品进入用户手里，你才知道该往哪个方向做。就像做菜：你不是一口气做完一整桌菜才端上桌，而是先做一道让人尝尝咸淡，再决定后面的菜怎么调味。敏捷不是'没有计划'，而是'计划是动态的'——每两周根据真实反馈调整方向。
什么时候用
产品需求不确定时、创新型项目、用户需求快速变化的市场
什么时候别用
安全关键系统（航空、医疗设备不能'先上线再改'）、需求非常明确且稳定的项目、法规要求完整交付的场景
怎么用
- 1
拆分为2周一个的迭代
把大项目拆成每2周可交付的小单元。每个迭代结束时必须有可用的东西
- 2
每个迭代只做最重要的事
每2周开始前，从待办清单中选出最重要的几件事，集中精力做完
- 3
快速收集反馈
每个迭代结束后让真实用户使用，收集他们的反馈
- 4
根据反馈调整下一个迭代
用户说好用就继续，说不好就改方向。保持灵活
真实例子
Spotify的部落模式
Spotify把公司分成多个自治小队（Squad），每个小队像一个迷你创业公司，负责产品的一个功能。每个小队自己做决策、自己发布、两周一个迭代。这种模式让Spotify能快速试错——新功能先给1%用户试用，数据好就推广，数据差就回滚。
Gmail的永久Beta
Gmail在2004年发布，但一直标着'Beta'标签，直到2009年才正式去掉——整整5年。Google的理念是：产品永远在迭代，没有'完成'的那一天。Gmail从最初的1GB存储，不断迭代加入了标签、搜索、垃圾邮件过滤等功能，最终成为全球最大的邮箱。