毫无疑问，敏捷开发方法正在大举进军今天的企业，但是通往敏捷的道路却是崎岖的。它更像是一条多车道的高速公路，各种类型的司机们都在选择各自适合的路线向目的地进发。最近，某网站组织了2008年敏捷趋势调查，结果数据显示，瀑布式开发方法并非总是到达目标的捷径。
在本次调查中，Scrum成为所有敏捷技术中最受欢迎的，选择Scrum方法的高达41%;其次是极限编程(XP)，占到15%。另有14%的被调查者选择了混合使用Scrum和XP，13%的人使用自定义或其他类型的混合敏捷方法。Crystal和动态系统开发方法(Dynamic Systems Development Method，DSMD)都只有3%以下的使用者。
现代人在着装上流行混搭，而现在连敏捷方法也流行混合使用。许多企业有选择地部分采用了最适合他们的敏捷方式，而不是全盘敏捷化。
“现在的敏捷已失去更多技术性的意义，所以，一方面我觉得敏捷在不断地发展，不再是严格的XP或Scrum，而是在可以其中进行适合自己的修改。”Justin Gehtland，Relevance公司总裁及创办人之一，这样说道。
“Scrum是其中最简单易懂，并且易于采用的。”IBM敏捷开发实践的负责人Scott Ambler谈到：“Scrum实施的重点是团队领导和需求管理，它既不像XP必须有深入地技术实践，也不像统一过程必须覆盖整个生命周期的每一个细节。”
Ambler也认为：“没有一种方法可以涵盖一切。所以，我的建议是类似Scrum的方法只是整个过程中的一部分。而你所遵循的过程必须适应你所在的环境。众所周知，Scrum是不够的，XP也是不够的，敏捷建模同样是不够的。他们都只涉及整体过程中的部分。所以，你有两个选择：你可以把自己用到的Scrum、XP等方法进行最佳组合，并重新对其改造以适应自己的需要;或者你也可以直接采用RUP(Rational统一过程)，并对其进行裁剪以满足自己的需要。”
总部位于加拿大多伦多的LYNXDev公司就是这种“按需选择”方式的很好的例子。该公司为金融服务行业提供商务解决方案。该公司的系统架构师表示，“作为一家规模不大的ISV，我们会与很多金融机构有直接的接触。我们发现，客户常常要求我们采用基于RUP的开发方法。但是，我们也发现，这种基于RUP的方法所固有的过程和管理成本并不适合我们的应用环境。因此，这样一个基于RUP的方法所能带来的效果是有限的。通常情况，我们最终会采用一种改进的RUP或敏捷方法。尽管我们并没有使用一种正式的敏捷方法或过程，但是我们借鉴了敏捷方法的概念，将其用于整个开发过程中。比如，我们使用RUP方法的某些方面，将其用于满足一个极短开发周期且不那么正式的需求。”
位于加州的Ajira公司是一家服务流程管理解决方案提供商，它也同样通过混用匹配的敏捷方法，来适应自己的需要。公司CEO Nari Kannan表示：“我们并不盲从大量所谓的方法。我们挑选能真正对我们有用的方法。对于选择的这些方法，我们也不会教条式的照搬照做，好像在每周的同一时间去完成一套仪式一样。有时，我们会做每周构建;而有时，我们可能要隔上几周才做构建。因为如果有大量的特殊功能需要实现，可能得等上几周才能让构建有意义。所以，我们非常注意保持这种灵活性。”
坚持瀑布式开发
也有很多其他企业没有选择敏捷开发的路线。
“据我所知，健康网没有正式大规模使用任何敏捷方法，但我相信，我们的一些Web团队已经开始在他们的小规模项目中非正式地使用到迭代方法。”Cooper Zale，该公司系统分析师谈到，“健康网还处在发展成熟阶段，目前我们的第一步是满足所有开发都必须遵循的基本原则。因此，我们采取了传统的瀑布式开发模式，事实上，我们是在整个公司范围内实施该模式。”
选择瀑布式开发的公司远不止Zale一个。在这次敏捷调查的被访者中，采用瀑布式开发和敏捷开发的人数旗鼓相当。其中，有45%的人选择敏捷方法，而44%的人在使用瀑布方法。其他的开发方法中，测试驱动开发(TDD)占到19%，RUP则占15% 。
Ambler认为：“瀑布方式是不会消失的。其普及程度肯定在萎缩，这是因为它不再如以前那样有效。但仍然有很多企业在坚持这种老方法。这一方法让他们感到更为舒适，这是他们所熟悉的方式，而且他们对这种方法带来的效果也很满意。虽然新方法可以让他们做得更好，但是这需要时间。而迭代成为向这个新方向迈出的第一步。”
在Ambler看来，企业不可能简单一步就切换到敏捷方法。“对于IBM，这也经过了多年的过渡。”他谈到：“我们是目前世界上向敏捷过渡的最大的公司，可以肯定，今后5年内，我们仍会有瀑布式开发团队的存在。” 。
选择敏捷要灵活
对于那些还没有开始选择敏捷路线的公司，情形又如何呢?数据显示，在目前还未使用敏捷方法的被访者中，有超过60%的表示他们对敏捷方法很感兴趣。
尽管如此，Ambler仍然认为，不是所有项目都能实施敏捷，“是否选择敏捷需要一定的灵活性。你必须明白真正的问题和挑战所在”。
此外，我们知道，“敏捷”对于不同的团队、不同的项目有着不同的含义。如IBM公司Rational部门的总架构师Per Kroll所言，“敏捷在不同的项目中意味着不同的东西。对某一个项目作用巨大的敏捷，却不一定能对另一项目起到同样的作用。”
