馮 東,齊國棟,唐 宇

(北京國電通網(wǎng)絡(luò)技術(shù)有限公司,北京 100070)

目前國網(wǎng)公司信息化項(xiàng)目大多采用瀑布模型,將軟件生命周期劃分為可研、需求、設(shè)計(jì)、開發(fā)、測試和上線運(yùn)行等6 個(gè)基本階段.國網(wǎng)信息化項(xiàng)目需求相對明確,采用瀑布模型有助于提升人力分配和項(xiàng)目進(jìn)度計(jì)劃的準(zhǔn)確性,有效規(guī)避或者減少項(xiàng)目開發(fā)風(fēng)險(xiǎn).

由于瀑布模型的下一環(huán)節(jié)依賴于上一環(huán)節(jié)的交付成果,所以這類項(xiàng)目通常交付周期較長,導(dǎo)致用戶需求無法快速得到響應(yīng),甚至在交付完成后用戶需求已經(jīng)發(fā)生變化或不能滿足用戶當(dāng)前所需,影響用戶滿意度;國網(wǎng)目前信息化流程中需求評審、概要設(shè)計(jì)和第三方測試測試以及上線試運(yùn)行環(huán)節(jié)相關(guān)干系人較多,流程花費(fèi)時(shí)間較長;早期的錯(cuò)誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn),增大了修復(fù)完善問題的代價(jià)和成本.

為快速響應(yīng)和滿足用戶需求,縮短系統(tǒng)建設(shè)周期,避免因業(yè)務(wù)變化導(dǎo)致的開發(fā)工作浪費(fèi),保證產(chǎn)品交付質(zhì)量,國網(wǎng)公司決定研發(fā)敏捷轉(zhuǎn)型,選取經(jīng)法2.0 系統(tǒng)、人資2.0 系統(tǒng)作為敏捷迭代開發(fā)試點(diǎn)項(xiàng)目.以用戶為中心主動創(chuàng)新、敢于試錯(cuò),著力推進(jìn)系統(tǒng)的敏捷迭代、小步快跑,創(chuàng)新優(yōu)化系統(tǒng)建設(shè)模式.試點(diǎn)項(xiàng)目通過迭代梳理用戶需求、迭代研發(fā)、迭代發(fā)布等方式,實(shí)現(xiàn)用戶需求的快速上線,縮短項(xiàng)目整體交付周期.目標(biāo)是通過敏捷轉(zhuǎn)型實(shí)現(xiàn)快速高質(zhì)量的完成項(xiàng)目交付,并總結(jié)轉(zhuǎn)型經(jīng)驗(yàn)同時(shí)梳理出適用于國網(wǎng)敏捷項(xiàng)目的制度、標(biāo)準(zhǔn)、流程以及相關(guān)的支撐工具.

1 工作思路

轉(zhuǎn)型到敏捷不是否定國網(wǎng)前期信息化建設(shè)思路,而是在充分借鑒國網(wǎng)公司現(xiàn)有信息化成果和相關(guān)流程規(guī)范的基礎(chǔ)上,結(jié)合敏捷和精益的思想對現(xiàn)有流程和規(guī)范進(jìn)行參照、完善或裁剪.項(xiàng)目按照Scrum 敏捷開發(fā)模式,遵循高優(yōu)先級的需求驅(qū)動原則,依托公司統(tǒng)一研發(fā)環(huán)境,利用云效DevOps 平臺,實(shí)現(xiàn)迭代開發(fā)、增量交付、灰度發(fā)布.

1.1 Scrum 概述

Scrum[1,2]這個(gè)英文字母來源于橄欖球運(yùn)動的一個(gè)專業(yè)術(shù)語,表示“爭球”的動作.在橄欖球比賽的每次沖刺前,都將有一個(gè)計(jì)劃安排的過程,但沖刺開始后則由隊(duì)員在原計(jì)劃的基礎(chǔ)上隨機(jī)應(yīng)變(Scrum 框架如圖1所示).

圖1 Scrum 框架

Scrum是用于開發(fā)、交付和持續(xù)支持復(fù)雜產(chǎn)品的一個(gè)框架,是一個(gè)增量的、迭代的開發(fā)過程.它不同于傳統(tǒng)瀑布模型開發(fā)過程,而是由若干個(gè)短的迭代周期組成,每個(gè)短的迭代周期稱為一個(gè)沖刺(Sprint),每個(gè)Sprint的建議長度是1–4 周.Scrum 團(tuán)隊(duì)總是先開發(fā)對客戶具有較高價(jià)值的需求.

1.2 云效DevOps 平臺

云效DevOps 平臺(見圖2)主要涵蓋了研發(fā)環(huán)境支持、流程貫通、項(xiàng)目管理、發(fā)布部署支撐等功能,能夠?qū)崿F(xiàn)項(xiàng)目全生命周期管理.

圖2 云效DevOps 平臺

1.3 工作思路

1)需求梳理.明確業(yè)務(wù)藍(lán)圖,結(jié)合用戶需求優(yōu)先級明確分階段開發(fā)任務(wù);明確每個(gè)階段的詳細(xì)需求;對各階段需求進(jìn)行原型設(shè)計(jì).

2)設(shè)計(jì).采用微服務(wù)、微應(yīng)用的技術(shù)路線實(shí)現(xiàn)各業(yè)務(wù)模塊間的解耦,實(shí)現(xiàn)各業(yè)務(wù)并行開展.

3)開發(fā).先把底層功能以傳統(tǒng)模式快速開發(fā)完成;業(yè)務(wù)功能分階段迭代開發(fā);每個(gè)階段再根據(jù)業(yè)務(wù)優(yōu)先級列入開發(fā)計(jì)劃,實(shí)現(xiàn)核心功能優(yōu)先開發(fā)上線;上線功能根據(jù)用戶反饋迭代完善.

4)測試.開發(fā)過程中使用統(tǒng)一研發(fā)管控平臺進(jìn)行UI 自動化、接口自動化等;具備條件的項(xiàng)目可由業(yè)務(wù)部門或試點(diǎn)單位關(guān)鍵用戶完成用戶確認(rèn)測試工作.

5)發(fā)布.首次部署前由研發(fā)單位向國網(wǎng)信通公司提交軟硬件需求申請及部署方案;后續(xù)每次迭代測試通過后,由研發(fā)單位按照國網(wǎng)信通公司要求提交部署申請,按照信通公司要求完成迭代部署;通過云效DevOps 工具實(shí)現(xiàn)項(xiàng)目發(fā)布;系統(tǒng)部署完成后由紅隊(duì)進(jìn)行生產(chǎn)環(huán)境進(jìn)行安全掃描.

6)上線運(yùn)行/迭代完善.通過問答機(jī)器人、在線客戶及后臺自動信息收集等多個(gè)渠道獲取試點(diǎn)單位用戶使用情況;試點(diǎn)期間安排實(shí)施人員在客戶現(xiàn)場貼身用戶實(shí)時(shí)反饋用戶使用過程中的問題;通過不斷迭代做出功能完善、客戶滿意的系統(tǒng).

7)分析小結(jié).每次迭代完成后對迭代過程中的問題進(jìn)行總結(jié)分析,找出有待的改進(jìn)工作項(xiàng),逐步完善;將各個(gè)環(huán)節(jié)收集的問題進(jìn)行閉環(huán)跟蹤,確保所有問題、建議都能按時(shí)處理.

8)驗(yàn)收.依據(jù)最終系統(tǒng)功能與可行性研究報(bào)告的對應(yīng)情況;系統(tǒng)實(shí)現(xiàn)與技術(shù)方案、安全防護(hù)方案的遵從情況;最終用戶反饋的使用情況.

2 實(shí)踐過程和做法

本論文主要探索敏捷開發(fā)模式下如何做好研發(fā)質(zhì)量管控,達(dá)到及時(shí)響應(yīng)客戶需求的同時(shí),提升產(chǎn)品交付質(zhì)量.實(shí)踐過程共分前期準(zhǔn)備階段、執(zhí)行階段及探索優(yōu)化階段3 個(gè)階段開展.

2.1 前期準(zhǔn)備階段

選定經(jīng)法2.0 項(xiàng)目、人資2.0 項(xiàng)目作為敏捷轉(zhuǎn)型試點(diǎn)項(xiàng)目,組織調(diào)研銀行、航空[3]、大型國企、央企等單位敏捷轉(zhuǎn)型實(shí)踐過程,并閱讀大量敏捷相關(guān)書籍及論文[4–18],最終編制《人資與經(jīng)法項(xiàng)目敏捷研發(fā)工作方案》.

方案制定后,經(jīng)法2.0 項(xiàng)目、人資2.0 項(xiàng)目分別組建各自試點(diǎn)項(xiàng)目的敏捷團(tuán)隊(duì),敏捷團(tuán)隊(duì)含項(xiàng)目經(jīng)理、敏捷教練、產(chǎn)品經(jīng)理、技術(shù)經(jīng)理、產(chǎn)品團(tuán)隊(duì)、開發(fā)團(tuán)隊(duì)角色.

2.2 執(zhí)行階段

下述執(zhí)行過程以經(jīng)法2.0 項(xiàng)目為例,通過敏捷轉(zhuǎn)型結(jié)合云效DevOps 平臺來提升軟件質(zhì)量.

通過與用戶溝通,獲取重要的,關(guān)鍵的,標(biāo)志性的時(shí)間節(jié)點(diǎn)或事件,分析里程碑關(guān)鍵節(jié)點(diǎn),協(xié)助用戶制定里程碑計(jì)劃,來控制項(xiàng)目工作的進(jìn)展和保證實(shí)現(xiàn)總目標(biāo)(見圖3).

圖3 云效DevOps 平臺截圖(里程碑)

創(chuàng)建產(chǎn)品待辦列表(見圖4),產(chǎn)品待辦列表以用戶故事的形式來表達(dá).用戶故事的來源不限于用戶需求,也可以是迭代過程中產(chǎn)生的新需求或者系統(tǒng)上線后用戶提出的問題,產(chǎn)品負(fù)責(zé)人和需求分析師需要對需求池中的用戶故事進(jìn)行持續(xù)更新維護(hù),用戶故事積累到可規(guī)劃1–2 個(gè)迭代時(shí),由敏捷教練組織召開需求澄清會.

圖4 云效DevOps 平臺截圖(產(chǎn)品待辦列表)

產(chǎn)品待辦列表建立后,通知敏捷團(tuán)隊(duì)所有成員提前熟悉用戶故事,以便召開需求澄清會時(shí)能充分的提出問題和建議(見圖5).

圖5 云效DevOps 平臺截圖(用戶故事)

拆分用戶故事與維護(hù)產(chǎn)品待辦列表都是一個(gè)持續(xù)的過程,每當(dāng)產(chǎn)品負(fù)責(zé)人澄清完成用戶故事,技術(shù)負(fù)責(zé)人則帶領(lǐng)敏捷開發(fā)團(tuán)隊(duì),拆分用戶故事,制定對應(yīng)工作任務(wù),并完成任務(wù)工時(shí)的精準(zhǔn)估算.工作任務(wù)要落實(shí)到具體的責(zé)任人;任務(wù)粒度要小,工作量大于兩天的任務(wù)要進(jìn)一步分解(見圖6).

圖6 云效DevOps 平臺截圖(拆分用戶故事/任務(wù))

產(chǎn)品負(fù)責(zé)人按照需求優(yōu)先級及里程碑計(jì)劃,對交付的產(chǎn)品進(jìn)行版本規(guī)劃,明確每個(gè)版本的交付內(nèi)容和交付目標(biāo)(見圖7).

圖7 云效DevOps 平臺截圖(版本規(guī)劃)

由敏捷教練組織迭代計(jì)劃會,團(tuán)隊(duì)全員參與,保證所有人對需求的理解和交付所需的任務(wù)達(dá)成一致,并根據(jù)工作量和需求優(yōu)先級確定迭代周期(一般每周/每兩周設(shè)置為一個(gè)迭代周期)和迭代一交付內(nèi)容(見圖8).

圖8 云效DevOps 平臺截圖(迭代規(guī)劃/計(jì)劃)

在迭代詳情頁面,可以看到迭代的起止日期,預(yù)計(jì)總工時(shí)和實(shí)際工時(shí)、總體進(jìn)度還有工作項(xiàng)完成進(jìn)度等信息,方便管理和評估迭代進(jìn)度(見圖9).

圖9 云效DevOps 平臺截圖(迭代規(guī)劃/計(jì)劃詳情)

進(jìn)入迭代開發(fā)階段,技術(shù)負(fù)責(zé)人組織敏捷開發(fā)團(tuán)隊(duì),依據(jù)迭代待辦列表、用戶故事、迭代計(jì)劃等,開展詳細(xì)設(shè)計(jì)工作.

敏捷開發(fā)團(tuán)隊(duì)根據(jù)用戶故事、工作任務(wù)、詳細(xì)設(shè)計(jì)等文檔,完成業(yè)務(wù)功能實(shí)現(xiàn).過程中,堅(jiān)持每日站會,為敏捷團(tuán)隊(duì)提供了面對面交談的機(jī)會,來協(xié)調(diào)當(dāng)天任務(wù)的優(yōu)先級和識別任何出現(xiàn)的挑戰(zhàn),站會時(shí)利用看板向所有敏捷團(tuán)隊(duì)成員展示當(dāng)前迭代的狀態(tài),跟蹤項(xiàng)目進(jìn)度(見圖10).

圖10 云效DevOps 平臺截圖(看板)

代碼編寫完成后,進(jìn)入代碼審查階段,檢查代碼的一致性、編碼風(fēng)格、代碼的安全問題、代碼冗余、是否正確設(shè)計(jì)以滿足需求(功能、性能)等.

代碼提交后,云效平臺創(chuàng)建自動化流程項(xiàng)目,自動化流程項(xiàng)目構(gòu)建腳本代碼如下:

//自動化腳本代碼第一步:maven 代碼編譯打包

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

-Dmaven.test.skip

//自動化腳本代碼第二步:構(gòu)建docker 鏡像包

1.登錄云效平臺Docker Registry

$ sudo docker login--username=xx

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

2.構(gòu)建鏡像

sudo docker build-t packageName.

3.推送鏡像

$ sudo docker push

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

推送到阿里云鏡像倉庫,然后發(fā)布程序,對本次提交的內(nèi)容進(jìn)行代碼自動化掃描,檢查代碼的規(guī)范與安全性.開發(fā)人員根據(jù)代碼掃描問題列表,修改代碼缺陷(見圖11).

圖11 云效DevOps 平臺截圖(代碼掃描)

后端開發(fā)工程師根據(jù)業(yè)務(wù)邏輯,編寫單元測試用例,驗(yàn)證代碼的行為是否和期望的一致.

測試人員先維護(hù)測試用例,再通過云效平臺自動化接口SAT 測試工具,檢測系統(tǒng)前端頁面與后端代碼的接口功能是否滿足功能要求,重點(diǎn)是要檢查數(shù)據(jù)的交換,傳遞和控制管理過程.根據(jù)前后端接口文檔,編制測試用例,編寫自動化測試腳本,定時(shí)執(zhí)行腳本進(jìn)行接口正確性測試(見圖12).

圖12 云效DevOps 平臺截圖(自動化腳本)

測試人員先維護(hù)測試用例,項(xiàng)目組內(nèi)評審,再采用手工測試或者云效平臺UI 自動化工具,完成系統(tǒng)功能測試,同時(shí)對缺陷進(jìn)行管理(見圖13).

圖13 云效DevOps 平臺截圖(自動化測試)

在以上測試都通過后,合并各分支,利用集成工具,開展集成測試工作,利用UI 自動化工具,開展自動化,確認(rèn)各分支集成成功.

在每輪迭代結(jié)束后舉行迭代回顧會,目的是分享好的經(jīng)驗(yàn)和發(fā)現(xiàn)改進(jìn)點(diǎn),促進(jìn)團(tuán)隊(duì)不斷進(jìn)步,下一批次迭代順利.會議需要Team 全員參加,氣氛寬松自由,暢所欲言,頭腦風(fēng)暴發(fā)現(xiàn)問題,共同分析根因;會議關(guān)注重點(diǎn)是Team 共同討論優(yōu)先級,將精力放在最需要的地方;會議結(jié)論要跟蹤閉環(huán).

2.3 探索優(yōu)化階段

本階段對上述具體實(shí)踐過程做總結(jié)分析,并探索優(yōu)化敏捷開發(fā)流程,包括初期團(tuán)隊(duì)組建,過程中應(yīng)用“回顧反思”“頭腦風(fēng)暴”“5WHY”“PDCA”等工具,項(xiàng)目管理過程線上化,云效DevOps 平臺運(yùn)用等.同時(shí)將經(jīng)驗(yàn)總結(jié)運(yùn)用到后續(xù)迭代過程中,從而提升軟件質(zhì)量.

3 建設(shè)成效

3.1 項(xiàng)目管理提升

經(jīng)法2.0、人資2.0 系統(tǒng)利用統(tǒng)一研發(fā)管控平臺執(zhí)行項(xiàng)目管理,與傳統(tǒng)模式相比,管理方式從分散走向集中,實(shí)現(xiàn)全線上管理,包括需求管理、迭代規(guī)劃、里程碑管理、任務(wù)管理和缺陷管理等,同時(shí)線上支持度量可視化、多人協(xié)作,提高溝通效率.

3.2 流程化管理提升

經(jīng)法2.0、人資2.0 系統(tǒng)充分借鑒國網(wǎng)公司現(xiàn)有信息化成果和相關(guān)流程規(guī)范的基礎(chǔ)上,結(jié)合敏捷和精益的思想對現(xiàn)有流程和規(guī)范進(jìn)行參照、完善或裁剪,簡化流程.按照Scrum 敏捷開發(fā)模式,遵循高優(yōu)先級的需求驅(qū)動原則,依托公司統(tǒng)一研發(fā)環(huán)境,利用云效DevOps平臺,實(shí)現(xiàn)迭代開發(fā)、增量交付、灰度發(fā)布.

用戶需求優(yōu)先級分批次的進(jìn)行梳理,梳理一批、確認(rèn)一批、開發(fā)一批,擁抱變化(見圖14).

圖14 敏捷模式vs 瀑布模式

3.3 研發(fā)質(zhì)量提升

經(jīng)法2.0、人資2.0 系統(tǒng)使用國網(wǎng)云、國網(wǎng)SGUAP 開發(fā)平臺、云效DevOps 平臺開發(fā)、持續(xù)集成及部署,保證研發(fā)質(zhì)量.

1)統(tǒng)一使用國網(wǎng)SG-UAP 開發(fā)平臺進(jìn)行開發(fā),保障程序各依賴包的兼容性和安全性;

2)定期開展代碼審查,目的檢查代碼的一致性、編碼風(fēng)格、代碼的安全問題、代碼冗余、是否正確設(shè)計(jì),保障提交流水線前的代碼質(zhì)量;

3)通過創(chuàng)建研發(fā)流水線,保障研發(fā)過程透明、安全可控;

4)UI 自動化、接口自動化、單元測試自動化等功能保障業(yè)務(wù)實(shí)現(xiàn)的正確;

5)代碼靜態(tài)掃描與源碼安全掃描工具保障代碼質(zhì)量和安全;

6)流水線自動化構(gòu)建,利用自動化腳本,保障多環(huán)境部署無失敗;

7)項(xiàng)目部署在國網(wǎng)云上,利用容器化技術(shù),實(shí)現(xiàn)快速部署、版本快速回退;對服務(wù)的各項(xiàng)運(yùn)行指標(biāo)進(jìn)行整體監(jiān)控,保障項(xiàng)目的高可用性、穩(wěn)定性和安全性.

3.4 研發(fā)效率提升

使用統(tǒng)一代碼倉庫管理研發(fā)代碼及分支版本,避免各項(xiàng)目組手工自建;強(qiáng)化項(xiàng)目版本管理及風(fēng)險(xiǎn)管理;在開發(fā)過程中對業(yè)務(wù)系統(tǒng)功能進(jìn)行自動化回歸測試,強(qiáng)化代碼質(zhì)量;測試完畢后自動發(fā)布至生產(chǎn)環(huán)境.

4 結(jié)語

敏捷轉(zhuǎn)型是一場變革,充滿挑戰(zhàn).這場變革是全方位的,不僅是流程,開發(fā)方法,還是思想上的.通過敏捷開發(fā)模式能夠極大提升軟件質(zhì)量,仍然需要持續(xù)探索優(yōu)化從而更大程度提升軟件交付質(zhì)量.

(1)敏捷領(lǐng)導(dǎo)力培養(yǎng)很關(guān)鍵.人的重要性不言而喻,在敏捷變革這樣有挑戰(zhàn)的工作中更是如此.變革的成功與否取決于變革關(guān)鍵角色的能力.

(2)包容失敗,打造互信的團(tuán)隊(duì)氛圍.敏捷強(qiáng)調(diào)持續(xù)探索和快速驗(yàn)證,而探索驗(yàn)證可能會伴隨著失敗,敏捷團(tuán)隊(duì)通過回顧會議反思,總結(jié)經(jīng)驗(yàn)教訓(xùn)并列出改進(jìn)計(jì)劃,以便在后續(xù)迭代中能做得更好.在轉(zhuǎn)型過程中我們發(fā)現(xiàn)互聯(lián)網(wǎng)上的敏捷經(jīng)驗(yàn)大部分是ToC的和ToB的項(xiàng)目有著非常大的區(qū)別,國網(wǎng)公司大部分業(yè)務(wù)用戶是兼職做信息化,投入時(shí)間和參與程度無法得到保障.經(jīng)過多次討論,我們提出了業(yè)務(wù)迭代與研發(fā)迭代雙環(huán)模型.將研發(fā)迭代的思路借鑒到需求設(shè)計(jì)環(huán)節(jié),通過現(xiàn)場頻繁的溝通確認(rèn)實(shí)現(xiàn)業(yè)務(wù)層面的快速交付,通過研發(fā)迭代實(shí)現(xiàn)軟件層面的快速交付.通過雙環(huán)模型的運(yùn)轉(zhuǎn)逐漸提升了雙方的信任,避免了相互指責(zé)推諉的情況,提升了工作效率和質(zhì)量.

(3)信息共享,打造透明的團(tuán)隊(duì).敏捷團(tuán)隊(duì)通過電子屏展示總體工作目標(biāo)和當(dāng)前工作進(jìn)展情況,使得團(tuán)隊(duì)每個(gè)成員對項(xiàng)目目標(biāo)由清晰認(rèn)識,知道自己所做的每一項(xiàng)工作都是為了目標(biāo)更好的實(shí)現(xiàn);通過每日站會的信息共享機(jī)制不僅可以減少團(tuán)隊(duì)溝通成本而且有利于團(tuán)隊(duì)的協(xié)作效率的提升,助于管理人員對迭代進(jìn)度的判斷跟蹤,強(qiáng)制性的站會機(jī)制也有利于提升員工的團(tuán)隊(duì)意識.

(4)采用漸進(jìn)地適應(yīng)性方法.敏捷是一種變革.變革不可能一步到位.敏捷的精髓是不斷改進(jìn)和適應(yīng).敏捷只提供了一套價(jià)值觀和基本框架,所謂地一些最佳實(shí)踐也是別人地實(shí)踐.一定要根據(jù)團(tuán)隊(duì)的實(shí)際情況進(jìn)行適應(yīng)性調(diào)整,摸索,才能找到適合本團(tuán)隊(duì)的方法.只有經(jīng)過逐步改進(jìn),同時(shí)注意培養(yǎng)團(tuán)隊(duì)的能力,特別是關(guān)鍵角色(PO,Scrum master)的能力,才能漸進(jìn)的實(shí)現(xiàn)敏捷的轉(zhuǎn)型.