不久前我去了趟中国和澳大利亚，我发现大家都想变得“敏捷”。在这方面，也许北欧和美国稍微领先一点，但是它的趋势已经遍布全球、不可逆转了。在
与CIO的圆桌会议上，我总是喜欢问问大家现在对什么感兴趣。五年前，很多人的回答是“我们在试着采纳统一过程”。现在，针对同样的问题，大家的回答变成
了“我们在向敏捷转变”。借此也许可以假定人们已经知道“敏捷”是什么了。
上个月，我进行了4次演讲，每次的听众大约有100-200人，接洽了大约12家公司。每次演讲，我讯问听众在敏捷方面的新进展，而得到的回应也大致是如下几种：
快速迭代
能够产生可用的软件
应付变化
沟通
灵活性
适应性
消除浪费
小迭代
特性驱动
持续集成
测试驱动开发
零文档
人优先于过程
适应变化
由团队自主设置优先权
干系人尽早加入
绝大多数人——大约有60%——都认为敏捷就是迭代（或是Scrum术语“sprint”）。这种情况有些令人失望，因为他们并不知道：早在25年前，Barry Boehm就提出了迭代开发的概念，不过称其为螺旋式开发。
更
令人失望的是，人们并不知道Rational Unified Process
（RUP）其实不是迭代开发，而是基于瀑布式开发的模型。事实上，如果你真的要用RUP来进行瀑布式开发，那么你还得在重组RUP上花些精力。我们明确认
为：所有的开发者们都应该转向迭代式开发，因为它和人们喜欢的敏捷具有相同的特征：快速、能够产生可用的软件、接受变化、灵活性、风险保障等等。
既然60%的人都认为敏捷就是关于迭代开发，而且RUP的设计初衷就是用来支持迭代式开发的，那么RUP就等同于敏捷吗？我并不这么认为。RUP可以用敏捷的方式应用，但是它本身却并不是敏捷。想变得敏捷，还需要更多的东西。
20%的答案与技术相关，包括特征驱动、测试驱动、用户故事等等。然而，这些理念不能单靠自己就引发开发的革新。
而与“轻量级”相关的答案占了10%：易于理解、易于应用、易于生成文档。现在我们算是要涉及到敏捷的核心内容了。我确信过去我们曾对描述过程、采纳大量过程和文档有着过分的期望。
然而事与愿违，事实是即使有人写了很多东西，也不会有多少人看。因此保持轻量级的趋势会一直持续下去。不过，要变得“轻量级”很容易。关键是不要变得过分“轻量级”。在这方面，我相信你会发现我们在EssUP和EssWork上的工作非常地新颖。
最
后10%就是关于如果保证开发人员每日、每周、每月甚至更长时间地紧密工作。这关系到沟通、人和团队，关系到如何组织团队、如何决策、如何保护团队不被外
界环境干扰。这些学问被我们称为社会工程学。敏捷早就指出，想在软件开发上有所成就，团队中就需要有活跃的成员和能胜任工作的员工。没有哪个流程能够把软
件开发出来，工作总是要由人来做的。一直以来我们都清楚这一点，但是却没有把它放在心上。关注人，是敏捷独一无二的特质，也是敏捷当初得以成功的原因。
其实，人们如何看待敏捷并不重要。它甚至已经成为了一种哲学体系。现在看来，所有好的东西都被称为敏捷，因此想要说清楚敏捷是什么并不容易。不过，人人都想变敏捷（其实人人都应该变敏捷），我们对此心知肚明。总有一天，敏捷之道将行于天下，不需赘言。
不如让我来做个谨慎的预言吧。照现在这个趋势，危险显而易见：敏捷将会名声扫地，因为有人会用它作为工作质量低下的借口，有人会以敏捷之名不收集需求，有人会因为要“敏捷”随心所欲地开发。然而“真正的敏捷”的本质并不是这样的，但是长此以往，敏捷也将背臭名远场。
不管发生什么，在将来的某一天，我们会融入一种新的潮流。我并不能明确地告诉你将会是什么，但是有一点可以确信——它会很明智，非常明智。
本文转自
http://sd.csdn.net/page/7457d292-1fa6-402f-9d68-e9ba7788f509