上海银行统一版本与敏捷开发的实践

商业银行科技的核心价值在于既快又好地为业务发展提供系统支撑。随着银行业务的不断扩展、管理要求的不断细化，单人完成全流程的开发方式渐行渐远，在多个人同时在多个应用上进行开发的情况下，对于各应用开发投产的统一管理日益重要；而业务的特性，尤其是近期互联网业务创新的特性又要求应用系统快速响应变动。由此，如何在统一版本管理的基础上实现特定业务的敏捷开发投产，达到质量与效率的双赢成为我们研究的重要课题之一。

做好变更管理是内在要求

　　版本管理强调计划性。在目前商业银行应用体系相对复杂、多项目开发任务同时实施的情况下，每个版本从计划确定到投产的整体周期较长；而敏捷开发则要求适应变化、快速开发、频繁交付、实现小周期的快速循环，版本确认周期较短，甚至要求打破整体版本进行单独实施。

　　在互联网业务风起云涌之前，整体版本管理过程中的变更同样存在。但此前银行业务或产品创新周期较长，往往可以加入整体版本进行管理。久而久之，一谈到版本管理，更容易想到防止变更、控制变更，忽略了变更管理这项重要工作。

　　如果将版本管理目标设定为防止变更，版本管理与敏捷开发从根本上不相容，后续各项管理控制措施也就无从谈起。要实现版本管理与敏捷开发的结合，获得质量与效率的双赢，内在要求是正视变更存在的合理性，做好变更的管理。

　　我们统计2016 年上海银行变更比例发现，做好变更管理，投产比例、质量（生产问题比率）基本保持较理想的情况。

　　变更管理工作包括持续评估、任务分解（基于尽可能松耦合情况下）、估算占比、资源预测、分析变更价值、控制无效变更、变更风险评估与控制、变更后评估等一系列动作，即在送预留合理的变更资源用于满足合理的变更需要。

　　围绕变更管理完善版本管理体系，可以不断提升版本统一管理与敏捷开发投产的契合度，实现质量与效率的双赢。

合理的预测与资源规划是基本前提

　　为了在版本推进中有适当资源来满足变更要求，在期初制定版本计划时需要合理预估可能的变更，保留一定量的资源。通常情况下，面对市场和客户的投产时间较短、成熟度较低的应用，新增功能维护要求的可能性较大，要适当地多预留资源；内部管理应用、柜面操作平台、运行时间较长和成熟度较高的应用版本管理较为稳定，计划预留资源可以少一些。

　　市场热点的变动、监管单位的动向、全行战略工作的重点调整往往都会影响版本计划的调整比率。除了根据历史变更比率预估和合理设置各应用的预留资源外，在实际操作过程中需要通过加强与业务部门的沟通，提前了解可能出现的波动，实现主动管理变更，合理预测和做好资源规划。

　　上海银行目前应用版本的总体变更调整率由于市场变化并不衡定，不同应用根据特性不同，变更调整率在15%~30%波动。这些应用在安排期初版本计划时，初期计划工作量按照总产能×(1- 变更调整率) 的模式进行设定。在这种安排下，开发测试资源可以相对充裕地满足各部门提出的版本调整申请，完成95% 左右的变更要求，较好地提升了客户满意度。

适当的风险评估与过程控制是有效保障

　　强调服务业务要求、支持版本管理过程中变更并不意味着无限制地满足业务要求，适当的风险评估与过程控制是实现质量与效率双赢的有效保障。风险评估主要从变更领域与变更复杂度两个方向进行，根据风险评估结果对不同层次的变更申请采用不同的授权管理级别。

　　从应用领域来看，对涉及核心账务、基础平台、公共组件的变更风险较高，影响面较广，需要加强控制其版本调整比率，原则上不支持相关应用的独立投产。在特定需求涉及相关内容时，应尽量协调纳入统一版本管理，或采用临时性的特殊方案进行过渡。

　　变更复杂度方面，涉及单一平台的需求变更风险较低，单一平台开发而需要跨应用调试的需求变更风险较高，涉及多应用平台开发的需求变更风险进一步加大。原则上，涉及多于3个应用平台的变更需求不应该纳入版本变更范围，其中如果一组应用指向同一组业务或服务对象时可以计算为一个。
　　
快速版本功能回归能力是技术支撑
　　
　　由于应用系统的耦合度增加，大量功能的实现都涉及到多个应用的开发。系统间公共接口、公共组件在提升开发效率的同时也增加了变更影响的范围。一个成功的版本，除了实现新功能外，更需要保证现有的功能未受到程序修改的影响。如果说版本的计划和资源管理是保证协作、提升开发效率的基本要求，那么快速的版本功能回归能力是保证版本质量的必要技术支撑。

　　上海银行自2013年组建测试专业团队开始，就启动了功能自动回归脚本的编写工作，将变更频繁度最高的应用、柜员和客户使用频率较高的应用中使用比率较高的交易作为版本回归的内容。目前完成了柜员综合业务平台、理财系统、信用卡系统、银联交易等基本应用中主要交易的回归测试脚本编写工作，并形成了定期回顾和更新机制。

　　通常在版本投产前一个星期按照交易类别，选择其中30% 的交易，花费1~2 天进行整体版本回归测试，对于自动化测试发现的问题，交由功能测试小组进行进一步验证确认后安排后续处理。这一机制可以快速完成敏捷开发模式下，大量版本归并、分拆等操作后的基本功能验证，保证基础功能的稳定性，有效提升版本质量。
　　
开发管理平台是有效机制
　　
　　在我行现有开发体系下，一个业务功能的操作界面、逻辑判断、信息交互、账户/ 合同体系、组织与柜员管理、账务处理、信息报送、数据统计分析往往在不同的应用平台里。在统一版本规划下尚且要花费大量的力气来保证各部分开发测试人员的协同，敏捷开发所产生的变更管理更是产生了大量信息交互与工作计划调整的处理要求，一个便捷实用的开发管理平台就成为了提升版本管理能力的有效机制。

　　上海银行的开发管理平台实现了对版本需求的合理拆解，将工作量和工作计划下发到每个参与者的工作队列中，并提出时间控制要求，从而保证各方人员协同一致。同时，平台还可以提供需求关联应用系统、需求变更情况、需求复杂度等一系列的基本信息，作为后续版本管理后评估的基础数据。
　　
版本实施情况后评估是必须手段
　　
　　只有不断后评估，分析问题、持续优化才能保证机制与实际情况的契合，实现整体体系的螺旋式上升。上海银行在版本管理体系中充分贯彻了这一理念，在每次版本投产后，都对版本的变更比率、变更应用、变更业务、风险估算值、计划达成率等数据进行总结分析，适时调整各方面产能估值、变更比率估值，并分析流程中资源损耗或者风险异常的波动情况，以便后续加强管理的方向。

　　截至目前，通过反复总结与调优，上海银行已在整体应用版本管理体系下嵌入了互联网核心应用的敏捷开发投产模式。该模式支持纯互联网关联应用每月两次以上的投产，并使得互联网相关业务在其他关联应用系统上实现相对快速（两个星期）的“确认—投产”周期。

　　通过加强统一版本管理模式下的变更管理来实现特定业务的敏捷开发投产是当前应用系统非标程度弱、组件化程度低、数据标准性差的大背景下的一种临时过渡性处置模式。长远来说，要应对快速业务创新、灵活定价、差异化营销等新的商业银行业务发展趋势，还是需要从加强业务与技术分析能力，做好体系架构规划，逐步实现需求标准化、开发组件化、应用系统之间的松耦合等基础工作做起，实现开发效率和开发质量的总体提升。

（文章来源：金融电子化杂志）

扫码即可手机
阅读转发此文