渐进式敏捷：由下而上的敏捷推行策略

BJUG的创始人李默在一篇题为“敏捷的弱点”的文章中指出，“当你没有办法改变你周边的人、部门、公司做事方式的时候”，敏捷方法的适用性会降低。他进一步举例说：

在某些公司，由于各种原因，一个团队的敏捷程度完全取决和他们合作的部门或公司的敏捷程度。在一个项目中，我的一个同事所在的团队需要和数据库部门以及另 一个开发部门协作，从而完成一个系统集成应用，然而，他们没有数据库的操作权限，同时另一个部门的 API 尚未就绪。他们很快就开发完毕自己所分配的部分功 能，在等待中不断的催促和协调另外的部分。一个几周的工作，硬生生的被拖到了三个月。

敏捷的效果需要在合作各方都采用敏捷方法时才能得以充分发挥。正因为如此，一种广泛存在的看法认为：敏捷的推行必须由组织高层由上而下地进行。在“敏捷中国”用户组的一个讨论中，网名 photoman 的网友这样说道：

要想实行某种制度，首先必须要取得从上至下的一致看法，获得得到大多数人的同意并从公司行政角度加以制度化。如果敏捷实践只是一个人或者一个小组的试验性的工作，那首先不能不考虑公司利益，不向上级请示就开干，这样做有违职业操守，如果无人作主不论如何不应该启动，至少你没有理由说服领导层决策，这样的做法只能算蛮干。

但这样一来，敏捷的推行者们往往陷入一个两难境地：要实际推行敏捷，需要首先得到高层的支持；但没有实际推行敏捷之前，又拿不出证据来说服高层。面对这种情况时，网友“咖啡屋的鼠标”意识到没有证据很难说服同事和领导，于是采用了一种渐进式、由下而上的敏捷推行方法：

我现在就在用敏捷的思想做一个号称 CMMI4 级的小项目（只有四个人）。我始终没对上面说要用敏捷（不过以我对敏捷的热衷，上面也猜的到，只是不说罢了）。我只是说要先写单元测试用例（这不是问题，CMMI 也认可），要自动化测试，要大家都坐的近一点，早晨开个晨会，写用户故事当成测试用例，使用 Mingle 管理我们的项目，慢慢的现在已经有些像 Scrum 了。公司那边还是会要 CMMI 文档，还是会按照公司的制度运行，我这边也并行不悖。等我的故事够多了之后，详细设计也就有了。操作手册也有了，每个周的周报也不缺，很多本来是瞎填的文档最后肯定是能填的更好了。有了第一个成功的案例，再说话分量就不一样了。空口白牙能说通那真的是很难。

来自 ThoughtWorks 的李晓也曾有过类似的经历：

最容易，最有成效的应该是 TDD，或者就是补一些测试也是非常有价值的，至少我以前就这样做过，周围没有一个人做敏捷相关的实践，我就只是尝试 TDD，效果是非常好的，即使没有人跟着你走敏捷的路，其他人其实也是非常认同你的能力的。

正如李默在他的文章所指出的，要说服别人、改变别人并不容易，更多的时候敏捷的推行者们只能靠自己小范围的实践来影响周边的人，让别人看到这些实践的价值。

改变一个人虽然困难，但我们可以去影响他们。只要从基本的实践处做起，逐渐的，周边的人会被带动，从而可以推动整个部门的改变。一个部门改变了，公司领导会很快意识到这种变化，变化也有可能影响到其他部门。只要我们坚持去做。

老话说临渊羡鱼不如退而结网。如果组织高层领导大力推行敏捷那当然是好事，但很多时候敏捷的主要推行者还是技术人员和中层技术型管理者，老板们还在等着看他们实践的成果。在这种情况下，有计划、有技巧地采用渐进式的、由下而上的推行方式，可能就是让敏捷在企业中扎根的第一步。