基于風險驅(qū)動的Scrum方法改進研究

嚴振亞

（天津開發(fā)區(qū)先特網(wǎng)絡系統(tǒng)有限公司 天津 300192）

基于風險驅(qū)動的Scrum方法改進研究

嚴振亞

（天津開發(fā)區(qū)先特網(wǎng)絡系統(tǒng)有限公司 天津 300192）

針對提高Scrum軟件開發(fā)方法應對風險的目的，采用改進軟件過程的方式，分別對需求風險、技術(shù)風險、進度風險和質(zhì)量風險增加監(jiān)控節(jié)點。通過在軟件過程中加入了需求風險分析環(huán)節(jié)、系統(tǒng)設計環(huán)節(jié)、每日報告記錄和持續(xù)集成機制、功能測試環(huán)節(jié)等節(jié)點，確保在軟件開發(fā)過程中的風險點得有效的監(jiān)控和預測。得出基于風險驅(qū)動的Scrum敏捷開發(fā)方法可以有效的應對開發(fā)風險，增加軟件產(chǎn)品開發(fā)成功機率的結(jié)論。

軟件工程；過程改進；敏捷；Scrum

隨著社會信息化水平的不斷提高，人們對軟件的依賴程度也隨之增長，市場需求對軟件的更新?lián)Q代提出了新的要求。傳統(tǒng)的軟件工程方法體系由于過于笨重，已經(jīng)不能滿足軟件開發(fā)現(xiàn)狀，人們迫切的需要一種輕量級的軟件過程方法來適應快速的市場變化。因此敏捷方法在過去的幾年里得到了迅猛的發(fā)展，其特征是用適應變化、頻繁迭代、用戶參與等方式代替原有的以文檔驅(qū)動的重量級軟件開發(fā)過程，這其中又以Scrum方法最為流行。

但是傳統(tǒng)的Scrum敏捷開發(fā)方法中并沒有針對風險進行有效的監(jiān)控和處理機制，這很容易導致開發(fā)失敗。文中針對Scrum開發(fā)過程提出一種基于風險驅(qū)動的改進方法，在整個開發(fā)周期的各階段分別建立風險監(jiān)控檢查點，主要針對需求風險、技術(shù)風險、進度風險和質(zhì)量風險4個方面對開發(fā)過程進行監(jiān)控。在風險發(fā)生之前，盡早的識別并進行處理，將風險對開發(fā)過程的影響降到最低程度。

1　Scrum簡介

Scrum是一種敏捷開發(fā)過程，它將軟件開發(fā)過程劃分為若干個迭代（稱為Sprint），每個Sprint迭代通常在2～4周內(nèi)完成，每次迭代都會從Prodcut Backlog（產(chǎn)品列表）中選取本次需要完成的功能，然后細化為1～2人/天的工作量單元，組成Sprint Backlog（迭代列表）。

每天由團隊成員領(lǐng)取Sprint Backlog中的任務，同時通過Stand Meeting（站立會議）確定前一天完成的工作、后續(xù)要完成的計劃和遇到的問題。當一個Sprint迭代周期完成后，團隊應該交付本次迭代的成果，并通過 Srpint Review Meeting （Sprint評審會）向相關(guān)干系人演示。如果接受本次迭代成果，則產(chǎn)生Release Product（發(fā)布產(chǎn)品）并最終完成本次迭代。

圖1　Scrum開發(fā)方法

2　使用Scrum開發(fā)軟件存在的風險

2.1需求風險

在Scrum開發(fā)方法中，需求是由Porduct Owner（產(chǎn)品所有人）提供的Product Backlog清單，這個需求清單并沒有經(jīng)過傳統(tǒng)軟件工程的“需求分析”過程，因此其中難免會存一些業(yè)務層面的風險。比如：Product Backlog中不同功能點之間互相矛盾、隱含的非功能性需求、需求描述不清等問題。這些問題在沒有風險監(jiān)控的情況下，會直接進入Sprint Backlog，最終導致某次迭代失敗。

2.2技術(shù)風險

技術(shù)風險來源于Sprint迭代周期過程中。由于對某個功能使用到的技術(shù)預期估計不足，在開發(fā)過程中可能會遇到技術(shù)難點無法實現(xiàn)的情況，尤其在缺乏開發(fā)經(jīng)驗的團隊中此類風險更為明顯。它會導致Sprint迭代失敗，最終無法交付預期的軟件產(chǎn)品。

2.3進度風險

雖然在Stand Meeting中每天都要說明自己完成工作的進展和計劃，但對于長達數(shù)周的 Sprint迭代周期，Scrum Master（Scrum教練）對進度把握也很容易出現(xiàn)問題，造成進度失控。同時對于已經(jīng)完成的程序代碼，如果在編譯或集成時遇到問題，同樣也會對本次Srpint的進度產(chǎn)生不利的影響。

2.4質(zhì)量風險

現(xiàn)有的Scrum開發(fā)方法，在每次Srpint迭代結(jié)束后會將本次成果直接提交給干系人。而這個過程中缺少了傳統(tǒng)軟件的功能測試環(huán)節(jié)，功能測試的目的是為了驗證軟件完成的功能與用戶原始需求的符合程度，如果檢查出軟件存在缺陷，則需要開發(fā)人員進行相應的調(diào)整并進行回歸測試，最終將合格的產(chǎn)品交付給用戶。而缺少功能測試環(huán)節(jié)，會將軟件的Bug直接暴露給最終用戶，這勢必會給軟件帶來質(zhì)量風險。

3　基于風險驅(qū)動的Scrum過程改進

3.1增加需求風險分析環(huán)節(jié)

在每次迭代周期開始階段，團隊成員需要從 Product Backlog中的選擇本次迭代需要完成的功能，并加入到Sprint Backlog中。此時增加“風險分析（Risk Analysis）”環(huán)節(jié)（圖2），由團隊成員對本次需要實現(xiàn)的功能進行風險分析，盡量減少需求層面對于后續(xù)開發(fā)迭代的影響。

需求風險分析主要從以下幾個方面進行：

檢查不同功能點之間是否互相矛盾。用戶的原始需求中經(jīng)常存在不同功能之間相互矛盾的情況，比如在一個報銷審核流程中，某個需求點規(guī)定只有大于等于500元的報銷請求由經(jīng)理審核后再送交財務部門，而小于500元的報銷申請直接送交財務審核。但在另一個需求中卻要求財務部門在處理報銷審核的前提是，必須經(jīng)理審核通過，否則做退回處理。這2個需求明顯存在矛盾，因此在需求風險分析過程中就需要甄別這類風險，避免將風險推遲到迭代過程中才被發(fā)現(xiàn)。

圖2　基于風險驅(qū)動的Scrum開發(fā)方法

檢查原始需求中包含的非功能性需求。在 Product Backlog中的需求主要都是功能性需求，由于用戶通常是非專業(yè)計算機人員，對非功能需求幾乎很少關(guān)注。但非功能性需求往往對項目的成敗起著關(guān)鍵性作用，因此在一個迭代周期開始之前發(fā)現(xiàn)非功能性隱藏需求非常重要。此時將主要檢查系統(tǒng)的處理性能、可靠性、響應時間、安全性、易用性等幾個方面。

檢查是否存在需求描述不清等情況。在Product Backlog列表中的需求是由用戶直接提出的，此時的需求并沒有經(jīng)過結(jié)構(gòu)化處理，其中難免會有一些描述模糊或敘述不清的情況。對于此類需求要在迭代前及時發(fā)現(xiàn)，并排除在 Sprint Backlog之外，等待用戶細化需求并更新Product Backlog后再考慮是否加入下一次迭代，否則極有可能造成開發(fā)出的軟件和用戶希望得到的功能相差較大的情況。如在一個需求中，用戶只要求報銷時必須要有流程，但并沒有說清具體流程情況，類似這樣的情況都可以歸為需求描述不清的范圍。

3.2增加系統(tǒng)設計環(huán)節(jié)

軟件設計工作對于后期的開發(fā)環(huán)節(jié)至關(guān)重要，它可以在開發(fā)過程中對所使用的技術(shù)、標準、規(guī)范給出有效的指導，同時軟件設計又是從全局出發(fā)，在宏觀的層面上考慮軟件各功能模塊間的關(guān)系，因此也可以使軟件保持良好的結(jié)構(gòu)特性。

但Scrum過程中并沒有針對系統(tǒng)設計的專門環(huán)節(jié)，當在一次迭代中生成Sprint Backlog后，團隊成員就開始按照自己的能力領(lǐng)取任務，開發(fā)人員關(guān)心更多的問題是在規(guī)定的時間內(nèi)完成自己負責的模塊開發(fā)，而很少考慮從全局的角度審視軟件，也容易忽視各模塊之間調(diào)用關(guān)系是否合理、是否為高內(nèi)聚低耦合等架構(gòu)層次的問題。這種開發(fā)模式如果一直持續(xù)下去，經(jīng)過幾次迭代后，軟件的內(nèi)部結(jié)構(gòu)會變得越來越差、可能會導致可維護性變差、處理性能降低、模塊間的耦合程度增高等一系列問題。

因此在一次迭代開始之前，建議增加＂系統(tǒng)設計（System Design）＂環(huán)節(jié)（圖2），盡量降低由于缺少全局設計對于后期開發(fā)的影響。系統(tǒng)設計階段需要團隊成員集體參與，不再專門設置軟件設計崗位。因為在Scrum模式中開發(fā)團隊非常了解用戶需求，并且全員參與討論系統(tǒng)設計也可以使每個成員接受最終的設計方案。系統(tǒng)設計主要包括接口、領(lǐng)域類和類之間的交互關(guān)系3個方面，在不違背Scrum的輕量級開發(fā)方式的核心思想上，建議只進行必要的設計內(nèi)容，減少非必要的設計文檔，主要以UML圖的方式描述設計思路和實現(xiàn)原理，并配合少量的文字描述即可。如接口設計時僅描述本次迭代需要完成的功能所涉及到的Interface和它內(nèi)部的方法；對于涉及到的核心領(lǐng)域類以及對象之間的調(diào)用關(guān)系，可以采用UML中的類圖和時序圖來描述，并在不易理解的地方使用簡單的文字說明。目的是在系統(tǒng)層面有一個整體的設計框架用來約束開發(fā)階段的隨意性，同時又要盡量保持Scrum開發(fā)方法的敏捷特性。

3.3每日報告記錄和持續(xù)集成機制

雖然Scrum開發(fā)方法中包括每日站會的環(huán)節(jié)，通過這個10分鐘左右的會議使團隊各成員互相了解工作進度、計劃工作內(nèi)容和遇到的問題。但這個會議并沒有留下任何記錄數(shù)據(jù)，只能使團隊關(guān)注最近幾天內(nèi)的工作進展情況，缺少項目整體觀察視角。同時由于在Sprint過程中團隊里的每個成員很少關(guān)注各自開發(fā)的模塊在集成后會出現(xiàn)的問題，這類問題最終會推遲到Sprint結(jié)果之前的幾天才被發(fā)現(xiàn)。以上這些問題都有可能對項止進度造成潛在的影響，因此必須盡量減少此類風險發(fā)生的機率。

增加＂每日報告記錄（Daily Report）＂環(huán)節(jié)。（圖2）為項目團隊選擇一個工作日志系統(tǒng)，在當天結(jié)束工作之前，要求團隊成員根據(jù)當天完成的工作情況填寫日志信息。其中包括實際工作內(nèi)容、完成的百分率、是否遇到問題等關(guān)鍵信息，Scrum Master可以根據(jù)這些日志信息發(fā)現(xiàn)Sprint過程中遇到的進度問題，并在風險發(fā)現(xiàn)前進行干預。日志提供長期監(jiān)控項目的歷史信息用于數(shù)據(jù)分析，每日站會提供最近短時間內(nèi)工作情況用于成員間的相互溝通，兩者相結(jié)合可以對Scrum開發(fā)周期進行全面的監(jiān)控和風險預防。

增加＂持續(xù)集成（Continuous Integration）＂機制。（圖2）為了能夠?qū)⒛K集成階段發(fā)生的問題提前發(fā)現(xiàn)，團隊成員每天結(jié)束工作前需要將已完成的工作提交到版本控制服務器，并在設置的時間段編一編譯。如果出現(xiàn)問題則會使用郵件的方式自動發(fā)出通知，以便及時發(fā)現(xiàn)問題并進行修復。

3.4增加功能測試環(huán)節(jié)

按照傳統(tǒng)軟件工程的思想，測試和開發(fā)要由不同的人完成，這樣可以盡量減少由于心理、實現(xiàn)思路等原因?qū)ψ罱K測試的影響，以便發(fā)現(xiàn)更多的軟件缺陷。在Scrum開發(fā)模式中并沒有強制約束對每個Sprint的測試環(huán)節(jié)，在實際操作中即使測試也是由團隊成員自己完成。但這樣做會存在很大的問題，通常開發(fā)人員對測試專業(yè)技術(shù)并不精通，再加上不愿意否認自己的工作成果，導致很多軟件缺陷都沒有被及時發(fā)現(xiàn)，為軟件質(zhì)量帶來很大的風險。為了解決這樣的問題，可以增加QA團隊和功能測試環(huán)節(jié)。

增加QA團隊，由這些質(zhì)量保證人員對軟件進行功能測試。為減少測試對Scrum輕量級過程的影響，在測試過程中不建議寫測試用例，而是以Sprint Backlog中的需求點做為測試依據(jù)，結(jié)合測試人員的經(jīng)驗對軟件進行功能測試。測試過程中可以將發(fā)現(xiàn)的缺陷分級管理，根據(jù)項目的實際情況規(guī)定具體級別以上的缺陷完全修正后才能夠發(fā)布最終的Sprint Product。通過增加測試環(huán)節(jié)可以有效的減少軟件產(chǎn)品風險對項目的影響。

4　結(jié)束語

本文以風險的預防和控制為中心，對Scrum開發(fā)過程進行改進。增加了需求風險分析、系統(tǒng)設計、每日報告記錄、持續(xù)集成機制、功能測試等環(huán)節(jié)，從需求風險、技術(shù)風險、進度風險和質(zhì)量風險各個層面對Scrum開發(fā)過程進行監(jiān)控，盡可能減少風險對于開發(fā)過程的影響。

［1］劉慧玲,王申申,陳曉軍.Scrum敏捷方法在快速開發(fā)中的實踐與改進［J］.電腦知識與技術(shù),2012,8（21）:5168-5169.

［2］孫開翠,楊立揚.基于SCRUM的大型軟件開發(fā)模型的研究［J］.電腦知識與技術(shù),2013,9（13）:3043-3046.

［3］徐偉,王浩宇,謝夢，等.結(jié)合CMMI的Scrum敏捷軟件開發(fā)研究［J］.計算機技術(shù)與發(fā)展,2014,24（9）:89-92.

［4］施瓦伯.Scrum敏捷項目管理［M］.李國彪,譯.北京:清華大學出版社,2007.

［5］Chris Sims Hillary Louise Johnson.Scrum要素［M］.徐毅,譯.北京:人民郵電出版社,2013.

［6］皮希勒,李忠利.Scrum敏捷產(chǎn)品管理［M］.北京:清華大學出版社,2013.

Improvement of Scrum method based on risk drive

YAN Zhen-ya
（ESINT System Co.，Ltd.，Tianjin 300192，China）

Aiming at the risk prevention through improving Scrum development method,this paper adopted the software process improvement to increase monitoring nodes for demand risk,technical risk,schedule risk and quality risk.Addition of demand risk analysis,system design,daily report record and continuous integrating system,function test and so on to the software process to make sure the risks are monitored and forecasted effectively during the software development.It is concluded that the quick risk-driven development method of Scrum can respond to development risks effectively and increase the success probability of software development.

software engineering；process improvement；agile；Scrum

TP311.5

A

1674－6236（2016）13-0152-03

2015-07-07稿件編號：201507059

嚴振亞（1982—），男，天津人，碩士，副高級工程師。研究方向：軟件工程過程和系統(tǒng)架構(gòu)設計。