一个版本的前世今生

说明：本文章是一个示例稿，从配置管理角度出发，结合项目管理工具redmine，阐述了一个版本的起因、形成、测试和发布的过程。过程中示例的内容（特别是部门、科室中的工作描述和处理过程）为非规范内容，仅作为承上启下，对系统项目的开展、任务分解、管理衔接进行说明，流程上形成闭环并成为一个整体，从配置管理角度指导系统项目负责人按照规范过程进行参考、使用。

一、源起

1. 业务需求

部门开发任务主要来源于业务需求，是全行各个业务部门或金融科技部内部为实现业务开展需要，新建系统或调整现有系统功能，用程序工具等实现并提供全行使用。业务需求一般以联系单或ITIL开发需求的形式存在，目前，需要进行需求分析，并由架构室统筹管理。

2. 系统优化

部门现有系统会存在一些缺陷（Bug）或不涉及业务功能的系统优化，这些内容会使系统的使用者遇到问题，存在一定的错误或不符合实际使用期望，使用者希望解决解决他们，由部门进行牵头验证、排查并处理。系统优化大部分来源于各业务部门，由于业务部门无法区分是否为业务需求、系统缺陷或非业务功能的系统优化，所以此类问题仍然以业务需求（开发需求）被发往部门，需要对应的系统进行需求分析，如涉及业务需求，由架构室进行需求统筹；如为系统缺陷或非功能性的系统优化，则由对应的系统牵头开发解决。还有一部分系统优化由金融科技部内部发现，体现在开发自测或测试人员在日常工作中发现，由对应的系统直接转换为开发任务进行解决，随版本上线进行修复。

二、前生

一个版本的前生要经过需求分析、需求审核、任务分派等过程，即业务需求或系统优化要经过分析和审核后形成任务分派，确定相关系统的版本内容、排期、工作量等属性信息后，拟定计划并执行。期间，前期可能要经历需求讨论、技术方案评审、设计方案评审和架构管理等，后期可能要经历开发规划、测试规划和投产规划等，中间穿插一些项目管理、质量管理方面的内容。

1. 需求分析

需求分析是对业务需求或系统优化的处理，一般由架构室进行统筹，以ITIL中需求服务台的形式处理。对于明确的业务需求，由架构室直接进行需求管理；对于不明确的非业务需求，由应用支持室统筹，经系统分析师完成需求分析后，将分析后的结果归类汇总，通过领导审核并转开发进行处理。需求分析过程包含需求讨论、技术方案评审、设计评审和架构管理等。

2. 需求审核

需求分析后，需要对分析后的结果、规划、任务分派内容进行审核，审核通过后执行任务分派。

3. 任务分派

需求审核完成后，任务分派生效，按照需求分析后内容、规划进行任务分派并执行。

注意：需求分析、审核、任务分派均在ITIL中完成，redmine仅作为挪移展示，使示例更顺畅，同时任务分派中添加了测试任务，使得任务更全面，并派生了过程中的质量室和应用支持室任务分派。

三、今世

一个版本的今世要经过开发设计实现、测试执行、上线投产等过程，即业务需求或系统优化经过分析、审核、计划任务分派后，进入正常的系统开发、测试和投产的常规项目流程。期间，还涉及到开发过程管理、测试管理、配置管理、应用环境支持、质量管理和项目管理等。

1. 开发设计实现

开发设计实现是依照需求分析后的任务分派，有计划的开展开发、设计和实现的相关动作。其中，开发过程管理需遵循相应的配置管理、质量管理、项目管理的要求，如建立版本分支、发布版本提测、质量检查等。过程如下图：

2. 测试执行

开发设计实现后，由应用环境支持对发布版本进行部署提测，测试人员执行任务分派时的测试任务，按照测试案例进行测试执行，围绕测试缺陷进行反馈及跟踪解决，最终出具测试报告。

3. 上线投产

测试通过后，由开发负责人、测试负责人整理对应的上线提交发布包，包含对应版本的程序文件、数据库文件、测试报告、版本部署说明及其他所需文档等，配置管理员针对版本内容进行审核，提交质量室进行上线投产申请，并最终审核通过完成投产。

四、版本全流程示例（结合项目管理软件redmine）

1. 部门任务录入

部门项目管理工具redmine服务器已按组织结构进行调整（http://10.1.121.122），部门任务在金融科技部父项目下进行录入，可全部门人员流转，目前可录入金融科技部部门级别的业务需求（开发需求）和系统优化任务。

业务需求（开发需求）和系统优化任务由ITIL转录，一般由开发中心或智慧创新中心科室对应的系统分析师在ITIL中的任务分派（主办）确定后录入。任务录入后，可在部门层面流转（流转给协办人），同时依照ITIL中任务分派的内容进行任务分派（分派任务以科室系统项目子任务的形式存在，是部门父任务的分解）。

举例：

例1：部门接收到信用卡中心的业务需求：“在微信公众号上线即享金入口”，任务已在ITIL中流转至需求服务台，并分配架构室梁丽金进行需求统筹，经对应系统分析师的需求分析、技术方案评审、架构管理后，任务分派至核心室及渠道室进行开发，对应的系统开发负责人员为张梓鹏（主办）及廖燚。由张梓鹏在部门中录入此业务需求（开发需求），并将任务指派给自己，要求建立对应的科室系统项目子任务。

例2：部门接收到个人金融部的系统优化任务：“关于海珠支行建筑工人工资专户销户问题”，任务已在ITIL中流转审核，并最终分配到核心室处理，由匡濠解决。匡濠需要在在金融科技部中录入此任务，将此任务指派给自己。

2. 科室系统项目任务录入

项目管理工具redmine为所有科室系统项目建立了标准的项目管理路径，项目下涵盖项目的开发需求/系统优化任务，支持项目任务分解及项目工作流转，同时配以项目角色及成员划分，配以wiki等信息协同，项目可以以此工具开展项目工作。

举例：

例1.2：张梓鹏在录入完部门业务需求“在微信公众号上线即享金入口”的任务后，需要按照任务分派建立科室“微信银行”系统项目的子开发需求任务，同时将部门的父任务指派给协办科室系统项目负责人廖燚，建立对应的子任务。

例1.3：廖燚执行相同的任务，并将任务流转给测试中心，如再补充ITIL中的需求处理流程，redmine中的部门任务与科室系统项目子任务构成如下图关系：涵盖规划中心架构室、开发中心渠道室、核心室、测试中心测试室等，总体视图简洁、明确，且可以根据甘特图追踪进度。：

3. 关于需求统筹/分析/审核

此部分已在ITIL中处理完成，redmine中故不做展开，如果需要在redmine的需求中记录及体现此部分内容，形成整体记录，可以对此部分进行补录，如例1.3中架构管理室相关子任务。

4. 关于任务分派

此部分已在ITIL中处理完成，redmine中进行重复录入旨在开展项目工作活动，将任务分发或传递给项目成员。

5. 开发设计实现

任务分派完成后，正式进入常规的项目开发、测试、发布流程。Redmine中标准的科室系统项目统一为如下所示，可参考部门redmine调整中的说明。

任务分派作为系统的开发任务或需求源头，由对应的任务开发负责人进行开发任务分解，拆分给自己或项目组内其他人员完成。即将系统项目开发需求/系统优化子任务（金融科技部父任务）进行任务分解，步骤如下：

5.1 建立/对应版本

系统项目开发需求/系统优化任务需要对应系统的发布版本计划，如版本计划已存在，将对应的任务纳入版本计划下，通知配置管理员版本任务变化；如版本不存在，则通知配置管理员建立对应的版本，并说明版本要进行的任务内容。

举例：

例1.4：系统的开发需求/系统优化任务需要指明计划投产的版本，或在确定开发需求/系统优化任务的投产版本后，将任务纳入投产版本中。找到“在微信公众号上线即享金入口——微信银行部分”任务，指明计划投产的版本。

5.2 确定版本开发分支

版本确定后，由配置管理与系统负责人约定开发分支，或代码基础开发路径。此开发分支或代码基础开发路径基于生产代码基线建立，不同于开发集成分支，仅提交此次版本发布内容，不包含其他版本或其他功能内容。

举例：

例1.5：版本确定后，由配置管理员从系统生产代码基线引出开发分支或代码基础开发路径，版本任务在此开发分支或代码基础开发路径下进行开发及版本发布。

5.3 任务分解

对开发需求/系统优化任务进行分解，分解为开发任务给对应的项目人员完成。

举例：

例1.6：微信银行开发需求“在微信公众号上线即享金入口——微信银行部分”需要4名项目人员进行设计及开发，子任务内容为明确需求，编写需求及设计文档，编码实现及缺陷修复，自测完成及通知发布。张梓鹏将任务分解并分给对应的项目人员，如下图：

注：版本内部分任务（如内部流转任务、WBS颗粒度较细任务）可不指明父任务，以免影响父任务查看。

5.4 版本发布

开发任务完成后，版本发布由配置管理员统一构建打出，并将版本发布包发布至对应应用环境进行部署提测。经历多次版本发布、测试、缺陷修复、验证后形成最终版本。其中，统一构建及持续集成服务器地址为http://186.1.64.106:8080（域账号登录，以redmine系统项目建立），版本发布包存放服务器地址为\\186.1.64.200（域账号登录）。注意：此步骤统一构建最为关键，配置管理接管的系统项目，测试发布包、投产发布包禁止在个人环境中产出，必须在部门指定服务器上统一构建打包产出。

举例：

例1.7：开发任务完成或部分完成后，开发人员可提起代码的版本发布，即在redmine中建立版本发布任务，填写发版信息（版本实现内容、bug修复情况、代码路径、开发人员、部署环境等），然后将版本发布任务指派给系统项目的配置管理人员，配置管理人员发版后，填写统一构建地址、版本发布包位置，然后将任务指回开发人员，告知发版完毕，或直接关闭版本发布任务。同时，在此版本发布任务下建立部署提测子任务，指派给应用支持（环境维护）人员进行部署提测。

5.5 部署提测

版本发布后，配置管理员按照版本内容，依据开发人员和测试人员提供的信息，发起部署提测任务，将版本发布到对应的应用环境使用。

举例：

例1.8：版本发布后，配置管理员发起部署提测任务，指派个系统项目应用支持（测试环境维护）人员进行部署。

6. 测试

目前部分系统的测试缺陷管理在禅道中流转，部分系统仍然使用redmine进行管理。无论是禅道还是redmine都以版本为维度进行测试，以及测试用例、缺陷管理的任务分配，但禅道中与redmine略有不同之处在于，月度版本以版本为主口径，以需求进行测试，而redmine中是以系统（项目）为主口径，由部门任务进行需求间的版本关联，虽表现形式不一样，但实质内容及使用完成相同。

举例：

例1.9：由于在部门分派中已针对开发需求/系统优化进行了测试任务分配，故测试以需求任务为测试执行，编写测试案例，测试缺陷并跟踪解决，缺陷对应所属版本即可。