基于風險驅動的Scrum方法改進研究

嚴振亞

（天津開發區先特網絡系統有限公司 天津 300192）

基于風險驅動的Scrum方法改進研究

嚴振亞

（天津開發區先特網絡系統有限公司 天津 300192）

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

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

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

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

1　Scrum簡介

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

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

圖1　Scrum開發方法

2　使用Scrum開發軟件存在的風險

2.1需求風險

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

2.2技術風險

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

2.3進度風險

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

2.4質量風險

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

3　基于風險驅動的Scrum過程改進

3.1增加需求風險分析環節

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

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

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

圖2　基于風險驅動的Scrum開發方法

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

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

3.2增加系統設計環節

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

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

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

3.3每日報告記錄和持續集成機制

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

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

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

3.4增加功能測試環節

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

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

4　結束語

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

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

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

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

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

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

［6］皮希勒,李忠利.Scrum敏捷產品管理［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—），男，天津人，碩士，副高級工程師。研究方向：軟件工程過程和系統架構設計。