梦想风暴

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://dreamhead.blogbus.com/logs/33068654.html

曾经，我以为，所谓敏捷咨询，就是把敏捷理念传递给客户，然后，带着客户做一些敏捷实践，让客户知道每一步应该如何来走。

如果仅仅“敏捷”定义我们的工作范围，我们显然已经越权了：
* 我们曾经建议用新的集成测试方案替代公司内已经长久存在的集成测试方案。
* 我们做的一些重构可能会超出了项目组的范围，以致于碰触到一些其他项目组的代码。
* 我们坚持测试人员做到开发人员身边，而在客户这边，这意味着跨部门的协调。
* ……

偶尔我会想，从表面上来看，这些东西已然不是敏捷的范畴，那我们为什么要做这些，客户需要的不是敏捷吗？随着我在这里和同事、和客户交流的不断增多，我越发认识到一点：客户真正需要的不是“敏捷”，他们需要的是一种比更好的方法开发软件。所以，我们提供的也远不止“敏捷”咨询。

去年，我在《圣诞聊敏捷》时提到过，敏捷是一种好的工作方法。其实，我一直都不太在乎敏捷这个名字，那只是给人讨论／争论／辩论而预备的。我们不断探索的是一种恰当的做软件开发的方法。

客户的一个项目经理对我们说过，之前，他一直在想，难道软件开发只能让大家那么痛苦吗？为什么在这个过程中，会出现种种的问题，有些看起来很简单的问题却到了几乎无法解决的地步。与其说，我们要改变他们，不如说，他们自己在寻求改变。

我们的到来，对于他们而言，引入的是一种新的思惟方式，因为他们之前没有从这个角度考虑过问题。

通过一段时间的观察，我发现，所谓的流程是非常容易学习的：在我们引导客户的几个人做过需求分析之后，他们就可以按照类似的方式进行后面的需求分析；当我们告诉他们如何编写测试之后，他们就会自己按照类似的方式进行开发。但是，并不是掌握了这些流程，我们就算结束工作了。相反，适应了这些基本流程之后，越来越多的问题会暴露出来。比如，原本测试是一个相对延后的过程，而TDD把测试提到了一个新的高度，大家就会觉得快速测试、快速反馈是好的，这时他们原有的集成测试就会显得笨拙，于是，改进集成测试方案成了必然。

借鉴“破窗户”理论，不同的东西总是会不断扩散的。于是，原来一个个不是问题的点就成了问题。现阶段，虽然客户开始发现一些问题，但是，他们还不太习惯按照新思路进行自我改进，于是，我们——作为顾问——就要和他们一起动手解决这些问题。而正是因为我们和团队工作在一起，我们的解决方案才能做到有的放矢。比如，我们建议每天有一个固定时间段，大家可以就项目各方面的问题进行讨论或者分享，这种做法就是针对着团队之间交流和分享不充分而提出的。当然，问题多种多样，技术的，过程的，甚至组织的。所以，我们必须不断越出“敏捷”的圈子。

参与一个交付项目，我们留下的是一段段代码，那咨询项目呢？我们希望客户不仅仅是知道有一种不同的工作方法，更希望这种方法为他们带来真正的改变，向着他们希望的、好的方面改变，那怕只有一点也是好的。