不论你是测试人员、开发人员还是普通人员，可能都熟悉预定航班和航空旅行的麻烦之处。软件测试人员和开发人员经常成为类似调度和迭代问题的牺牲品。每个人都想在享受旅行之时以最快、最小的压力顺利起飞。

　　当英国航空公司（BA）在软件开发上经历了起飞的问题，软件工程师Mike Croucher被召来寻找一种方式将这些问题快速地挑选出来。他发现尽管愿意并能胜任开发团队，但仍然存在严重的组织和沟通问题。这些毛病延迟了应用交付，拖延测试并增加了新功能特性的剩余，这些功能被强迫放到次要地位。尤其，BA需要改进交付时间表、雇员追踪和BA网站的很多方面。

　　Croucher拥有30年的航空软件开发经验。事实上，他已经作为IT 关系经理为BA进行工作。作为首席软件工程师，他分析了BA的开发流程，他说：“我意识到我们的迭代的创建和部署存在的缺陷。我们失去了灵活性和可预测性的好处；每件事情就像贫瘠的脚本。”

　　Croucher建议转向敏捷开发。他自2002年第一次听说敏捷便热衷于此。他表示：“那时候，许多开发人员探讨精益生产，在迭代中提供可扩展性。”

　　其次，Croucher的团队着手寻找和雇佣声誉好的公司来解决BA转换向敏捷的问题。五个主要的敏捷咨询公司得到评估，但是BA选择了emergn。

　　Croucher和emergn的咨询师就开发的一些区域达成一致，这些区域中不适合选择敏捷，或者说在一些情况下，甚至在一个选项上不适合选择敏捷。Croucher 说：“我们的组织中大概25%已经转向敏捷。这个数字还在增长；但是在增长的过程中，我们界定的数字区域，我们确定瀑布式开发是唯一选择。”

　　BA在许多需求不能变更的领域选择使用瀑布式方法论，这些领域用户社区始终确定并且现有基础设施在一种不能超越的水平上运作；主要运作的集成软件围绕SOA基础创建。Croucher 解释道：“这些‘大锤’领域有很极大的连续的集成需求，没有地方讨论或者进行障碍测试。”

　　所以问题就来了，“你如何知道对于主开发动，何时敏捷是最佳的选择呢？”

　　Croucher建议这些领域包括你的用户基础要求速度、灵活性以及面向自定义的设计；当你确定区域，小的功能可以进行开发或者易于开发。

　　在初期敏捷过渡任务完成之后，项目更换了齿轮，开发团队集中于改进BA.com的其他功能，包括改进在线航班预定、空英里计算和BA网站频道。引导理念不会改变客户对于BA.com的体验。

　　将开发项目转向敏捷协助BA在八周内产生想法，在此之前，项目采取了九个月的时间进行交付。