从《用机器进行思考》看敏捷开发的本质
凯文.凯利在他的《失控》中提到了《用机器进行思考》这本书中的一个例子：在1948年以前，钢铁行业中的技术人员想要生产出厚度统一的薄板，结果都失败了。他们发现，影响轧钢机轧出的钢板厚度的因素很多，比如速度、温度、牵引力。他们不遗余力的一项项调整，然后又花了更多的时间进行同步协调，试图找到一个完美的条件组合，却没有任何效果。控制住一个因素会不经意地影响到其他因素。减慢速度会升高温度；降低温度会增加拉力；增加拉力又降低了速度，等等
后来，维纳提出了一个办法巧妙地解决了这个问题。他的核心思想是：反馈回路。
轧钢时，在出口处安装一个厚度测量仪，然后把这个信号传送回控制拉力变量的伺服电动机上，形成一个回路。如果产出的钢板厚度超过设定值，伺服电动机就调整拉力，这样，钢板的厚度就会变小。如果，产出的钢板厚度小于设定值，伺服电动机就反向调整拉力，使得钢板厚度增加。这样，通过这个反馈装置，在不知道速度、温度、牵引力等等这些因素如何具体影响钢板的情况下，精确控制了钢板的输出。
轧钢系统中的反馈回路
回到我们的敏捷管理的话题上来。简单的说，敏捷管理的核心思想就是：在流程中增加一个快速反馈回路。
Scrum敏捷管理模型
软件开发中的敏捷管理思想，要求团队在一个较短的时间内(一个迭代)生产出一个可运行的软件。这就如同轧钢时快速让钢板从出口产出一样。然后，可运行的软件会交付给用户使用，让用户提出反馈意见。用户就是厚度测量仪，他们在真实的场景中使用这个软件，便知道它是否符合实际需要。如果软件偏离方向，用户会就会发出相应的信号。
开发团队会定期开回顾会议和迭代会议，将用户的这些信号转变成下一个迭代的需求内容，让软件的特性朝着用户需要的方向发展。这个机制就像在流程中增加了一个回路装置一样，让流程出口的信号返回到入口，进行再加工。每一个迭代都会让团队向正确的方向上微微调整一点点。经过反复迭代，团队就能交付出满足需求的软件。
为什么PC时代通常使用瀑布模型，而到互联网时代更多采用敏捷思维？瀑布模型是Royce在1970提出的软件开发模型，这个模型源于对工业生产管理的模仿。由于工艺上的各种限制，工业产品从设计到交付有一个很长的周期，中途很难调整。比如生产飞机。厂家无法做到让飞机经常上天试飞，频繁重复各种故障。很多时候，故障出现一次就是致命的。因此，必须在设计阶段就把各种风险解决掉。
瀑布流开发模式
PC时代的软件开发，与工业制造有颇多相似之处。软件开发出来通过光盘销售，软件与用户的距离很远。开发团队收到用户的反馈周期长，无法形成一个有效的快速反馈回路。因此采用瀑布模型是合适的。
互联网时代到来后，用户和软件的距离大大缩短，反馈回路得以实现，敏捷开发思想便适时的出现了。
如果我们理解了敏捷的本质，就不会纠结于怎么开迭代会、怎么估点、怎么评审这些细节。不管怎么玩，只要始终把握正确的方向，就不会出错。