新型信息化系統建設下的敏捷開發模式①

馮 東,齊國棟,唐 宇

(北京國電通網絡技術有限公司,北京 100070)

目前國網公司信息化項目大多采用瀑布模型,將軟件生命周期劃分為可研、需求、設計、開發、測試和上線運行等6 個基本階段.國網信息化項目需求相對明確,采用瀑布模型有助于提升人力分配和項目進度計劃的準確性,有效規避或者減少項目開發風險.

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

為快速響應和滿足用戶需求,縮短系統建設周期,避免因業務變化導致的開發工作浪費,保證產品交付質量,國網公司決定研發敏捷轉型,選取經法2.0 系統、人資2.0 系統作為敏捷迭代開發試點項目.以用戶為中心主動創新、敢于試錯,著力推進系統的敏捷迭代、小步快跑,創新優化系統建設模式.試點項目通過迭代梳理用戶需求、迭代研發、迭代發布等方式,實現用戶需求的快速上線,縮短項目整體交付周期.目標是通過敏捷轉型實現快速高質量的完成項目交付,并總結轉型經驗同時梳理出適用于國網敏捷項目的制度、標準、流程以及相關的支撐工具.

1 工作思路

轉型到敏捷不是否定國網前期信息化建設思路,而是在充分借鑒國網公司現有信息化成果和相關流程規范的基礎上,結合敏捷和精益的思想對現有流程和規范進行參照、完善或裁剪.項目按照Scrum 敏捷開發模式,遵循高優先級的需求驅動原則,依托公司統一研發環境,利用云效DevOps 平臺,實現迭代開發、增量交付、灰度發布.

1.1 Scrum 概述

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

圖1 Scrum 框架

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

1.2 云效DevOps 平臺

云效DevOps 平臺(見圖2)主要涵蓋了研發環境支持、流程貫通、項目管理、發布部署支撐等功能,能夠實現項目全生命周期管理.

圖2 云效DevOps 平臺

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).

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

創建產品待辦列表(見圖4),產品待辦列表以用戶故事的形式來表達.用戶故事的來源不限于用戶需求,也可以是迭代過程中產生的新需求或者系統上線后用戶提出的問題,產品負責人和需求分析師需要對需求池中的用戶故事進行持續更新維護,用戶故事積累到可規劃1–2 個迭代時,由敏捷教練組織召開需求澄清會.

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

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

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

拆分用戶故事與維護產品待辦列表都是一個持續的過程,每當產品負責人澄清完成用戶故事,技術負責人則帶領敏捷開發團隊,拆分用戶故事,制定對應工作任務,并完成任務工時的精準估算.工作任務要落實到具體的責任人;任務粒度要小,工作量大于兩天的任務要進一步分解(見圖6).

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

產品負責人按照需求優先級及里程碑計劃,對交付的產品進行版本規劃,明確每個版本的交付內容和交付目標(見圖7).

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

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

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

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

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

進入迭代開發階段,技術負責人組織敏捷開發團隊,依據迭代待辦列表、用戶故事、迭代計劃等,開展詳細設計工作.

敏捷開發團隊根據用戶故事、工作任務、詳細設計等文檔,完成業務功能實現.過程中,堅持每日站會,為敏捷團隊提供了面對面交談的機會,來協調當天任務的優先級和識別任何出現的挑戰,站會時利用看板向所有敏捷團隊成員展示當前迭代的狀態,跟蹤項目進度(見圖10).

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

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

代碼提交后,云效平臺創建自動化流程項目,自動化流程項目構建腳本代碼如下:

//自動化腳本代碼第一步: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/packageNam e:1.0

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

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

后端開發工程師根據業務邏輯,編寫單元測試用例,驗證代碼的行為是否和期望的一致.

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

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

測試人員先維護測試用例,項目組內評審,再采用手工測試或者云效平臺UI 自動化工具,完成系統功能測試,同時對缺陷進行管理(見圖13).

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

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

在每輪迭代結束后舉行迭代回顧會,目的是分享好的經驗和發現改進點,促進團隊不斷進步,下一批次迭代順利.會議需要Team 全員參加,氣氛寬松自由,暢所欲言,頭腦風暴發現問題,共同分析根因;會議關注重點是Team 共同討論優先級,將精力放在最需要的地方;會議結論要跟蹤閉環.

2.3 探索優化階段

本階段對上述具體實踐過程做總結分析,并探索優化敏捷開發流程,包括初期團隊組建,過程中應用“回顧反思”“頭腦風暴”“5WHY”“PDCA”等工具,項目管理過程線上化,云效DevOps 平臺運用等.同時將經驗總結運用到后續迭代過程中,從而提升軟件質量.

3 建設成效

3.1 項目管理提升

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

3.2 流程化管理提升

經法2.0、人資2.0 系統充分借鑒國網公司現有信息化成果和相關流程規范的基礎上,結合敏捷和精益的思想對現有流程和規范進行參照、完善或裁剪,簡化流程.按照Scrum 敏捷開發模式,遵循高優先級的需求驅動原則,依托公司統一研發環境,利用云效DevOps平臺,實現迭代開發、增量交付、灰度發布.

用戶需求優先級分批次的進行梳理,梳理一批、確認一批、開發一批,擁抱變化(見圖14).

圖14 敏捷模式vs 瀑布模式

3.3 研發質量提升

經法2.0、人資2.0 系統使用國網云、國網SGUAP 開發平臺、云效DevOps 平臺開發、持續集成及部署,保證研發質量.

1)統一使用國網SG-UAP 開發平臺進行開發,保障程序各依賴包的兼容性和安全性;

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

3)通過創建研發流水線,保障研發過程透明、安全可控;

4)UI 自動化、接口自動化、單元測試自動化等功能保障業務實現的正確;

5)代碼靜態掃描與源碼安全掃描工具保障代碼質量和安全;

6)流水線自動化構建,利用自動化腳本,保障多環境部署無失敗;

7)項目部署在國網云上,利用容器化技術,實現快速部署、版本快速回退;對服務的各項運行指標進行整體監控,保障項目的高可用性、穩定性和安全性.

3.4 研發效率提升

使用統一代碼倉庫管理研發代碼及分支版本,避免各項目組手工自建;強化項目版本管理及風險管理;在開發過程中對業務系統功能進行自動化回歸測試,強化代碼質量;測試完畢后自動發布至生產環境.

4 結語

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

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

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

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

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