跟上" 敏捷" 的步伐

    以上是登在敏捷联盟网站显著位置上的“敏捷宣言”，对于那些疲于应付内部的各种规章制度和外部客户的各种要求，但却永远赶不上计划进度的项目经理们；对于那些编程之余还被强行要求编写“该死的文档”的程序员们，对于那些勉为其难的维持着那些理论上无比正确但在执行过程中摇摇欲坠的软件过程的QA经理们。这些宣言听起来是何等的让人耳目一新且神清气爽......

    然而，软件开发光有好心情显然是不够的，这些“宣言”究竟是一剂灵丹妙药还是一些哗众取宠的口号而已，我们不妨来看看这些宣言背后所蕴藏的含义......

强调个人和交互而不是过程和工具。

    和CMMI这类重型的过程模型着重强调过程规范而淡化人为因素不同，“敏捷”的过程更依赖于人的因素，不管是什么样敏捷过程要想有效的被实践都有一个非常重要的前提，那就是“Professional”的个人，“Professional”这个词在中文中其实并没有一个意义完全能够对应的词汇，因为“Professional”不仅是指“专业”，而且是在这个专业上有想当的经验和造诣。所以当我们计划实践一种敏捷方法的时候，我们首先要看看我们的团队（至少是团队中的部分人员）是否够“Professional”——编码能力、分析和设计能力、重构、架构......，换句话说，摆脱过程和工具的前提是你有一个和你的目标相称的由诸多“Professional”个人组成的团队。

强调工作的软件而不是繁复的文档。

    可以摆脱文档是大多数程序员梦寐以求的好事情， 文档的目的是为了传递程序以外的开发过程中需要传递的中间信息，例如需求和设计等。我们不能在抛弃文档的同时把这些东西也抛到九霄云外 。实际上敏捷只不过是用一些不同于大家习惯的方式来完成通常需要文档来完成的工作。
    例如需求，在传统的开发过程中我们通常采用需求规格文档来记录和传递需求，而敏捷开发的代表——XP中对于需求的传递是这样实现的：用故事而不是需求规格来传递需求，XP给出了这样一幅美好的画面——程序员们一边阅读着优美的故事（而不是枯燥的需求文档）一边编写着代码 。然而故事传递的只能是需求的概要，至于需求的细节则用现场客户来弥补，而由此导致的需求不完整性和不精确性则通过持续的迭代、集成、发布来进行不断的完善。
    也就是说，虽然敏捷教导我们抛弃文档，但并不能同时抛弃文档所传递的信息，我们在采用敏捷方法以前应该审视一下我们是否已经做好了足够充分的准备：例如我们的故事描述方法是否能够达成基本的一致而不产生大的歧义；我们是否在技术上做好了持续集成的准备；我们的客户是否能够满足我们的要求进行充分的配合......

强调客户的协作而不是合同的谈判。

    将客户作为协作的伙伴而不是谈判的对手，是一种化敌为友的高明策略，然而支撑这种策略的实现，则需要高超的沟通技巧和娴熟的商业手腕，我们常说客户和技术人员用的是两种语言——技术语言和业务语言，要让客户用技术人员的专业语言来沟通显然是不现实的， 因此这就要求我们的技术人员必须用业务语言和客户沟通，尤其是强调现场客户作为获取明细需求的主要手段，这就要求我们和客户打交道的技术人员除了具备专业知识以外，还需要充分掌握业务背景，并且具有高超的沟通技巧和商业手腕。

强调变更的响应而不是计划的遵循。

    和CMMI意在彻底扼杀变更所导致的缺陷的可能性不同。敏捷方法采用的是让变更所导致的缺陷不至于产生严重的后果，换句话说，就是让变更导致的缺陷能够被及时的发现和修复。
    所谓的“条条大路通罗马”， 但是不管采用哪条道路，我们的目的地是罗马，这点是绝对不能改变的， 我们并不能因为选择了一条风景优美的道路却一路走到了西伯利亚，因此无论采用什么样的方法，不管是“敏捷”的还是“迟钝”的，我们都应该在路上始终牢记我们出发时所确定的目的地——罗马。 例如敏捷的代表——XP，虽然抛弃了基于配置管理的那一套复杂而繁琐的变更控制体系，但持续的迭代、重构、集成和发布同样对团队的技术平台和团队成员的能力构成不小的挑战。

结论：

    敏捷的步伐固然优美而轻快，但需要有坚实的内力和充分的热情才能保证脚下的步伐始终的一致和协调。所以，当你选择敏捷方法的时候，首先扪心自问一下：你是否具备足够的智慧、经验和能力......