張鴻鳴

摘要：敏捷開發(fā)是軟件項目的一個概念框架，能夠幫助開發(fā)團隊迅速響應(yīng)需求的變化并且能夠很好地控制成本和風(fēng)險。它是一種以人為核心、迭代、循序漸進的開發(fā)方法。Scrum是一個應(yīng)用廣泛的迭代增量過程進行軟件開發(fā)的敏捷開發(fā)方法。國家電網(wǎng)在用電信息采集系統(tǒng)項目開發(fā)上采用了敏捷開發(fā)模式Scrum方法，有效提升了開發(fā)及管理效率。

關(guān)鍵詞：敏捷開發(fā)；Scrum；用電信息采集管理系統(tǒng)

中圖分類號：TP311 文獻標(biāo)識碼：A 文章編號：1009-3044（2017）26-0240-03

Abstract： Agile development is a conceptual framework for software projects that can help the development team respond quickly to changing requirements and be able to control costs and risks well. It is a kind of human core， iterative， step by step development method. Scrum is an agile development method for software development using a wide range of iterative incremental processes. The national grid adopts the agile development model Scrum method in the development of the electricity information acquisition system project， which effectively improves the development and management efficiency.

Key words： agile development； Scrum； electricity information collection and management system

各類技術(shù)的革命、更新始終貫穿著計算機發(fā)展的進程，同時軟件開發(fā)作為計算機技術(shù)飛速發(fā)展的關(guān)鍵技術(shù)也在迅速地發(fā)展著，越來越多的軟件開發(fā)改進方法在涌現(xiàn)。大多數(shù)方法都被描繪成“使過程可控”，都“標(biāo)志著重大成果性突破”，實則不然。與此同時，制度管理混亂、投入產(chǎn)出不成正比等情況也比比皆是。二十世紀(jì)初，業(yè)界的一些專家總結(jié)了軟件開發(fā)過程中的一些能夠有效加速開發(fā)速度、有效應(yīng)對各種變化的原則和價值觀，以解決軟件開發(fā)過程中復(fù)雜、冗余的問題，這些原則和價值觀就稱為敏捷開發(fā)，這批專家自稱敏捷聯(lián)盟，并發(fā)布“敏捷宣言”。

1 敏捷開發(fā)理論

1.1 定義

敏捷開發(fā)是一種以人為核心的、迭代循序漸進的軟件開發(fā)方法，也是軟件項目開發(fā)的一個概念框架。敏捷開發(fā)通常將一個大項目細分成許多相互聯(lián)系、也可獨立運行的小項目，最大限度地降低開發(fā)過程中的風(fēng)險系數(shù)。極限編程（XP）、Scrum、特征驅(qū)動開發(fā)、上下文驅(qū)動開發(fā)、動態(tài)系統(tǒng)開發(fā)方法、精益開發(fā)等是敏捷開發(fā)的幾種常見的軟件開發(fā)方法。

1.2 實施原因

敏捷開發(fā)為軟件項目開發(fā)提供了良好的解決方案。國家電網(wǎng)用電信息采集系統(tǒng)引入敏捷開發(fā)的原因主要包括外部因素、內(nèi)部因素和外圍因素三個方面。

1） 外部因素。外部因素包括項目需求來源和項目干系人兩個方面。以國家電網(wǎng)用電信息采集系統(tǒng)為例，需求來源包括省公司營銷部、運檢部、安質(zhì)部以及省計量中心、各地市公司等等，導(dǎo)致業(yè)務(wù)處理復(fù)雜度高；與此同時，各個省公司職能部門、各地市、縣公司、抄表公司、項目管理組及開發(fā)團隊成員等項目干系人眾多，需尋求一種開發(fā)管理框架來統(tǒng)一管理。

2） 內(nèi)部因素。同樣以國家電網(wǎng)用電信息采集系統(tǒng)為例，此處內(nèi)部因素主要包括一直以來所采用的瀑布式和迭代式開發(fā)模式、任務(wù)及進度管理模式（CMMI）、質(zhì)量管理和資源管理共五個方面。

①2010～2012年用電信息采集系統(tǒng)開發(fā)時，項目組按照傳統(tǒng)的瀑布式開發(fā)模式，成立了需求組，設(shè)計組，開發(fā)組，測試組，發(fā)布組，運維組。嚴(yán)格按照CMMI的要求，從源頭形成需求文檔—設(shè)計文檔，通過評審的設(shè)計文檔給開發(fā)組，開發(fā)組完成開發(fā)并自測完成交給測試組，測試組測試通過交給發(fā)布組，發(fā)布到正式環(huán)境后，交給運維組負責(zé)后期的運維工作。這種開發(fā)模式可以有效地應(yīng)對用采系統(tǒng)前期需求變化不大的業(yè)務(wù)，但是隨著用采需求不斷地延伸和擴展，無法快速的響應(yīng)需求變化，瀑布模式的開發(fā)逐漸暴露出其中的不足。

②2013～2014年用電信息采集系統(tǒng)在升級、完善的過程中引入迭代式開發(fā)模式，首先將任務(wù)分解成階段目標(biāo)，然后將階段目標(biāo)分解成一個迭代周期（2周），完成需求設(shè)計、編碼、測試、發(fā)布但是由于迭代頻繁，不能有效地掌握人員的工作負荷，并且有時質(zhì)量保障措施會有欠缺，導(dǎo)致返工。

③用電信息采集系統(tǒng)采用Excel電子檔和Mantis的任務(wù)管理模式，這種任務(wù)管理模式，可以準(zhǔn)確的了解項目組的任務(wù)，通過Mantis的日報管理，了解項目組成員的每日工作內(nèi)容。這種模式的缺點是不能夠?qū)θ蝿?wù)的可視化管理，以及對組員每日的進度沒有一個定量的分析，對整體的工作量沒有一個整體的把握。

④傳統(tǒng)的開發(fā)模式質(zhì)量管理靠的是每個環(huán)節(jié)的評審，比如說設(shè)計文檔完成后，形成設(shè)計文檔的基線，開發(fā)完全參照這個設(shè)計文檔，再經(jīng)過測試組測試，然后上線，所有的都是基于評審后的設(shè)計文檔。

⑤用采項目組目前的資源管理有幾個組組成，每個組負責(zé)不同的業(yè)務(wù)，在工作忙碌的時候，可能有些組存在空閑的資源，由于資源沒有統(tǒng)一的管理，導(dǎo)致某些繁忙的組沒有有效利用其他組閑置的資源，造成了資源的浪費。后來通過項目經(jīng)理的協(xié)調(diào)，臨時解決了問題，但是沒有形成一個有效地，長期的管理模式。endprint

3） 外圍因素。運維組的咨詢，項目的郵件，電話咨詢等等，作為項目開發(fā)的外圍因素，時時刻刻都在影響著項目組的進程。過去，運維組的人員可以直接找到相應(yīng)的業(yè)務(wù)功能開發(fā)人員，導(dǎo)致開發(fā)人員不得不停下手頭的工作去應(yīng)付外部的干擾，干擾其實是最大的浪費。

2 敏捷開發(fā)項目實踐

在綜合比較了幾種主流的敏捷開發(fā)方法之后，國家電網(wǎng)用電信息采集項目采用了敏捷開發(fā)Scrum方法。幾乎所有的軟件開發(fā)方法都由三部分組成：研發(fā)團隊角色、各項活動和各類產(chǎn)出。Scrum方法也不例外，它是一個包含了多種角色和實踐活動的過程框架。

2.1 Scrum研發(fā)團隊角色

Scrum開發(fā)過程中研發(fā)團隊角色主要分為四類：產(chǎn)品負責(zé)人、Scrum主管和研發(fā)團隊成員、客戶代表四類。

1） 產(chǎn)品負責(zé)人。產(chǎn)品負責(zé)人需要根據(jù)需求確定產(chǎn)品的功能和交付時間，同時還需要根據(jù)項目進程確定功能需求和事務(wù)優(yōu)先級。

2） Scrum主管。Scrum主管需要根據(jù)項目進程監(jiān)督整個項目實施，確保產(chǎn)品能夠按時開發(fā)，同時還需要具備協(xié)調(diào)不同角色成員之間相互溝通的能力，確保產(chǎn)品開發(fā)的進度。

3） 研發(fā)團隊成員。一般是自組織的、由5-10個全職成員組成最為理想，理想規(guī)模是7個人，團隊成員橫跨各個職能，通常包括開發(fā)、測試、設(shè)計、部署等，改變團隊結(jié)構(gòu)時需謹(jǐn)慎。國家電網(wǎng)用電信息采集項目將組建3個Scrum團隊，每個團隊7成員，分別負責(zé)不同功能的開發(fā)工作。

4） 客戶代表。一般來自客戶對方，主要負責(zé)提供業(yè)務(wù)背景和項目需求，以及跟蹤項目進程確認產(chǎn)品完成進度，驗收已完成產(chǎn)品的功能。

國家電網(wǎng)用電信息采集項目按照Scrum角色劃分之后的組織結(jié)構(gòu)如圖1所示，各Scrum子團隊的需求和分工如表1所示。

由表1可見，子團隊1的主要任務(wù)是完成后臺的建模任務(wù)，不依賴于任何選項。而子團隊2負責(zé)前臺界面的設(shè)計與實現(xiàn)，這需要依賴于后臺的建模。子團隊3負責(zé)完成相關(guān)報表的編寫工作，這需要依賴于現(xiàn)有的報表平臺。

2.2 Scrum方法中的四類活動

國家電網(wǎng)用電信息采集系統(tǒng)采用的Scrum方法中有四種重要的儀式，分別是迭代計劃會議、每日Scrum站會、迭代評審會議、迭代回顧。Scrum方法鼓勵所有團隊成員聚在一起共同工作，文字、口頭交流，產(chǎn)品負責(zé)人和Scrum主管能夠更好的強調(diào)項目的有關(guān)規(guī)范，這些都能夠很好地體現(xiàn)出團隊的自組織性。

1） 迭代計劃會議

迭代計劃會議（需求澄清會）可以讓設(shè)計人員、開發(fā)人員、測試人員第一時間了解需求，對不明白的需求直接討論，業(yè)務(wù)人員給出解答，避免了之前只有設(shè)計人員了解需求，開發(fā)人員和測試人員通過設(shè)計文檔間接熟悉需求的問題。通過需求澄清會生成的迭代Backlog，作為本次迭代的任務(wù)展開工作分解會議，將迭代Backlog細分成一個個的故事卡（WBS），集體評估每個故事卡的工作量。之后的開發(fā)根據(jù)這個工作量展開，可以對工作進行定量的分析。每次開發(fā)人員領(lǐng)取一個故事卡，減少開發(fā)人員的并發(fā)開發(fā)，通過開發(fā)人員自己領(lǐng)取故事卡，增加開發(fā)人員的主動性。

2） 每日Scrum站會

每日Scrum站會及時了解開發(fā)人員上一日的進度和今天需要開展的工作，通過看板的形式將進度可視化的展現(xiàn)在每位面前，一方面能夠使項目經(jīng)理直觀的了解每個開發(fā)人員的工作情況和整個項目的進展情況，另一方面開發(fā)人員都能夠看到所有人員的工作，增加同行壓力，提高員工的積極性。通過看板的質(zhì)量門，解決了之前只有設(shè)計評審環(huán)節(jié)的質(zhì)量控制，現(xiàn)在對設(shè)計環(huán)節(jié)，開發(fā)結(jié)束環(huán)節(jié)，測試環(huán)節(jié)都加入了業(yè)務(wù)負責(zé)人的監(jiān)控，提升了開發(fā)成果的質(zhì)量。

3） 迭代復(fù)審會議

會議不要太長，規(guī)定為迭代周期的1.5%，由各Scrum子團隊成員向產(chǎn)品負責(zé)人、客戶代表及其他相關(guān)人員匯報總結(jié)迭代周期內(nèi)的項目進程和產(chǎn)品開發(fā)情況，并規(guī)劃下一步的迭代周期內(nèi)的詳細工作。

4） 迭代回顧

迭代回顧會議，每次迭代結(jié)束，總結(jié)上次迭代工作中的得失，每次故障的回顧，對常見的故障生成可執(zhí)行的方案，制定具體負責(zé)人根據(jù)方案，避免下次迭代產(chǎn)生同樣的問題，對工作成果的質(zhì)量持續(xù)的改進。在迭代回顧會議上，對本次迭代工作量大且質(zhì)量高的人員給予一定的獎品的獎勵，能夠調(diào)用大家的積極性。

2.3 Scrum方法中的五類產(chǎn)出

Scrum方法中有五種產(chǎn)出，分別為產(chǎn)品需求清單、沖刺訂單、任務(wù)板、未計劃任務(wù)和可編入任務(wù)。

（1） 產(chǎn)品需求清單

產(chǎn)品需求清單是站在用戶的角度編寫的整個用電信息采集系統(tǒng)的概要文檔，不僅包含詳細的項目需求和約束條件，而且包含已劃分優(yōu)先等級的、需要開發(fā)的系統(tǒng)和產(chǎn)品的詳細清單。

在用電信息采集項目中的Scrum角色確定好之后，在第一次迭代會議之前，產(chǎn)品總負責(zé)人需根據(jù)用戶的需求創(chuàng)建詳細的產(chǎn)品訂單，并依次賦予優(yōu)先級。在此用電信息采集項目中，產(chǎn)品總負責(zé)人在與客戶代表商談之后，給出了用電信息采集系統(tǒng)Scrum產(chǎn)品訂單的初稿，如表2所示。

（2） 迭代訂單

迭代訂單是從產(chǎn)品需求訂單中選擇出來的，是它的一個子集，規(guī)劃了Scrum團隊在迭代周期中的任務(wù)。任務(wù)被分解為以人天為單位，沒有任務(wù)可以超過1個人天。

（3） 任務(wù)板

任務(wù)板是一個公開展示迭代周期內(nèi)的所有迭代訂單和所有分解的工作任務(wù)的進度狀態(tài)圖表，也可以稱為故事墻。用電信息采集項目的故事墻如圖2所示。

（4） 未計劃任務(wù)

未計劃任務(wù)是指在總體計劃外的工作任務(wù)，有可能是迭代訂單沒有分解完全，也有可能是一些突發(fā)任務(wù)。這部分任務(wù)越少越好，因為它有可能會毀掉這次迭代周期。

（5） 可編入任務(wù)

如果在規(guī)定的迭代周期之內(nèi)就可以完成計劃好的迭代訂單，則可以接著編入計劃的產(chǎn)品訂單項及其分解任務(wù)。

3 結(jié)束語

目前國家電網(wǎng)用電信息采集系統(tǒng)項目組經(jīng)過努力，完成了用電信息采集系統(tǒng)的設(shè)計與實現(xiàn)。通過各項產(chǎn)出，對需求多源頭進行統(tǒng)一管理，產(chǎn)品負責(zé)人將需求納入，確定需求的優(yōu)先級，各開發(fā)團隊獲取需求，根據(jù)開發(fā)進展修改需求的完成情況，產(chǎn)品負責(zé)人對業(yè)務(wù)進行跟蹤，時刻了解需求的進展。通過各項產(chǎn)出，各開發(fā)團隊主管可以及時了解項目的進度，根據(jù)需求的優(yōu)先級統(tǒng)一分配資源，消除了以前資源分配不均衡的問題。

參考文獻：

[1] Hughes Bob，Cotterell Mike.軟件項目管理[M].廖彬山，王慧譯.4版.北京：機械工業(yè)出版社，2007.

[2] 桑大勇，王英，吳麗華.敏捷軟件開發(fā)方法與實踐[M].西安：西安電子科技大學(xué)出版社，2010（5）.

[3] 任思迷.論敏捷開發(fā)中的團隊建設(shè)[J].計算機光盤軟件與應(yīng)用，2013，29（2）：114-118.

[4] 胡文生，趙明，楊劍鋒，等.敏捷開發(fā)過程中的迭代策略分析[J].微電子學(xué)與計算機，2012，27（5）：276-278.

[5] 張林，劉德永.敏捷開發(fā)在軟件產(chǎn)品項目中的應(yīng)用實踐[J].硅谷，2011（7）.endprint