现在“敏捷开发”已经成为了一个非常“时髦”的词汇，很多的团队和公司都声称自己正在“做敏捷”，但是作为一个跑过很多公司，见过很多项目和团队的敏捷教练来讲，我却很悲哀地发现，很多团队的做法却没有真正理解敏捷开发背后的意义，甚至早已和敏捷宣言所倡导的价值观背道而驰了。
重读敏捷宣言
“2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚到一起，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》（Manifesto for Agile Software Development）。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。”——history of agile manifesto
我想不用太多我个人的赘述，在敏捷宣言的官网上就已经有了非常明确的描写，只是似乎人们都不太擅长学习，对于敏捷开发的误解很多也就来源于此。
什么是敏捷？
敏捷是快吗？似乎是，也似乎不是。如果敏捷是快的话，为什么当年他们把这种开发方法叫做“Agile”，而不是“Fast”或者“Rapid”呢？
我们看一下这两种动物：大象和猴子，如果说“快”的话，猴子的奔跑速度怎么也不会比大象更快，但很显然，相比于大象，猴子是更加“敏捷”的。
敏捷不敏捷，取决于一个动物或者一个系统是否能够察觉到周边环境细微的变化，但是光察觉到还不够，主要还得看是否能够作出应对。你说：“其实我早就知道了，就是没有做到。”那也是不够敏捷。
所以所谓的敏捷，涉及两个方面：敏锐的感觉和矫健的身手。
为什么要敏捷？
在过去的几十年间，人类商业环境的变化和科技水平的发展正以指数级的趋势在增长，于是商业组织和个人是否能够在这样剧烈的变化中生存下来，就变得非常重要，正是因为如此，敏捷开发所倡导的“响应变化”的价值观才应运而生，也在过去的15年间得以发扬光大。
关于人类科技水平的变化，雷·库兹韦尔提出了一个很有意思的定律，叫做“加速回报法则”，网络上有一个更加通俗易懂的翻译是“吓尿单位”，下文转自《人工智能革命：人类将永生或者灭绝》。
想象一下坐时间机器回到1750年的地球，那个时代没有电，畅通通讯基本靠吼，交通主要靠动物拉着跑。你在那个时代邀请了一个叫老王的人到2015年来玩，顺便看看他对“未来”有什么感受。我们可能没有办法了解1750年的老王内心的感受——金属铁壳在宽敞的公路上飞驰，和太平洋另一头的人聊天，看几千公里外正在发生进行的体育比赛，观看一场发生于半个世纪前的演唱会，从口袋里掏出一个黑色长方形工具把眼前发生的事情记录下来，生成一个地图然后地图上有个蓝点告诉你现在的位置，一边看着地球另一边的人的脸一边聊天，以及其它各种各样的黑科技。别忘了，你还没跟他解释互联网、国际空间站、大型强子对撞机、核武器以及相对论。
这时候的老王会是什么体验？惊讶、震惊、脑洞大开这些词都太温顺了，我觉得老王很可能直接被吓尿了。
但是，如果老王回到了1750年，然后觉得被吓尿是个很囧的体验，于是他也想把别人吓尿来满足一下自己，那会发生什么？于是老王也回到了250年前的1500年，邀请生活在1500年的小李去1750年玩一下。小李可能会被250年后的很多东西震惊，但是至少他不会被吓尿。同样是250来年的时间，1750和2015年的差别，比1500年和1750年的差别，要大得多了。1500年的小李可能能学到很多神奇的物理知识，可能会惊讶于欧洲的帝国主义旅程，甚至对于世界地图的认知也会大大的改变，但是1500年的小李，看到1750年的交通、通讯等等，并不会被吓尿。
所以说，对于1750年的老王来说，要把人吓尿，他需要回到更古老的过去——比如回到公元前12000年，第一次农业革命之前。那个时候还没有城市，也还没有文明。一个来自狩猎采集时代的人类，只是当时众多物种中的一个罢了，来自那个时代的小赵看到1750年庞大的人类帝国，可以航行于海洋上的巨舰，居住在“室内”，无数的收藏品，神奇的知识和发现——他很有可能被吓尿。
小赵被吓尿后如果也想做同样的事情呢？如果他会到公元前24000年，找到那个时代的小钱，然后给他展示公元前12000年的生活会怎样呢。小钱大概会觉得小赵是吃饱了没事干——“这不跟我的生活差不多么，呵呵”。小赵如果要把人吓尿，可能要回到十万年前或者更久，然后用人类对火和语言的掌控来把对方吓尿。
所以，一个人去到未来，并且被吓尿，他们需要满足一个“吓尿单位”。满足吓尿单位所需的年代间隔是不一样的。在狩猎采集时代满足一个吓尿单位需要超过十万年，而工业革命后一个吓尿单位只要两百多年就能满足。
现在所有人对于人工智能的警觉也来源于此，因为也许我们下一个面对的“吓尿单位”只有几十年或者几年了。
明确了敏捷开发价值观的本意是“灵活应对变化”，以及敏捷开发的本质是追求“对变化敏锐的感觉”和“能够跟上变化的矫健身手”之后，我们再来看看对敏捷开发常见的一些误解。
误解一：我们现在工期很紧，是不是可以尝试一下敏捷开发？
在上文中我们提到，敏捷并不是“快”，目的也并非是“提升效率”。敏捷的目的是能够做到“快速响应变化”。
如果说采用了敏捷方法之后，提升了效率和质量，那也只是我们做到“快速响应变化”之后的一个副产品罢了。
误解二：敏捷开发就是没有计划，指哪儿打哪儿。
事实上，在之前阶段式开发占据主流的年代，即使是最出色的技术人员，面对一个长达半年或一年的项目，让他去估算，也很难做到准确无误。甚至有数据表明，在一个三个月周期的开始阶段，做出的估算上下误差高达400%。
这么看来，在那个年代，我们估算并做出来的工作计划只不过是自欺欺人罢了。
敏捷开发也并非采用了什么新的估算和计划方法，只不过更加面对现实罢了，事实上，在敏捷宣言的网页上有这样一段话：
敏捷运动并不是反方法论的，事实上，我们中的大多数人正在试图恢复方法论的名声。我们希望能重归平衡。我们乐于建模，但目的不是给无人问津的企业资源库增加几篇图表存档。我们要写文档，但那些从不维护、并很少用到的长篇大论不算在内。我们得做计划，但同时也要认识到在剧烈变化的环境中计划的局限。
不论是Scrum框架也好，Kanban方法也好，都不是没有计划。Scrum作为一个极度轻量级的开发框架，也把迭代计划会作为保留下来的4个会议之一。Kanban方法背后的精益开发更是把计划放到了每一次卡片拉动的过程中。
所以在敏捷开发中，并非是不做计划，而是将过去的“长计划”转变为了“常计划”，面对现实，不去做自欺欺人的长期计划，而是经常性地、频繁地调整计划并做出预测。
误解三：我们非常想尝试敏捷开发，但不要改变任何现状，也没有时间投入到改进工作
在软件工程的名著《人月神话》中，布鲁克斯就已经下了一个断言：软件开发没有银弹。不存在什么放之四海而皆准的方法论和工具，应用之后就可以瞬间强身健体吃嘛嘛香，每一次改进和前进都是需要团队和个人付出汗水和努力的。
如果什么也不做，那么什么也不会发生。
事实上，在敏捷转型的过程之中，我们希望得到的更多是远期的一些收益，短期之内开发效率、表现反而还会出现一些下降。其实这并不难理解：团队需要时间去进行学习、适应新的工作方式和流程，当一切磨合好了之后，我们才会逐渐收回投资，我们把这种效应叫做“J-curve”，如下图所示，横轴是时间轴，纵轴是进行改进过程中团队的效率和绩效。
误解四：我们现在有了迭代和站会，所以我们现在是敏捷的了。
上文中提到了敏捷开发被提出来的时候的目标是为了“更快地响应变化”。所以我们做了什么其实并不重要，重要的是我们做的这些事情有没有使我们能够敏锐地感觉到外界的变化，有没有使我们能够更快更可靠地对这些变化做出应对和反应。如果有的话，那你就踏上了“变敏捷”的道路，如果没有，那我劝你要么调整姿势，看看如何能够得到这些收益，要么干脆就别折腾了。
毕竟，不看广告，得看疗效啊。
有的团队在每个迭代的计划会上，一不看上迭代结束之后干系人提出的反馈，二不看自己团队上迭代完成的故事点数，直接蒙着眼睛做下迭代的计划。
最终的结果是：每个迭代的计划达成率都很低，而且也没有及时将干系人的反馈意见调整到交付计划中。
如果没有收集到有效反馈，那么迭代演示会就是没有效果的。
如果没有根据上迭代的速率进行新迭代的计划，那么计划会就是失败的。
误解五：敏捷是好的，PMBOK/CMMI是坏的。
很多次我在给团队一些改进意见的方案的时候，会听到声音说：“这也不是什么新鲜东西嘛。”“这不是PMBOK里的东西吗？”
举个例子：我见过有一个几百人的产品开发团队，这个项目在前期风险管理做得非常不好。风险要么没有识别出来，要么识别出的风险缺乏跟踪，到项目执行中仍然会像放炮仗一样一个接一个的爆炸。其实风险管理作为PMBOK九大知识领域之一，管理和应对手段都很成熟了。
应对的思路就有“转移、接受、缓解、消除”四种，而我看到的情况通常都以“接受”为应对手段，赌这个风险不会发生，或者等一个Risk变成了Issue再去想应对方案。
风险识别不论是在需求优先级排序还是在架构设计上都是非常重要的一环，我们之所以把高价值、高风险的需求视作第一优先级，是因为我们希望尽早释放风险，尽早缓解风险。我们提的“简单设计”简单到什么程度，也是由是否能够涵盖最重大的风险作为边界的。
对于这种事情，我只能说，解决这类问题还没到需要敏捷转型才能解决的份儿上……
最后：在这篇文章里，我没有写到如何才能做到敏捷，只是希望看这篇文章的团队和个人能够真正理解敏捷所倡导的价值观和我们做敏捷转型所期望达到的效果，如果理解了这些，我相信每个人都能够做出判断：自己正在做的究竟是不是敏捷。
