为了进一步明确这两者的区别，特对比如下：以项目为中心，其核心是以需求立项，带来的主要问题是项目周期长、需求力度大、反馈周期长、多并发项目、团队无节奏，直接结果是无法快速交付对终端用户有价值的产品；相比之下以产品为中心的交付，统筹所有需求、需求力度更小、采用持续滚动计划、团队节奏感更强，从而使得所有成员关注最有价值的高优先功能，持续交付价值。

　　企业创造产品的目的就是要解决用户或企业自身所面临的问题，因此以产品为中心也就是以解决问题为中心；相反，以项目为中心则是以计划、预算和职能为中心。

　　图4: 项目为中心交付流程 vs 产品为中心的交付流程

　　虽然提到要“围绕产品组建跨职能团队”，但是传统金融行业的组织结构是典型的职能矩阵式， 业务部门通常在总部，开发、测试、运维部门分离，物理地理位置上也分离，很难做到理想的敏捷团队同地共置，即使是把开发和测试放在一起，也不容易；再加上外包团队，分布式团队更复杂。如何快速解决这种复杂的分布式团队的敏捷协作问题，各大银行纷纷借鉴学习了ThoughtWorks的Always-on工作模式来构建高效的分布式虚拟团队。

　　图5：Always-on可以帮助分布在不同地点的团队成员虚拟的面对面沟通，及时解决问题。敏捷12条原则中第四条“敏捷在整个项目开发期间，业务人员和开发人员一起工作”，这种Always-on的模式，就是为了实现这个原则。

　　差异化交付模式，是一个能够很好应对传统金融行业在“快”与“慢”的挑战下落地敏捷的一个可选方式。所谓“快”，就是变化快，需要快速响应，及时调整；所谓“慢”就是在已经非常熟悉的领域，可预测性强，需求变化慢。下面详细介绍如何使用这种模式实施交付。

　　差异化的交付模式如下图。模式1进行很多内部迭代，上线之前专门有个Launching阶段，与各个依赖之间进行联调测试，以免出现上线前的集成风险。模式 2结合了LSM（Lean Startup Methodology）以及Scrum，对于一个产品的研发包含：产品的Vision设置、概念剖析、MVP发布以及后续的持续迭代交付阶段。

　　图6: 差异化交付模式

　　模式1：长迭代与版本火车

　　不需要频繁的上线发布，而更强调稳定性。因此在每一个版本周期内以小瀑布方式完成计划、设计、开发和测试，并准备发布。开发过程以2到4周为迭代，可以在每个迭代结束时给业务和产品负责人做一次演示，尽早获得反馈；也可以更好的支持敏捷团队尽早开始联调测试。每年固定4或6个版本火车，各产品的版本节奏基于版本火车时间点对齐，利于进行跨产品间集成的协调和共同上线。某国际银行的Core Banking核心后台业务，atv，也希望进行敏捷转型，选择了适合的模式1。

　　图7:版本火车

　　模式2：在进入迭代开发之后，就是传统的Scrum流程，迭代开发、持续交付。

　　作为前台系统，经常要与核心中后台系统做对接，差异化的两种模式进度如何匹配？具体实施方式如下：

前后台Scrum团队密切合作，建立Scrum of Scrums机制，定期沟通，互相协调配合，提前规划好依赖日历，明确好先后顺序，并且避免两边需求偏离太远；

从项目第一天开始进行系统集成，及时发现问题；

有时候后台资源不足，这时候采用Mock服务的方式，先保证前台的功能满足业务需求，而后根据中间层的Contract ，作为接口需求，与后台系统集成；

在上线前，后台会有长期的System Test、UAT 时间，这时候前台的开发计划尽量匹配后台的 ST 进行测试，以免出现上线前的集成风险。

　　图8:差异化交付协作方式

　　所有应对之策结合使用，其全局效果如下：

　　图9:应对之策全景图