敏捷项目不宜过大,尽量分拆成若干相对独立的模块或子系统去实施,否则对版本管理,迭代发布都会带来弊端。系统架构上,也尽可能模块化,微服务是个很好的选择。
根据以往的经验,软件的文档不是越多越好,但是关键的文档一定不能缺,主要的业务流程图,资金清算流程图,数据库设计,接口设计,配置文件,模块或服务设计等。看板讨论对敏捷也有很大的帮助。
敏捷方法,首先要解决传统的立项模式,瀑布式的立项模式不适合敏捷,另外敏捷要求科技和业务充分融合一起。在一些要求快速交付的领域可以试点敏捷,比如手机银行,网银等渠道环节,和互金公司合作的各类产品,贷款,支付清算等。
顺利推进互联网核心建设,一般需要组建独立的开发团队,10到20人规模(看编制了),在预算方面,建议采用年度预算制,避免过长的立项周期;人员配备方面可考虑有网银、核心、网上支付等接近互联网应用的不同人才梯队(让银行去挖互联网
互联网核心主要是为互联互通的复合型金融场景提供账户服务及清算结算服务,规划及建设的起点要高一点,务必要考虑敏捷开发,快速迭代,高并发,7x24等特性,否则容易蜕变成传统核心的影子,另外在网络贷款的支持方面,各家行可能有不
过去的十几年,银行的架构在ESB总线方面进展还是不错的,建立了完备的架构体系。但是未来十年,微服务化的架构会是银行的一个尝试热点,特别是应对大并发的互联网接入。
互联网化核心的一些看法:1、银行的第三代(姑且这么称呼)应用架构体系,建立了相对清晰的层组,有5层的,有7层的;层组之间分工及定位非常清晰,一个项目或者产品需要开发时,一般根据当前的应用架构定位进行分析,由不同的应用系统进
双模架构,可以分两个维度理解:一、实现时开发模式:1、银行传统的瀑布式开发模式:1提需求--〉2需求评审 --〉3可行性方案--〉4项目立项--〉开发测试;2、敏捷开发模式:年初确定一个大的预算投入,科技和业务融合在一起,减少1-4这
感谢各位专家的专业精彩回复。银行也在特定领域里,尝试采用独立小团队敏捷开发模式,业务和技术一体化。DevOps在银行落地将是一个长期探索过程,新型互联网银行包袱小,起步会更快一点的。 另外微服务,容器,持续集成等新技术
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30