基于敏捷開發的軟件工程實踐教學探討

白曉穎, 李山山, 李明杰, 葉德銘

(清華大學 計算機科學與技術系, 北京 100084)

隨著Web 2.0和軟件即服務的興起,軟件開發模式在近幾年有了很大改變。遵照Web 2.0的原則,在線更新以及頻繁發布已經是大多數互聯網軟件的常態。作為一種輕量型的軟件開發方法,敏捷開發應運而生,也成為軟件工程教學的一個主要改革方向。

1 敏捷開發過程

圖1是一個敏捷開發方法Scrum的過程。用戶提出的產品需求被分解成小的用戶故事,每個迭代周期在制定計劃時選擇實現一部分需求。經過1～2周到1個月的迭代過程形成可交付的軟件增量。迭代過程中,團隊成員每天討論前一天完成的工作和當天的任務。

圖1 Scrum開發過程

現代工業界的這種轉換也推進了大學課程的改革[1-3],敏捷開發在軟件工程課程中得到了越來越多的關注。傳統的軟件工程教學中,常常遵循劃分明確的計劃、需求、設計、實現和測試周期等階段,而敏捷開發則強調擁抱變化、增量開發、以運行的軟件作為評價工作的尺度、持續集成、自組織團隊、用戶和開發人員一起工作等理念[4],因此,如何設計基于敏捷的軟件工程教學及實踐環節,成為教學改革的一個挑戰性問題。與一般的軟件工程教學一樣,敏捷開發的教和學必須通過真實開發過程訓練來開展,以培養學生的實踐能力[1,3]。團隊開發是目前一種普遍采用的方法,學生可以通過實踐來理解理論知識。有了這些來自“現實世界”的項目,學生不僅可以學習軟件工程的方法,而且可以在開發過程中,更加真實地體驗用戶溝通、環境約束等方面的問題。

2 敏捷開發軟件工程實踐教學面臨的挑戰

但是,要支持敏捷開發的連續跟蹤和反饋的課程實踐模式是很困難的,尤其是當學生規模比較大的時候。總體來說,要用敏捷開發進行軟件工程課程實踐教學的改革,面臨著以下挑戰[2,5]。

(1) 項目組織。我們的課程有150多名學生,讓大家做同一個項目會缺乏區分度,學生也會覺得單調沒有挑戰性,對課程實踐缺乏興趣。此外,隨著軟件融入社會生產、生活的方方面面,軟件工程課程的實踐教學內容也必須豐富項目的類型,開拓學生的視野并活躍思維。但是,這樣做遇到的問題是:項目從哪里來，如何設計項目使其適合課程的教學內容，如何讓學生選擇項目,在保證公平性的同時,營造相互學習和相互競爭的項目實踐氛圍。

(2) 過程控制。從簡要描述的用戶需求到最終交付原型系統,每個項目的全部開發過程必須在一個學期內完成,軟件是在連續的Scrum周期中不斷快速迭代開發及交付的。為了保證敏捷開發過程的最佳效果,我們需要跟蹤每個團隊的進度和活動,對每個迭代周期提供反饋,并定期檢查和評估進度[6-7]。這樣做工作量巨大,因此在課程中需要采用大量的自動化工具來協助教師進行開發過程的管理。

(3) 過程評估。我們不僅需要評估最終交付的軟件產品的質量,也需要評估團隊中每個學生在軟件開發過程中的表現:既要有規范量化的客觀評價機制,同時也需要一些定性的工作評價(比如項目過程中的交流與合作)；既要把每個團隊作為一個整體進行評估，也要區分團隊中每名學生在項目中的個人貢獻。在評價過程中,評分和排名對于團隊項目來說是很困難的,特別是對于開發質量的度量和人員的評估[8],這些都需要特別的考慮和分析。

針對以上需求,我們精心設計了軟件工程課程的實踐教學方案,搭建起了相應的支撐平臺。本文介紹了在課程組織、過程管理、過程評估和工具開發等方面的探索以及總結的經驗。介紹了課程設計的目標、項目的選擇和項目團隊的設置，Scrum過程和支持持續質量控制的平臺，以及提出了評估的指標和度量方法,并對課程情況進行了統計分析。最后總結全文并討論未來的工作。

4 敏捷開發軟件工程實踐教學課程的設計

軟件課程是我校本科三年級的必修課,學生已經經歷了編程語言、數據結構和算法的學習。在本門課程中需要培養學生系統的軟件開發方法,掌握軟件開發的技能,并參與真實的軟件工程實踐過程中。因此,設立以下目標,并設計了相應的實踐內容來配合這些目標。

3.1 實踐教學課程的目標

(1) 全過程參與。通過完成一個真實項目,學生體驗到軟件開發的全過程,包括從用戶界面到應用邏輯,從數據存儲到網絡交互,從模塊設計到層次管理,以及滿足功能和非功能需求的權衡,這些都是在真實軟件開發過程中會遇到的。

(2) 工程素養。學生需要在實踐過程中遵循軟件工程規范,養成良好的開發習慣,如消除不良代碼、連續的版本控制、進行基于覆蓋的單元測試等。學生需要掌握了解工具鏈的重要性,并實踐各種軟件開發工具,以幫助檢查編碼風格、檢查錯誤和測試覆蓋率等。經過一個學期的軟件項目開發中的反復使用及強化,這種做法應該成為學生今后在工程開發中的良好習慣。

(3) 迭代開發和增量開發。對于一個只具有基本編程技能的學生來說,從一開始就設計一個復雜的系統是非常困難的。學生需要逐步理解需求,熟悉各種開發框架和軟件工具。因此,課程的實踐教學過程需要精心的設計,以指導學生逐步搭建起系統,并逐步完善。通過這一過程,學生了解到需要將需求分解成可實現的小任務,并逐漸掌握如何將系統分解成耦合度較小的模塊,方便其開發。

(4) 團隊的組織與協作。在團隊中,每一個學生承擔著不同的角色和職責,有團隊領導,也有系統構架師,也包括負責質量控制的人員。在實踐教學中,需要推動團隊成員密切合作,不僅僅與團隊成員之間需要合作,他們也需要與用戶密切合作。同時團隊成員需要學會平衡成員之間的工作量,以激發每個參與者的積極性,并做出相應的貢獻。同時,學生也可能需要與其他團隊進行合作,組成和整合自己的子系統。

3.2 項目的多樣性

實踐項目的選擇是實際教學中的一個關鍵問題,許多學校都嘗試引入真正工業界的項目,但是,考慮到學生的背景和課程設置的局限性,很難找到具有適當規模、復雜性和工作量適中的工業項目[9]。在我們的嘗試中,也有同樣的問題,主要是:

(1) 班級規模很大。每年有140～180人選修此課程,造成小組指導和監督需要大量的工作量。

(2) 學生水平參差不齊,80%名學生是三年級的學生,20%是二年級的學生。在全部學生中,大約只有20%的學生有較豐富的開發經驗,而其他學生只有幾百行規模代碼的編寫經歷。

為了解決這個問題,一個合理的解決方案就是提供多樣化的項目選擇,使不同層次、不同興趣的學生都能找到適合自己的項目。

因此,選擇了來自不同領域的項目供學生選擇,這些項目有工業界的、學校內部的,也有學生自己挑選的,代表了不同客戶類型、不同復雜性和難度級別、不同體系結構風格和技術的項目。表1顯示了過去3年中項目來源的統計數據,其中包括與其他課程的聯合項目、校園用戶、學生組織的項目和真正的工業客戶的項目。一些典型的項目有:學生電臺的點播(VOD)系統、工業界公司的高可用信息分發系統、基于人臉識別Web API的簽到系統、基于Android藍牙協議的車輛娛樂系統等。

表1 項目來源

項目來源的多重性使得項目種類豐富,讓學生在選擇過程中有了很高的靈活性,激發了學習興趣,同時通過跨個項目之間的交流也豐富了學生在實踐中的經驗。

3.3 雙贏團隊

在一個學期的課程實踐教學中,這些大三為主的學生需要大量的教師指導、頻繁的項目交流和快速的開發反饋才能建立起課程知識系統的概念,因此需要尋找更多的資源來幫助學生進行學習,更好地掌握課程知識。

在課程教學中,邀請了用戶代表提供相關領域的知識,并為每個項目設置一個助教。助教一般由高年級修過軟件工程課程的學生擔任，這樣,每個項目小組由多個開發團隊、一名高年級學生助教和一名用戶代表組成。一般來說,每個開發團隊由3～5名成員組成,學生自由結合。這樣,每個學期大約有40個小組,每個項目大約有5個小組。圖2描述了項目小組和團隊的組織結構。

圖2 項目小組構成

這樣的團隊方式被稱為“雙贏團隊”,我們希望通過這種方式來倡導一種團隊文化,使隊友都在團隊中占有舉足輕重的地位,作為一個整體共進退的集體。

4 對項目管理的持續質量控制

如圖3所示,項目分成3個管理階段。

在開課前的4周,教師就開始聯系潛在用戶并收集項目建議書,要求項目按照課程進行調整,從中篩選出適合課程實踐教學需求的項目作為學生實驗備選項目。在開學的第一周,項目助教對每個項目進行介紹,然后學生自由組成開發團隊,選擇相應的項目。這樣,項目小組就由用戶代表、助教和學生開發團隊形成了。在接下來的9周內,整個團隊共同完成系統的開發過程。在每個項目小組的Scrum過程中,用戶代表、助教和開發團隊在每一個迭代周期(1～2周)中見面,給用戶展示迭代成果,并由用戶提出建議或者新的需求；而項目助教每周都與開發團隊見面,討論開發進度。在這過程中,我們把文檔作為一個反思過程,讓學生進一步回顧和總結開發過程和經驗。整個開發結束后,每個開發團隊的項目成果都需要打包,并部署在指定的云平臺或客戶提供的環境中,并與必要的描述文件和配置文件一并交付給用戶。

為了更好地支持過程管理,我們在GitLab版本控制系統[10-11]基礎上搭建了一個項目管理平臺,圖4為此項目管理平臺的體系結構。

圖3 項目開發過程

圖4 項目管理平臺

學生的日常開發工作是使用GitLab進行版本控制的,每次提交到GitLab后會自動運行Jenkins和Codeface,進行編譯、測試和分析。Jenkins和Codeface對每次提交產生不同的報告,這些報告自動發送給學生,同時也發送給系統中的評估工具來對本次提交進行評估。Jenkins和Codeface都是開源的軟件工具,Jenkins可以集成各種插件工具,這樣它就可以支持各種類型的項目分析,包括編碼風格等。它也可以與Docker和xUnit框架整合,支持自動編譯和測試。Codeface具有各種項目統計的功能,如版本號、代碼行數、注釋行數等。它也可用于連接到GitLab的數據庫進行更深入的過程分析。

5 項目評估和結果

在項目的評估中有以下原則:

(1) 不只評價團體成果, 也評估各成員的貢獻。盡管我們鼓勵學生在一個團隊中同甘共苦,但仍然會有個別學生表現得非常突出,也有的在團隊中貢獻很少。在團隊得分的基礎之上,評估會根據個人的表現和貢獻賦予相應的獎勵或懲罰分數。

(2) 不只評價最終成果, 也評估開發中間結果。在項目管理平臺的支持下,我們不斷采集項目報告并評估項目進度,每次項目提交都會有相應的評價,與傳統的項目評價相比,全過程中的評價能給學生快速反饋和指導。

(3) 不只評價軟件產品, 也評估項目管理過程。我們設置了一些項目管理的評估點,包括工作計劃的安排和執行、團隊成員之間的工作量平衡、客戶參與度和團隊建設等。

在課程的項目開發過程中,項目管理平臺會根據收集到的各種統計數據,產生當前各個項目開發團隊的評估結果,并實時顯示在項目管理平臺上,同時也會給出相應的分數以及各團隊的排名情況。有了這些評分和排名,將會激勵各個開發團隊,產生同行競爭。如圖5所示為系統產生的報告,圖5(a)顯示的是對課程中所有的項目進行的包括提交、協作、分支、工作量和工作計劃在內的不同方面項目健康狀態的統計。每個方面都劃分了4個等級,優秀、良好、一般和差,并顯示了每個等級包含項目的數量。圖5(b)是對每個開發團隊的統計數據,它表明了每個學生的行為,如提交、更新、問題等。

課程的評價標準就是根據這些評估原則進行設計的,如分支評價、提交評價和協作評價等。

圖5 項目管理平臺統計

在軟件的并行開發過程中,項目管理上有著不同的分支模式[12]。盡管在版本控制系統中廣泛使用分支,但是并行開發中各成員并不能很好地遵守開發規范,往往導致分支和合并無法順利完成,并行開發無法順利進行下去。這通常是學生使用版本控制中遇到的一個嚴重的問題,可以通過避免分支來解決此問題,但這就失去了并行開發的意義。在課程中,定義一個指標來評估一個項目的分支是否合理、是否符合團隊開發的模式。例如,一個評估點是“不同的任務應該在不同的分支上實現,這些任務應該在稍后合并到主分支”。如果一個項目沒有分支,或者沒有及時合并分支,項目評分將會被拉低。

版本管理中提交到項目庫也需要遵循一定的準則,例如應以合理的頻率提交更改,過于頻繁的提交可能表明不夠謹慎,未經測試就提交了；而過少的提交數量表明缺乏足夠的版本控制,這兩種情況都將受到處罰。另一個指標是提交的注釋的質量,提交應該有高質量的文檔,這意味著提交應該包含足夠的說明,短于長度閾值的注釋將被扣分。

團隊協作可以衡量團隊成員之間的工作量是否平衡,一個指標是根據代碼貢獻量來評估工作量,然后根據每個團隊成員的工作量的標準差來進行評價各成員工作量是否平衡,也就是團隊協作的情況,較小的標準差表明團隊有更好的合作。圖6顯示了一個開發團隊的各項評估指標,其中雷達圖顯示了該團隊項目質量的一個多維評價,包括分支、合作、工作量等。

圖6 項目質量度量

為了激勵學生的積極參與和踴躍競爭,每個團隊成員個人和團體也有排名,圖7顯示了每個人的提交排名統計,包括總提交數、每周提交數和每月提交數。

圖7 提交排名情況

通過頻繁的反饋和評估,學生的工程實踐能力明顯得到了提高。與其他沒有使用敏捷開發和強化質量控制課程的學生相比,我們課程的學生在團隊協作方面的表現要明顯好于他們。在工程素養方面,圖8顯示了整個學期分支和協作的平均分數變化曲線,可以看出2個分數在逐漸提高,這表明學生越來越習慣于良好的工程習慣。

圖8 持續改善

6 結語

本文介紹了在軟件工程課程實踐教學中3年的探索與研究。課程實踐采用多樣化的項目設置,使用定制的敏捷開發模式,設計開發了項目管理平臺能夠支持持續的質量監控和評估,同時設計定義了評估標準。通過課程的實踐教學過程,希望能夠幫助學生在盡可能真實的環境中體驗現代開發技術和開發過程,積累軟件工程的經驗。

致謝:感謝所有參與到本課程中的教師、用戶以及學生的支持,特別感謝Wolfgang Mauerer博士和他的團隊提供的Codeface工具,共享他們的知識和經驗。

參考文獻(References)

[1] Anslow C，Maurer F. An experience report at teaching a group based agile software development project course [J]. ACM SIGCSE’, 2015(15):500-505.

[2] Chatley R， Field T. Lean learning: applying lean techniques to improve software engineering education [J]. ICSE-SEET’,2017(17):117-126.

[3] Laplante P A. An agile, graduate, software studio course [J]. IEEE Transactions on Education, 2006, 49(4):417-419.

[4] Martin R. Agile Software Development: Principles, Patterns, and Practices [M]. London: Pearson, 2013.

[5] Ghezzi C， Mandrioli D. The challenges of software engineering education [J]. ICSE’,2005(5):115-127.

[6] Marques M. Monitoring - an intervention to improve team results in software engineering education [J]. ACM SIGCSE’,2016(16):724-724.

[7] Paasivaara M, Vanhanen J, Heikkila V T, et al. Do High and Low Performing Student Teams Use Scrum Differently in Capstone Projects? [J]. ICSE-SEET’,2017(17):146-149.

[8] Alperowitz L, Dzvonyar D, Bruegge B. Metrics in Agile project courses [J]. ACM ICSE’,2016(16):323-326.

[9] van Vilet H. Reflections on software engineering education [J]. IEEE Software, 2006,23(3):55-61.

[10] Feliciano J, Storey M A, Zagalsky A. Student experiences using GitHub in software engineering courses: a case study [J]. ICSE’, 2016(16):422-431.

[11] Rayana R B, Killian S, Trangez N, et al. GitWaterFlow: a successful branching model and tooling, for achieving continuous delivery with multiple version branches [J]. RELENG 2016,2016:17-20.

[12] Appleton B, Berczuk S P, Cabrera R, et al. Streamed lines: Branching patterns for parallel software development [J]. Proceedings of PloP,1998.