敏捷的本质是负反馈调节，而非提速工具

敏捷是一组价值观和原则（2001年由Martin Fowler等17位专家在犹他州雪鸟会议上提出），而不是Scrum、XP这类具体方法论本身——这些具体方法论只是敏捷价值观的落地实现。敏捷诞生的根源是瀑布模型的局限：瀑布式开发是工程化思维在软件领域的应用，靠一个个事先规划好的里程碑推进项目，这套模式在工程建筑领域（大楼、大桥）效果很好，因为设计图纸一旦确定基本不会大改；但软件开发的需求变化是家常便饭，瀑布模型难以应对，于是极限编程、Scrum、水晶方法、精益开发这些方法先后出现，最终提炼凝聚成敏捷思想。一个容易被误解的地方是：敏捷本身并不能提高单个需求的开发效率（同一个需求，传统方式5天做完，敏捷方式同样要5天），也不保证缩短项目周期或降低成本——对高确定性的项目，敏捷反而可能因为沟通成本增加而变慢；敏捷真正适用的是模糊性大的项目：项目初期对系统了解最浅薄，不可能一开始就把所有需求定死，敏捷通过先抓住关键需求（MVP集合）、随认知加深逐步明确后续需求，往往会发现原计划的许多需求根本不需要实现，从而省下这部分本可以浪费掉的资源和时间。剥开XP（强调快速反馈、简单性、持续集成）和Scrum（强调原型优先、迭代式开发、自组织团队、透明化过程）这些具体实践的表象，敏捷的核心可以归结为控制论里的一个术语——负反馈调节：设定一个目标差，执行过程中不断拿反馈和这个目标差比较，让差距一次次缩小直到达成目标（就像老鹰捕猎时不预先计算猎物的完整运动路线，而是持续根据猎物动态调整飞行方向，不断缩小自己与猎物的距离）。负反馈调节之所以有效，源于两个因素：一是客观环境本身在不断变化，负反馈让计划能随环境灵活调整，瀑布式的”一开始就做详尽计划”反而缺乏应对不可预测事件的能力；二是完成复杂任务所需的资源本身是分层、嵌套、循环关联的，无法一次性预见和安排好，只能逐级解锁——所以对复杂任务而言，更好的方式是先做起来，靠不断反馈缩小与目标的差距，而不是妄图一次性制订出完美的计划。