目前国网公司信息化项目大多采用瀑布模型, 将软件生命周期划分为可研、需求、设计、开发、测试和上线运行等6个基本阶段. 国网信息化项目需求相对明确, 采用瀑布模型有助于提升人力分配和项目进度计划的准确性, 有效规避或者减少项目开发风险.

由于瀑布模型的下一环节依赖于上一环节的交付成果, 所以这类项目通常交付周期较长, 导致用户需求无法快速得到响应, 甚至在交付完成后用户需求已经发生变化或不能满足用户当前所需, 影响用户满意度; 国网目前信息化流程中需求评审、概要设计和第三方测试测试以及上线试运行环节相关干系人较多, 流程花费时间较长; 早期的错误可能要等到开发后期的测试阶段才能发现, 增大了修复完善问题的代价和成本.

为快速响应和满足用户需求, 缩短系统建设周期, 避免因业务变化导致的开发工作浪费, 保证产品交付质量, 国网公司决定研发敏捷转型, 选取经法2.0系统、人资2.0系统作为敏捷迭代开发试点项目. 以用户为中心主动创新、敢于试错, 着力推进系统的敏捷迭代、小步快跑, 创新优化系统建设模式. 试点项目通过迭代梳理用户需求、迭代研发、迭代发布等方式, 实现用户需求的快速上线, 缩短项目整体交付周期. 目标是通过敏捷转型实现快速高质量的完成项目交付, 并总结转型经验同时梳理出适用于国网敏捷项目的制度、标准、流程以及相关的支撑工具.

1 工作思路

转型到敏捷不是否定国网前期信息化建设思路, 而是在充分借鉴国网公司现有信息化成果和相关流程规范的基础上, 结合敏捷和精益的思想对现有流程和规范进行参照、完善或裁剪. 项目按照Scrum敏捷开发模式, 遵循高优先级的需求驱动原则, 依托公司统一研发环境, 利用云效DevOps平台, 实现迭代开发、增量交付、灰度发布.

1.1 Scrum概述

Scrum^[1,2]这个英文字母来源于橄榄球运动的一个专业术语, 表示“争球”的动作. 在橄榄球比赛的每次冲刺前, 都将有一个计划安排的过程, 但冲刺开始后则由队员在原计划的基础上随机应变(Scrum框架如图1所示).

Scrum是用于开发、交付和持续支持复杂产品的一个框架, 是一个增量的、迭代的开发过程. 它不同于传统瀑布模型开发过程, 而是由若干个短的迭代周期组成, 每个短的迭代周期称为一个冲刺(Sprint), 每个Sprint的建议长度是1–4周. Scrum团队总是先开发对客户具有较高价值的需求.

1.2 云效DevOps平台

云效DevOps平台(见图2)主要涵盖了研发环境支持、流程贯通、项目管理、发布部署支撑等功能, 能够实现项目全生命周期管理.

1.3 工作思路

1)需求梳理. 明确业务蓝图, 结合用户需求优先级明确分阶段开发任务; 明确每个阶段的详细需求; 对各阶段需求进行原型设计.

2)设计. 采用微服务、微应用的技术路线实现各业务模块间的解耦, 实现各业务并行开展.

3)开发. 先把底层功能以传统模式快速开发完成; 业务功能分阶段迭代开发; 每个阶段再根据业务优先级列入开发计划, 实现核心功能优先开发上线; 上线功能根据用户反馈迭代完善.

4)测试. 开发过程中使用统一研发管控平台进行UI自动化、接口自动化等; 具备条件的项目可由业务部门或试点单位关键用户完成用户确认测试工作.

5)发布. 首次部署前由研发单位向国网信通公司提交软硬件需求申请及部署方案; 后续每次迭代测试通过后, 由研发单位按照国网信通公司要求提交部署申请, 按照信通公司要求完成迭代部署; 通过云效DevOps工具实现项目发布; 系统部署完成后由红队进行生产环境进行安全扫描.

6)上线运行/迭代完善. 通过问答机器人、在线客户及后台自动信息收集等多个渠道获取试点单位用户使用情况; 试点期间安排实施人员在客户现场贴身用户实时反馈用户使用过程中的问题; 通过不断迭代做出功能完善、客户满意的系统.

7)分析小结. 每次迭代完成后对迭代过程中的问题进行总结分析, 找出有待的改进工作项, 逐步完善; 将各个环节收集的问题进行闭环跟踪, 确保所有问题、建议都能按时处理.

8)验收. 依据最终系统功能与可行性研究报告的对应情况; 系统实现与技术方案、安全防护方案的遵从情况; 最终用户反馈的使用情况.

2 实践过程和做法

本论文主要探索敏捷开发模式下如何做好研发质量管控, 达到及时响应客户需求的同时, 提升产品交付质量. 实践过程共分前期准备阶段、执行阶段及探索优化阶段3个阶段开展.

2.1 前期准备阶段

选定经法2.0和人资2.0项目作为敏捷转型试点项目, 组织调研银行、航空^[3]、大型国企、央企等单位敏捷转型实践过程, 并阅读大量敏捷相关书籍及论文^[4-18], 最终编制《人资与经法项目敏捷研发工作方案》.

方案制定后, 经法2.0项目、人资2.0项目分别组建各自试点项目的敏捷团队, 敏捷团队含项目经理、敏捷教练、产品经理、技术经理、产品团队、开发团队角色.

2.2 执行阶段

下述执行过程以经法2.0项目为例, 通过敏捷转型结合云效DevOps平台来提升软件质量.

与用户沟通, 获取重要的、关键的、标志性的时间节点或事件, 分析里程碑关键节点, 协助用户制定里程碑计划, 来控制项目工作进展和保证实现总目标(见图3).

创建产品待办列表(见图4), 产品待办列表以用户故事的形式来表达. 用户故事的来源不限于用户需求, 也可以是迭代过程中产生的新需求或者系统上线后用户提出的问题, 产品负责人和需求分析师需要对需求池中的用户故事进行持续更新维护, 用户故事积累到可规划1–2个迭代时, 由敏捷教练组织召开需求澄清会.

产品待办列表建立后, 通知敏捷团队所有成员提前熟悉用户故事, 以便召开需求澄清会时能充分的提出问题和建议(见图5). 拆分用户故事与维护产品待办列表都是一个持续的过程, 每当产品负责人澄清完成用户故事, 技术负责人则带领敏捷开发团队, 拆分用户故事, 制定对应工作任务, 并完成任务工时的精准估算. 工作任务要落实到具体的责任人; 任务粒度要小, 工作量大于两天的任务要进一步分解(见图5).

产品负责人按照需求优先级及里程碑计划, 对交付的产品进行版本规划, 明确每个版本的交付内容和交付目标.

由敏捷教练组织迭代计划会, 团队全员参与, 保证所有人对需求的理解和交付所需的任务达成一致, 并根据工作量和需求优先级确定迭代周期(一般每周/每两周设置为一个迭代周期)和迭代一交付内容(见图6).

在迭代详情页面, 可以看到迭代的起止日期, 预计总工时和实际工时、总体进度还有工作项完成进度等信息, 方便管理和评估迭代进度(见图7). 进入迭代开发阶段, 技术负责人组织敏捷开发团队, 依据迭代待办列表、用户故事、迭代计划等, 开展详细设计工作.

敏捷开发团队根据用户故事、工作任务、详细设计等文档, 完成业务功能实现. 过程中, 坚持每日站会, 为敏捷团队提供了面对面交谈的机会, 来协调当天任务的优先级和识别任何出现的挑战, 站会时利用看板向所有敏捷团队成员展示当前迭代的状态, 跟踪项目进度(见图8).

代码编写完成后, 进入代码审查阶段, 检查代码的一致性、编码风格、代码的安全问题、代码冗余、是否正确设计以满足需求(功能、性能)等.

代码提交后, 云效平台创建自动化流程项目, 自动化流程项目构建脚本代码如下:

//自动化脚本代码第一步: maven代码编译打包

/usr/install/maven3/bin/mvn clean install

-Dmaven.test.skip

//自动化脚本代码第二步: 构建docker镜像包

1. 登录云效平台Docker Registry

$ sudo docker login --username=xx

cr.registry.res.sgmc.sgcc.com.cn

2. 构建镜像

sudo docker build -t packageName.

3. 推送镜像

$ sudo docker push

cr.registry.res.sgmc.sgcc.com.cn/jingfa/packageName:1.0

推送到阿里云镜像仓库, 然后发布程序, 对本次提交的内容进行代码自动化扫描, 检查代码的规范与安全性. 开发人员根据代码扫描问题列表, 修改代码缺陷.

后端开发工程师根据业务逻辑, 编写单元测试用例, 验证代码的行为是否和期望的一致.

测试人员先维护测试用例, 再通过云效平台自动化接口SAT测试工具, 检测系统前端页面与后端代码的接口功能是否满足功能要求, 重点是要检查数据的交换, 传递和控制管理过程. 根据前后端接口文档, 编制测试用例, 编写自动化测试脚本, 定时执行脚本进行接口正确性测试(见图9).

测试人员先维护测试用例, 项目组内评审, 再采用手工测试或者云效平台UI自动化工具, 完成系统功能测试, 同时对缺陷进行管理(见图10).

在以上测试都通过后, 合并各分支, 利用集成工具, 开展集成测试工作, 利用UI自动化工具, 开展自动化, 确认各分支集成成功.

在每轮迭代结束后举行迭代回顾会, 目的是分享好的经验和发现改进点, 促进团队不断进步, 下一批次迭代顺利. 会议需要Team全员参加, 气氛宽松自由, 畅所欲言, 头脑风暴发现问题, 共同分析根因; 会议关注重点是Team共同讨论优先级, 将精力放在最需要的地方; 会议结论要跟踪闭环.

2.3 探索优化阶段

本阶段对上述具体实践过程做总结分析, 并探索优化敏捷开发流程, 包括初期团队组建, 过程中应用“回顾反思”“头脑风暴”“5WHY”“PDCA”等工具, 项目管理过程线上化, 云效DevOps平台运用等. 同时将经验总结运用到后续迭代过程中, 从而提升软件质量.

3 建设成效 3.1 项目管理提升

经法2.0、人资2.0系统利用统一研发管控平台执行项目管理, 与传统模式相比, 管理方式从分散走向集中, 实现全线上管理, 包括需求管理、迭代规划、里程碑管理、任务管理和缺陷管理等, 同时线上支持度量可视化、多人协作, 提高沟通效率.

3.2 流程化管理提升

经法2.0、人资2.0系统充分借鉴国网公司现有信息化成果和相关流程规范的基础上, 结合敏捷和精益的思想对现有流程和规范进行参照、完善或裁剪, 简化流程. 按照Scrum敏捷开发模式, 遵循高优先级的需求驱动原则, 依托公司统一研发环境, 利用云效DevOps平台, 实现迭代开发、增量交付、灰度发布.

用户需求优先级分批次的进行梳理, 梳理一批、确认一批、开发一批, 拥抱变化(见图11).

3.3 研发质量提升

经法2.0、人资2.0系统使用国网云、国网SG-UAP开发平台、云效DevOps平台开发、持续集成及部署, 保证研发质量.

1)统一使用国网SG-UAP开发平台进行开发, 保障程序各依赖包的兼容性和安全性;

2)定期开展代码审查, 目的检查代码的一致性、编码风格、代码的安全问题、代码冗余、是否正确设计, 保障提交流水线前的代码质量;

3)通过创建研发流水线, 保障研发过程透明、安全可控;

4) UI自动化、接口自动化、单元测试自动化等功能保障业务实现的正确;

5)代码静态扫描与源码安全扫描工具保障代码质量和安全;

6)流水线自动化构建, 利用自动化脚本, 保障多环境部署无失败;

7)项目部署在国网云上, 利用容器化技术, 实现快速部署、版本快速回退; 对服务的各项运行指标进行整体监控, 保障项目的高可用性、稳定性和安全性.

3.4 研发效率提升

使用统一代码仓库管理研发代码及分支版本, 避免各项目组手工自建; 强化项目版本管理及风险管理; 在开发过程中对业务系统功能进行自动化回归测试, 强化代码质量; 测试完毕后自动发布至生产环境.

4 结语

敏捷转型是一场变革, 充满挑战. 这场变革是全方位的, 不仅是流程, 开发方法, 还是思想上的. 通过敏捷开发模式能够极大提升软件质量, 仍然需要持续探索优化从而更大程度提升软件交付质量.

(1) 敏捷领导力培养很关键. 人的重要性不言而喻, 在敏捷变革这样有挑战的工作中更是如此. 变革的成功与否取决于变革关键角色的能力.

(2)包容失败, 打造互信的团队氛围. 敏捷强调持续探索和快速验证, 而探索验证可能会伴随着失败, 敏捷团队通过回顾会议反思, 总结经验教训并列出改进计划, 以便在后续迭代中能做得更好. 在转型过程中我们发现互联网上的敏捷经验大部分是ToC的和ToB的项目有着非常大的区别, 国网公司大部分业务用户是兼职做信息化, 投入时间和参与程度无法得到保障. 经过多次讨论, 我们提出了业务迭代与研发迭代双环模型. 将研发迭代的思路借鉴到需求设计环节, 通过现场频繁的沟通确认实现业务层面的快速交付, 通过研发迭代实现软件层面的快速交付. 通过双环模型的运转逐渐提升了双方的信任, 避免了相互指责推诿的情况, 提升了工作效率和质量.

(3)信息共享, 打造透明的团队. 敏捷团队通过电子屏展示总体工作目标和当前工作进展情况, 使得团队每个成员对项目目标由清晰认识, 知道自己所做的每一项工作都是为了目标更好的实现; 通过每日站会的信息共享机制不仅可以减少团队沟通成本而且有利于团队的协作效率的提升, 助于管理人员对迭代进度的判断跟踪, 强制性的站会机制也有利于提升员工的团队意识.

(4)采用渐进地适应性方法. 敏捷是一种变革. 变革不可能一步到位. 敏捷的精髓是不断改进和适应. 敏捷只提供了一套价值观和基本框架, 所谓地一些最佳实践也是别人地实践. 一定要根据团队的实际情况进行适应性调整, 摸索, 才能找到适合本团队的方法. 只有经过逐步改进, 同时注意培养团队的能力, 特别是关键角色(PO, Scrum master)的能力, 才能渐进的实现敏捷的转型.