当今，IT界有很多领导都喜欢灵活性和敏捷性，一些CIO们开始转而使用敏捷开发方法学进行软件开发。敏捷方法学可以帮助组织快速响应市场变更，把开发时间都花在真正的功能上将给企业带来最大的价值。

　　在这个阵营中的公司包括英国航空公司，该公司在2007年转向了敏捷软件开发；还包括资产五亿美元的卡塔丽娜销售公司（CMC），该公司在执行纯敏捷开发失败以后，对一次业务转换工作采用了敏捷和瀑布方法学混合的开发方法。

　　麦克•克劳彻（Mike Croucher）是英国航空的软件工程师负责人，他说：“你能提高生产率的一个关键因素就是速度。第二个因素是业务。看到市场持续地变化，我们意识到我们需要一套能随之快速响应这些变化的流程。”

　　在2009年SearchCIO.com的一份研究表明，在631名参与调查者中，有25%的人表示他们的组织采用了诸如敏捷方法这类快速开发方法学。在采用敏捷方法的群体中，有72%说它（敏捷方法）帮助加速了项目执行，还有25%认为这种方法更难管理项目的结束时间。剩下的13%称没有影响。

　　敏捷开发方法学强调迭代的软件设计，企业涉众和IT项目领导一起工作来确定流程并以短期增量的方式设计。采用敏捷方法，开发团队可以集中精力优先只实现能给企业带来最大价值的那部分功能，因此避免了浪费，还提高了生产率。敏捷方法还能适应在任何迭代过程中快速变更。

　　决定是否采用敏捷还是采用传统软件开发方法学（如：瀑布模型），我们要考虑很多因素，比如：组织的文化，成本和当前流程。瀑布模型从项目初期直到维护期的整个过程中是顺序进行的，强调在下一步进行之前确定确认好需求。

　　克莱•理查森（Clay Richardson）是Forrester研究公司一位高级分析师，他说：“敏捷方法更好，因为它能快速地给企业用户交付功能，在整个解决方案的开发过程中能最大程度地获得关键涉众的信息输入和采纳。此外，由于缺乏跟得上市场的速度，瀑布方法周期太长而且能提供的功能太少。”

　　敏捷开发方法学比较成功的案例

　　在英国航空公司，一开始向业务方面推广敏捷方法时并不顺利。克劳彻说：“英国航空公司完全是委员会驱动的，舆论敏感的环境。快速的决定并不能使他们做的更好。在敏捷的世界里，我们需要业务领导们把这件事作为经常性活动定期参与。”

　　克劳彻和他的团队把公司的网站变更作为了敏捷项目的试点。然而，因为该网站相关工作人员那时还没有准备好加入这一新流程并及时负责，IT把这次经历当作了一个学习过程。克劳彻说：“这次试验暴露了我们下一阶段变革要关注的问题类型。”

　　然后，IT组织转向到另一个项目时尝试敏捷方法，这次是与航空里程业务组有关。克劳彻说：“找到正确的业务单元来开始变成了项目成功和被采纳的基础。”

　　航空里程组管理航空公司的常旅客计划，他们给IT组提出了许多想法。通过采用敏捷方法对功能排定优先级的方法，与这些团队一起增量地列出了计划，该计划提供使客户兑换里程的服务。这种方法让他们看到了客户对他们的新功能反映如何，从而根据哪些有效和无效进行调整。

　　就在最近，英国航空公司在它的收益管理和优化系统中采用了敏捷开发方法，该系统是用来判定航空坐席的市场售价的。

　　克劳彻说：“我们有非常复杂的价格软件，可以根据供需查看飞机上售出了多少座位，并判断价格应该降低还是升高。通过敏捷方法我们可以快速看到增量变更带来的差异是什么，并按其路线发展，而不是积攒成一个很大的变更。”

　　自从结合精益实践实施冥界方法以来，英国航空公司得到了生产力提高和更快的投资回报率双重收获。按照传统情况，它会在项目投资平均九个月到一年的时间才能看到投资回报率；现在它三个月就能看到增量投资回报率。

　　敏捷的挑战

　　敏捷方法同样也是极具挑战的。卡塔丽娜销售公司最后以混合敏捷和瀑布的方法而告终，它在努力业务转型来改变它与客户在杂货店结账票证方面的工作方式时，开始使用的也是敏捷。

　　该公司变更涉及的工作包括修改工作流程，为客户构建Web前端功能，还有连接各种遗留系统的服务层。杰夫•芒（Jeff Mount）是位于佛罗里达圣彼得堡CMC业务流程管理的副总裁，他说公司“没有合适的框架来推行敏捷”。他在最近一次的Gartner研讨会上发言称，项目涉及的课题专家花大量时间全身心投入，一些人不知道如何跳出思维的框框来为变更工作做出贡献。

　　此外，CIO埃里克•威廉姆斯（ Eric Williams）说：“人们不会来参加会议，大家都只关心自己的工作。”（他说，没有人会丢下他们的工作）。

　　威廉姆斯说，结果采用敏捷方法开始就成了一个“严重的错误”，“业务方面不知道它想要什么”。

　　因此，卡塔丽娜公司最终选择了混合模式，利用瀑布模型技术手机需求和产品界面模型，然后采用敏捷方法进行开发。