01 _ 灵魂拷问：如何利用敏捷思维更好地解决实际问题？

先用几个案例聊聊做敏捷的价值。

最近几年，敏捷在国内推进得如火如荼，很多公司的研发团队都在使用它，并且尝到了这里面的甜头。但也有些公司，看别人做得挺好，就照搬过来，结果却并不奏效；由于探索得不是很成功，他们就觉得敏捷不好用，不适用于自己的公司，也开始怀疑它的价值。

作为一个过来人，我想谈一下我的看法：我认为敏捷确实是很好的，只是推进它也确实不容易。

为什么这么说呢？这是因为，敏捷毕竟是一场变革，它本身涉及了很多有关人的因素，比如说人的习惯、团队文化的改变等等；而且它的核心点是持续改进，可以说是一场没有终点的旅行。况且它有一定的章法，但是你若想运用好它，又不能拘泥于它的章法；如果你只是了解它的表面做法，就开始邯郸学步，那你注定会失败。

因此在这节课里，我更想让你了解的是敏捷的思维，理解透了这一点，你自然就能够把它融会到工作中，举一反三。但是切记，千万不要为了敏捷而敏捷，所以我也并不是想说服你必须全盘使用敏捷，如果你觉得敏捷方法很多、有些繁杂，不是所有都能用得上，那你完全可以从中借鉴一些好用的去解决你的实际问题。总之，不管用什么方法，只要能更好地解决问题就可以了。

接下来我想和你讲一个故事，来具体说明下为什么我觉得敏捷很好。

记得那是2007年~2008年，我们有一个项目是负责某大型通信公司印度尼西亚工厂的SAP实施。在简单了解需求之后，我们制定了项目初步计划，包括预算、人员安排和进度计划等等；目标是用10个月完成项目，这又包括了需求调研、开发、测试、上线以及用户培训。

我们的项目经理很资深，公司也有一套成熟的项目管理模式，于是我们就按照公司规定的项目管理规范来开展工作。

我们花了1个月的时间进行项目的前期筹备，包括组建团队。之后，我们花了2个半月的时间做完了需求调研，又花了3个月做开发，开发完成后交给测试，测试花了2个月完成，然后交付给客户来验收。验收之前，我们仿佛看到了胜利的曙光，就等着办庆功宴了。

没想到，噩梦才刚刚开始。当客户看到系统并真正试用时，才开始觉得这也不行、那也不可，提了大大小小50多条修改意见。记得当时验收会议结束时，客户相当不满意，就差拍桌子了。

在接下来的日子里，我们的工程师开始加班加点地改，项目经理和