问题的背景：
在传统银行的软件中心，随着移动互联网的飞速发展，互联网公司给传统银行带了巨大的冲击，很多机会往往转瞬即逝，传统的开发方式难以适应互联网时代的飞速变化。传统银行开始引入敏捷的开发模型，试图解决这个问题。
然而，目前在银行内部，有类似核心系统的大型集中式架构系统，也有在互联网发展洪流中创建的面向互联网渠道的分布式系统及移动端应用。
自然而然地，后面一类系统的开发开始尝试敏捷开发模型，然而，在采用敏捷的过程中，他们逐渐发现了如下的问题：
有很大一部分项目，关键的交易路由都需要走到传统银行部分的系统，而这些系统所采用的开发方式仍旧为瀑布式的。敏捷模型下，对需求拆分逐个迭代开发带来的快速交付优势，由于对传统银行系统的依赖，这种优势不但没有发挥出来，反而成了制约敏捷推行的掣肘，并且对团队的信心造成冲击。团队成员逐渐开始怀疑敏捷、迭代的正确性。
事实上，敏捷的推行者似乎在推行之初就意识到了这个问题，他们创造了所谓的开发敏捷。开发敏捷指的是仅仅在开发阶段的采用敏捷的方式，开发完成后，与采用非敏捷开发方式的系统一同进入功能测试阶段进行测试。开发阶段的敏捷仅仅解决的是开发问题，而并非整个项目的快速交付问题。因此本质上，开发敏捷并没有解决一开始提到的问题。仅仅是对团队内部的开发方式进行了改造。这种改造带来的优势，通常被采用开发敏捷团队内的成员总结为，更少的审计文档编写。大家似乎清晰或模糊的认为开发敏捷并没有从本质上解决问题。
随着企业内敏捷文化的推行，传统银行尝试在部分系统采用全敏捷的方式，即采用彻底的敏捷，将开发和测试共同融合到迭代内，使得在每个迭代结束后得到是可以交付的产品。但前面提到的采用瀑布式开发模型的系统对采用全敏捷的系统所带来的掣肘在此时并没有解决。因此，采用全敏捷的系统在每个迭代后交付的产品仍旧是不可用的。本质上这种更加激进的试验从项目角度，仍旧没有解决任何效率问题。所带来的仅仅是部分系统对功能测试阶段交付的可测试产品的省略。甚至，这种试验向全敏捷的系统提出了一个全新的问题：如何将迭代与传统的开发-内测-功能测试-交付两个模型进行有效的啮合，以在最终交付一个保证质量的产品？很明显这个问题不应该由采用敏捷开发方式的团队去解决，而应该有引入敏捷的人在引入之前就解决，而不是抛给开发团队，尝试用沟通、责任心、主动这些无法衡量的东西去弥补。
那么敏捷难道是彻头彻尾无用的吗？
很明显不是。从上面面临的问题可以看出，采用敏捷的前提是对非敏捷开发团队的依赖，因为一旦产生了这种依赖，敏捷不但难以推行，还会引入其他的问题。那么要解决上面敏捷要面临的问题，办法似乎呼之欲出：
第一种，让采用传统开发方式的系统采用敏捷。但是这种方式真的能最终解决问题吗？如何解决两个独立的敏捷团队之间的同步，似乎并没有给出解决方案。
第二种，适应瀑布开发方式的系统，仍旧经历功能测试阶段最终进行交付。在开发迭代过程中引入迭代内测试，并且将那些不依赖其他系统的功能在迭代内完成功能测试，降低功能测试阶段的成本。
但是，很明显，上述两种方案似乎都并没有对根本的问题：快速交付可用的产品，给出可行的解决方案。或许这需要更多的探索和思考。
事实上，敏捷的开发方式，在没有那么多外部依赖的项目或者产品上是非常适用的，是经过很多验证的毋庸置疑的。
而传统银行如何解决目前面临的问题，似乎还需要进行不停的探索。