基于Scrum敏捷開發的軟件實訓設計

尹華 王志堅

摘要：針對采用傳統過程控制的軟件實訓類課程中開發文檔與編碼脫節，學生無法深入理解和應用分析與設計理念等問題，介紹敏捷開發過程的基本思想以及Scrum敏捷開發過程引入軟件實訓教學中的現狀，闡述新的基于Scrum敏捷開發過程的軟件實訓教學方案以及一套完整的軟件實訓案例，并總結分析該教學設計方案的有效性。

關鍵詞：軟件實訓；Agile；Scrum敏捷開發；教學設計

引言

互聯網時代急需大量軟件人才，如何實現高校與產業界的銜接是軟件人才培養的一個核心問題。軟件實訓作為理論聯系實際的橋梁，具有舉足輕重的作用。目前，國內大部分高校軟件實訓課程以項目為載體，以編碼結果為導向，讓學生通過完成項目鍛煉動手能力。信息技術發展飛速，當下完成一個程序或是軟件（也就是說編寫代碼）對于多數大學生而言并不困難，真正的難點在于如何開發一個具有可擴展性、可維護性的優質軟件，這也是目前以及未來軟件實訓課程轉換思路的方向。

從產業界看，優質軟件的前提是過程控制，這也意味著高校軟件實訓課程的導向應側重于課程過程控制。筆者在十幾年軟件實訓課程的教學中發現，傳統教學中采用的過程是瀑布模型，因為此模型采用分階段的方式，適合學生逐步完成項目，但這僅是理想狀態，瀑布模型在教學中同樣也面臨產業界相同的問題。學生在經歷了需求和設計等文檔撰寫階段后，往往難以將其與編碼匹配，到實際編碼階段又已臨近課程結束，只能草草完成。

2015年筆者在美國佩斯大學訪問期間，旁聽了佩斯大學計算機系主任Christelle Scharff教授的軟件工程課程，她在課程中引入Agile開發過程，以Serum敏捷開發過程結合先進開發應用工具，使得學生將開發、管理和工具應用在一個實際項目中聯結起來。Christelle教授采用Serum敏捷開發過程進行教學已經多年，成功實現了美國學生與柬埔寨、印度等地學生的同步開發和教學。受此啟發，筆者回國后將Serum敏捷開發過程應用于軟件實訓課程中，從實踐中體會到基于敏捷開發過程的軟件實訓的有效性，也發現了其存在的問題。

1敏捷軟件開發

軟件過程模型是軟件開發過程控制的向導。傳統過程模型注重建立軟件過程中的軟件產品，尤其是軟件文檔，采用此類過程模型的軟件工程方法被稱為“重型軟件工程”。“重型軟件工程”通過建立完善的文檔系統，實現細致的過程建模及檢測，以備維護與修改。另一類以人為核心的軟件開發思想“敏捷開發”，被稱為“輕型軟件工程”。敏捷開發強調開發人員的溝通、可持續交付可工作的軟件，以及對軟件需求和開發問題的快速靈活響應。2001年，以Kent Beck等為代表的敏捷開發擁護者共同簽署了“敏捷軟件開發宣言”。據VersionOne公司2013年的調查顯示，在全球收集的3501份調查報告中有88%的公司采用敏捷開發方法，Google、華為等大型軟件公司也采用了敏捷開發。

1.1敏捷開發基本原則

敏捷宣言的價值陳述中，從過程和工具、文檔、合同談判以及遵循計劃4個基本原則，體現出一種現實的開發價值觀。軟件開發的終極產品是軟件，軟件產品的度量者是客戶，實現產品的是開發者，圍繞這3部分是開發的重點。所以，敏捷開發強調開發者的自主協作，強調可運行軟件的快速迭代，強調對于軟件需求的適應性。這要求敏捷開發團隊成員的平衡性，也即只有具有自主開發意識、編程能力對等的成員才能夠較好地踐行敏捷開發過程。雖然敏捷開發適用于需求變化的場景，但對于大型項目而言，敏捷開發的實現還需要更為具體、完善和有針對性的過程。根據不同的應用場景有不同的敏捷過程，如極限編程、Serum敏捷開發等。軟件開發中應根據項目的具體情況選擇適當的開發過程。

1.2Scrum敏捷開發過程

在眾多敏捷開發方法中，成長最快的方法之一就是Serum敏捷開發過程。Ken Schwaber和Jeff Sutherland于1993年正式確立Serum，這一過程已經被Yahoo、微軟、谷歌、摩托羅拉、思科等公司使用。許多使用Serum的團隊表示，Serum極大地提升了團隊的產能和士氣，是一種有效的團隊工程控制方法。

1.2.1Scrum基本要素

Serum是一個迭代增量框架，采用周期方式完成產品開發，Serum將這些周期性的工作稱為Sprint，整個Serum框架都圍繞Sprint進行。Sprint的持續時間通常是1～4周，且一個緊接一個，一旦確定Sprint的完成周期，不論工作是否完成，結束時間都是特定的，永遠不會延遲。Sprint開始之初，項目團隊從需求的優先列表中選擇需要完成的條項（item），并在Sprint結束前完成這些需求；Sprint期間，所需要交付的結果不會改變，每個工作日，團隊成員簡要匯報彼此的進度，并根據剩余工作更新燃盡圖（bum downchart）； 結束后，項目團隊演示他們所做的工作，并且反饋需要融入下次，Sprint的工作。

1.2.2 Scrum角色

Serum有3類角色：產品負責人（productowner）、開發團隊（the team）和流程管理員（Serum master）。產品負責人收集來自顧客、終端用戶、項目團隊等多方面的需求信息，以獲得最大化商業價值為原則，得出需求優先列表，以供后續開發團隊實現。開發團隊是軟件的實現者，具有高度自組織性。開發團隊決定了最終提交產品的質量。一個軟件項目中的開發團隊包括分析師、開發者、接口設計者、測試員等。流程管理員是Serum成功最重要的元素，他需要全力以赴幫助開發團隊成功完成項目。流程管理員和產品負責人不能是同一人。做流程管理員的人可以是以前的項目經理，但所做的工作卻與項目經理非常不同。流程管理員不是開發團隊的管理員，而是為開發團隊提供服務的，旨在保障開發團隊不受干擾并引導團隊使用好Serum，他并不分配任務也不指揮人工作，其職責核心本質就是服務Serum項目團隊的所有成員，為Serum過程掃清障礙。

1.2.3Scrum過程

Serum過程包括3大部分：

（1）開始Serum。由產品負責人列舉所有產品需求，根據全部需求明確優先級，形成productbacklog，開始Sprint迭代。

（2）Sprint迭代。每個Sprint之前，先進行Sprint計劃會議（Sprint planning meeting）。第一件事由產品負責人和開發團隊一起回顧productbacklog，彼此交換對此backlog的看法。第二件事由開發團隊從product backlog中選擇此次Sprint結束需要提交完成的需求項，通常按照優先級順序來完成。第三件事由開發團隊估計每個成員在此次sprint中完成任務需要投入的時間。確定時間后，開發團隊將優先級最高的需求項分解為單個任務，并記錄到Sprint backlog文檔中。任務確定后，團隊成員自愿認領任務，需要考慮任務順序，估計每個任務的時間并確保每個成員工作負載平衡，然后順序完成各項需求。Sprint迭代開始后，開發團隊還需進行每日Serum——個15分鐘以內的站立會議，每個開發團隊中的成員都要參加。這個會議主要是開發團隊成員一個接一個匯報進展和困難，由流程管理員記錄問題并在會后解決問題。站立會議不討論，只匯報，會議結束后開發團隊成員更新完成每項任務的剩余時間，由流程管理員繪制燃盡圖來顯示到提交還剩多少工作。一個Sprint結束后有一個Sprint評審（Sprint review）。在評審時，開發團隊需展示此次Sprint完成的demo，產品負責人、團隊成員、流程管理員、客戶、專家、投資人都可參加評審會并提問。評審結束后，項目團隊一起進行Serum回顧（Serum retrospective），發現此次Sprint中做得好或不好的地方。在Sprint評審結束后，產品負責人要為進入下一個Sprint做準備，根據上次完成的結果修改product backlog，重新確定優先級，完成新的product backlog后，進入新Sprint過程。Sprint不斷迭代，直到產品負責人明確可以發布產品則停止迭代，進行發布。

（3）發布產品。

1.3Scrum敏捷開發教學應用

上述scrum過程由于迭代周期短，迭代時間可控，學生在整個學習過程中都可不斷看到可運行的程序，減少了學習的挫敗感，非常適用于具有固定時間（通常2～4個月）的軟件實訓教學。目前Scrum在軟件實訓教學中已有不少應用。文獻針對高職軟件開發課程提出了引人敏捷開發對于實訓模式的創新優勢。文獻從啟動項目、實施項目和量化考核3個方面論述了引入Serum的軟件實訓，但其提供的方案過于籠統，操作性不強。文獻從分組、實踐和評價3個方面給出了一套Serum軟件實訓教學方案，并進行了2個學期的教學實踐，其方案基本遵循Serum的標準過程，在評價上采用了小組互評的方式，并且以小組互評方式為主（80%），教師評價為輔（20%）。此種評價方式從學生角度獲得相對公平的評價結果，但是學生的視點不同于教師，其評價具有更大的主觀性而缺少專業性，且單次評價方式缺少教師反饋，難以較好實現過程驅動與控制。文獻在同濟大學軟件工程課程中進行了一學期的軟件工程實驗實踐，提供了一套較為完整且有體系的Serum敏捷應用框架，但該應用框架主要是對Serum基本過程的細化。筆者在美國學習期間發現，Serum過程的成功實施，更依賴基于軟件的過程控制以及教師的評價控制，因此，如何充分利用先進信息技術以及合理評價機制，是Serum成功應用于軟件實訓類課程的關鍵所在。

2基于Serum的軟件實訓設計方案

將Serum過程引入軟件實訓類課程的核心要點是明確教學目標。軟件實訓類課程的教學目標是通過教師引導與管理，使學生能夠運用和掌握所學習的軟件開發原理和技能。基于Serum的軟件實訓設計方案的精髓是把教師定位為教練，利用畢博平臺、Github、百度云盤等工具來實現項目管理控制，方案主要包括教學內容、組織形式和評價方式。

2.1軟件實訓內容

軟件實訓以項目為主導。項目選擇對于實訓有很大影響，決定項目以及開發規范是軟件實訓的主要內容。實訓項目選擇原則如下：

（1）項目來源：與學生生活和學習息息相關的領域。相關領域的需求可以讓學生作為使用者體會需求的有效性，作為開發者體會完成需求的難度。

（2）項目規模：小型可擴展項目。項目應具備幾點核心功能，學生根據自身能力在Serum過程中調整擴展。

（3）開發規范：包括文檔規范和編碼規范。雖然Serum過程不強調文檔作用，但應對product backlog和Sprint backlog中的內容進行編號，在表達設計理念中應采用UML描述。編碼規范推薦采用Google的lava編碼規范。

2.2軟件實訓組織

基于Serum的軟件實訓教學組織包括整體過程組織和過程實踐組織。整體過程分為3部分——基礎學習、過程實踐和評價反饋，如圖1所示。

在軟件實訓的教學組織中，可以借助畢博平臺、GitHub管理、百度云盤等工具實現過程控制。畢博平臺負責學生的整體管理。作為教練，教師通過在畢博平臺上發布學習資源、學習時間進度和學生階段評價來控制學習過程；作為學習者，學生通過Github實現軟件版本控制，通過Wild實現文檔保存與更新，通過百度云盤實現團隊內部文檔共享。評價反饋來自兩個部分：畢博平臺，在關鍵時間節點上，教師根據學生的項目完成情況，給與分數評價；Github，在學生提交代碼和文檔到Github資源庫后，教師根據提交內容進行點評。

2.3軟件實訓評價

軟件實訓課程通常由多個學生組成團隊完成項目開發工作，最大的難點就是如何量化每位成員的工作，無法公平地量化學生的工作量則很難驅動不自覺的學生參與項目學習過程，這將導致由團隊中某一人全權負責項目的情況出現。基于Serum的開發則不存在這樣的問題，因為Serum的會議中每位成員都需要總結自己在項目開發中所做的工作以及遇到的問題，這樣教師就可以根據學生的記錄進行控制。

項目的最終評價主要包含3部分內容：過程、代碼和演講展示。過程評價是針對學生對于Serum實踐的完成情況；代碼是針對學生完成的軟件及其結構的合理性；演講展示針對學生對于該次開發的認識、陳述與總結。高質量的實訓應該具備4點要素：團隊精誠合作；迭代式開發不論修正軟件；軟件的代碼結構可維護性與擴展性強；演講陳述邏輯思路清晰。一個項目由團隊完成，所以一切評價的基礎是團隊，團隊成果強則評價基點高。在團隊評價結果之上，再根據組員對項目的貢獻度來進行區別式評價。組員的貢獻度體現在3個方面：Serum總結；組員自身貢獻評價；Github代碼貢獻度計量。在Github中，對于每位組員所提交的代碼都有量化，但由于代碼的難度不一，所以此部分的評價比重應更為弱化。基于相信原則，可由組員自身給出貢獻度評價，再由Serum總結給出最終評價。

3教學實踐分析

為了驗證該教學理念和設計的有效性，在廣東財經大學三年級軟件工程專業的軟件工程課程設計中進行教學實踐試點。具體教學方案見表1。

之所以選擇開發App項目是因為其快速的特點，App開發周期短，同時其開發已經具備較好的結構。選擇兒童游戲App和公益項目App是因為這兩類App的需求都是由學生自身決定和修正的，貼近他們的生活，學生更容易體會開發出的軟件的可用性。之所以將項目規模確定為4～6個功能，是因為開發周期為8周，除去頭尾的講解與考核，只有6周可用于迭代，則每兩周完成一次Sprint迭代，對于學生而言，4～6個功能是6周的迭代可以控制的。本次實踐試點通過畢博平臺提供完整規范的文檔模板，學生直接填寫模板即可記錄整個開發過程。

一個學期的基于Scrum的軟件實訓實踐后，學生反饋學會了使用有效工具來輔助管理，而且迭代式的開發降低了開發的難度，減少了實踐挫敗感，當需求不明確時，完成少量的工作增加了后續開發的信心。最為重要的是，學生能發現所做的需求和設計工作能否和后續的代碼聯系起來。但是，實踐中也存在一些問題，主要體現在兩點：工具使用（尤其是Github的使用），學生還不能很好地利用版本控制工具提高合作效率；軟件結構性問題，由于采用的是迭代增量開發，學生暫時不具備良好的設計能力，往往在初期以完成為導向，在后階段的Sprint過程中發現軟件結構的缺陷時難以及時修正，導致最終的軟件結構可能存在不合理性。對于這兩點問題，最佳的解決方案是由教師介入，指導學生使用工具并提供合理的設計結構。

4結語

基于Serum的軟件實訓教學方案在大三學生中進行實踐應用后顯示，引入敏捷過程的軟件實訓課程可以使學生收獲更多有關軟件開發的應用體會，且可視的軟件成果也為學生進行開發增強了信心。但是，此方案有正向反饋的同時，也存在一定的不足。目前，該教學方案的瓶頸是如何在有限時間內將軟件工程的基本理論與技術充分引入，這也是下一步工作需要考慮的問題。