昨天读完了这本书（小册子），说的是敏捷开发的实践，作者写的很有幽默，读起来颇有些欲罢不能的感觉。

敏捷的开发方法一直给我一种“聪明人的游戏”的感觉，这伙人似乎都有一个共同的特点：很能扯。换种说法，应该是很强的沟通能力吧！这应该和敏捷开发的价值观有关。

沟通

敏捷中的沟通，包括客户与团队的沟通、团队与团队的沟通、团队内部的沟通。敏捷方法认为这些沟通应该是日常的、每天甚至每时都在进行的事情，是每个人的事情而不是某一个人的事情。比如“客户作为团队成员”，就是旨在将客户与团队的沟通视为日常工作。

加强沟通的最好办法就是降低沟通的成本。就我们团队实践敏捷的经验来看，其实成员之间是很想沟通的，前提是沟通起来很容易：如果A坐在你的旁边，相信你很乐意和他讨论，如果找B必须打总机、转分机、再找人喊他一声，估计你会很快打消和他聊聊的念头。所以，敏捷团队通常要求成员“在一起”，即便是不能物理上在一起，也要通过视频、语音、IM等手段，让他们看起来貌似在一起。不过还是要想方设法的让成员真正的坐在一起，毕竟我们是在工作，对吗？

“结对编程”就要求很强的沟通能力，或许这倒是招人的好办法：你的简历上不是说团队协作能力强吗？结对试试吧！

务实

敏捷一直强调的是能用的代码，强调尽快的将系统交付给客户，通过代码而不是文档和用户沟通，让人感觉很踏实。从用户的角度来看，总能看到真金白银、可以实际操作的系统；从开发人员的角度来看，一步一步向终点迈进，信心十足。其实这和现在Web公司的思想有些类似，以前做网站都是大，任何网站都想把自己做成门户，现在不了，改成瞄准一个领域，先争取上线运行再说，一点点的发展。

务实的另一个要点是不做任何多余的东西。TDD最能表现这一特点——绝不写任何多余的代码，绝不做任何过度的设计。“用户故事”也是这么一种思路，让用户描述应用场景，而不是通过用户描述想法，猜用户需要什么。而且用户没有明确提出来的东西绝对不考虑。即便是用户明确提出来了，还要分个优先级出来，首要实现最重要的。

务实应该重内容而不重形式，比如对于“总结”有个说法：The most important thing about retrospectives is to make sure they happen。关键在于你做了，而且想办法把它做好，至于怎么做最好，就要视情况而定了。

平等

团队的成员是平等的，无论是在技术上还是职责上，任何人都了解项目的任何部分，并且被鼓励发表意见。代码是共有的，所有人都有权修改。知识在团队内部快速传播，使得每个人都有完成项目任何部分的能力。

这似乎不太符合咱们的国情，比如“团队所有人都有权修改代码”，在领导（中国特色的职务）看来，太危险了，谁都能改还不乱了套？但是说，这种方法很有效，我们团队的实践也证明了这一点，其实，一个团队的伙伴，谁会乱来？

敏捷的方法或许只能用在软件开发中，但敏捷的的思想却不仅限软件工程，在“一切都是项目”的今天，做什么工作不能敏捷一点？