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

(清華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)系, 北京 100084)

隨著Web 2.0和軟件即服務(wù)的興起,軟件開(kāi)發(fā)模式在近幾年有了很大改變。遵照Web 2.0的原則,在線更新以及頻繁發(fā)布已經(jīng)是大多數(shù)互聯(lián)網(wǎng)軟件的常態(tài)。作為一種輕量型的軟件開(kāi)發(fā)方法,敏捷開(kāi)發(fā)應(yīng)運(yùn)而生,也成為軟件工程教學(xué)的一個(gè)主要改革方向。

1 敏捷開(kāi)發(fā)過(guò)程

圖1是一個(gè)敏捷開(kāi)發(fā)方法Scrum的過(guò)程。用戶提出的產(chǎn)品需求被分解成小的用戶故事,每個(gè)迭代周期在制定計(jì)劃時(shí)選擇實(shí)現(xiàn)一部分需求。經(jīng)過(guò)1～2周到1個(gè)月的迭代過(guò)程形成可交付的軟件增量。迭代過(guò)程中,團(tuán)隊(duì)成員每天討論前一天完成的工作和當(dāng)天的任務(wù)。

圖1 Scrum開(kāi)發(fā)過(guò)程

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

2 敏捷開(kāi)發(fā)軟件工程實(shí)踐教學(xué)面臨的挑戰(zhàn)

但是,要支持敏捷開(kāi)發(fā)的連續(xù)跟蹤和反饋的課程實(shí)踐模式是很困難的,尤其是當(dāng)學(xué)生規(guī)模比較大的時(shí)候?？傮w來(lái)說(shuō),要用敏捷開(kāi)發(fā)進(jìn)行軟件工程課程實(shí)踐教學(xué)的改革,面臨著以下挑戰(zhàn)[2,5]。

(1) 項(xiàng)目組織。我們的課程有150多名學(xué)生,讓大家做同一個(gè)項(xiàng)目會(huì)缺乏區(qū)分度,學(xué)生也會(huì)覺(jué)得單調(diào)沒(méi)有挑戰(zhàn)性,對(duì)課程實(shí)踐缺乏興趣。此外,隨著軟件融入社會(huì)生產(chǎn)、生活的方方面面,軟件工程課程的實(shí)踐教學(xué)內(nèi)容也必須豐富項(xiàng)目的類(lèi)型,開(kāi)拓學(xué)生的視野并活躍思維。但是,這樣做遇到的問(wèn)題是:項(xiàng)目從哪里來(lái)，如何設(shè)計(jì)項(xiàng)目使其適合課程的教學(xué)內(nèi)容，如何讓學(xué)生選擇項(xiàng)目,在保證公平性的同時(shí),營(yíng)造相互學(xué)習(xí)和相互競(jìng)爭(zhēng)的項(xiàng)目實(shí)踐氛圍。

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

(3) 過(guò)程評(píng)估。我們不僅需要評(píng)估最終交付的軟件產(chǎn)品的質(zhì)量,也需要評(píng)估團(tuán)隊(duì)中每個(gè)學(xué)生在軟件開(kāi)發(fā)過(guò)程中的表現(xiàn):既要有規(guī)范量化的客觀評(píng)價(jià)機(jī)制,同時(shí)也需要一些定性的工作評(píng)價(jià)(比如項(xiàng)目過(guò)程中的交流與合作)；既要把每個(gè)團(tuán)隊(duì)作為一個(gè)整體進(jìn)行評(píng)估，也要區(qū)分團(tuán)隊(duì)中每名學(xué)生在項(xiàng)目中的個(gè)人貢獻(xiàn)。在評(píng)價(jià)過(guò)程中,評(píng)分和排名對(duì)于團(tuán)隊(duì)項(xiàng)目來(lái)說(shuō)是很困難的,特別是對(duì)于開(kāi)發(fā)質(zhì)量的度量和人員的評(píng)估[8],這些都需要特別的考慮和分析。

針對(duì)以上需求,我們精心設(shè)計(jì)了軟件工程課程的實(shí)踐教學(xué)方案,搭建起了相應(yīng)的支撐平臺(tái)。本文介紹了在課程組織、過(guò)程管理、過(guò)程評(píng)估和工具開(kāi)發(fā)等方面的探索以及總結(jié)的經(jīng)驗(yàn)。介紹了課程設(shè)計(jì)的目標(biāo)、項(xiàng)目的選擇和項(xiàng)目團(tuán)隊(duì)的設(shè)置，Scrum過(guò)程和支持持續(xù)質(zhì)量控制的平臺(tái)，以及提出了評(píng)估的指標(biāo)和度量方法,并對(duì)課程情況進(jìn)行了統(tǒng)計(jì)分析。最后總結(jié)全文并討論未來(lái)的工作。

4 敏捷開(kāi)發(fā)軟件工程實(shí)踐教學(xué)課程的設(shè)計(jì)

軟件課程是我校本科三年級(jí)的必修課,學(xué)生已經(jīng)經(jīng)歷了編程語(yǔ)言、數(shù)據(jù)結(jié)構(gòu)和算法的學(xué)習(xí)。在本門(mén)課程中需要培養(yǎng)學(xué)生系統(tǒng)的軟件開(kāi)發(fā)方法,掌握軟件開(kāi)發(fā)的技能,并參與真實(shí)的軟件工程實(shí)踐過(guò)程中。因此,設(shè)立以下目標(biāo),并設(shè)計(jì)了相應(yīng)的實(shí)踐內(nèi)容來(lái)配合這些目標(biāo)。

3.1 實(shí)踐教學(xué)課程的目標(biāo)

(1) 全過(guò)程參與。通過(guò)完成一個(gè)真實(shí)項(xiàng)目,學(xué)生體驗(yàn)到軟件開(kāi)發(fā)的全過(guò)程,包括從用戶界面到應(yīng)用邏輯,從數(shù)據(jù)存儲(chǔ)到網(wǎng)絡(luò)交互,從模塊設(shè)計(jì)到層次管理,以及滿足功能和非功能需求的權(quán)衡,這些都是在真實(shí)軟件開(kāi)發(fā)過(guò)程中會(huì)遇到的。

(2) 工程素養(yǎng)。學(xué)生需要在實(shí)踐過(guò)程中遵循軟件工程規(guī)范,養(yǎng)成良好的開(kāi)發(fā)習(xí)慣,如消除不良代碼、連續(xù)的版本控制、進(jìn)行基于覆蓋的單元測(cè)試等。學(xué)生需要掌握了解工具鏈的重要性,并實(shí)踐各種軟件開(kāi)發(fā)工具,以幫助檢查編碼風(fēng)格、檢查錯(cuò)誤和測(cè)試覆蓋率等。經(jīng)過(guò)一個(gè)學(xué)期的軟件項(xiàng)目開(kāi)發(fā)中的反復(fù)使用及強(qiáng)化,這種做法應(yīng)該成為學(xué)生今后在工程開(kāi)發(fā)中的良好習(xí)慣。

(3) 迭代開(kāi)發(fā)和增量開(kāi)發(fā)。對(duì)于一個(gè)只具有基本編程技能的學(xué)生來(lái)說(shuō),從一開(kāi)始就設(shè)計(jì)一個(gè)復(fù)雜的系統(tǒng)是非常困難的。學(xué)生需要逐步理解需求,熟悉各種開(kāi)發(fā)框架和軟件工具。因此,課程的實(shí)踐教學(xué)過(guò)程需要精心的設(shè)計(jì),以指導(dǎo)學(xué)生逐步搭建起系統(tǒng),并逐步完善。通過(guò)這一過(guò)程,學(xué)生了解到需要將需求分解成可實(shí)現(xiàn)的小任務(wù),并逐漸掌握如何將系統(tǒng)分解成耦合度較小的模塊,方便其開(kāi)發(fā)。

(4) 團(tuán)隊(duì)的組織與協(xié)作。在團(tuán)隊(duì)中,每一個(gè)學(xué)生承擔(dān)著不同的角色和職責(zé),有團(tuán)隊(duì)領(lǐng)導(dǎo),也有系統(tǒng)構(gòu)架師,也包括負(fù)責(zé)質(zhì)量控制的人員。在實(shí)踐教學(xué)中,需要推動(dòng)團(tuán)隊(duì)成員密切合作,不僅僅與團(tuán)隊(duì)成員之間需要合作,他們也需要與用戶密切合作。同時(shí)團(tuán)隊(duì)成員需要學(xué)會(huì)平衡成員之間的工作量,以激發(fā)每個(gè)參與者的積極性,并做出相應(yīng)的貢獻(xiàn)。同時(shí),學(xué)生也可能需要與其他團(tuán)隊(duì)進(jìn)行合作,組成和整合自己的子系統(tǒng)。

3.2 項(xiàng)目的多樣性

實(shí)踐項(xiàng)目的選擇是實(shí)際教學(xué)中的一個(gè)關(guān)鍵問(wèn)題,許多學(xué)校都嘗試引入真正工業(yè)界的項(xiàng)目,但是,考慮到學(xué)生的背景和課程設(shè)置的局限性,很難找到具有適當(dāng)規(guī)模、復(fù)雜性和工作量適中的工業(yè)項(xiàng)目[9]。在我們的嘗試中,也有同樣的問(wèn)題,主要是:

(1) 班級(jí)規(guī)模很大。每年有140～180人選修此課程,造成小組指導(dǎo)和監(jiān)督需要大量的工作量。

(2) 學(xué)生水平參差不齊,80%名學(xué)生是三年級(jí)的學(xué)生,20%是二年級(jí)的學(xué)生。在全部學(xué)生中,大約只有20%的學(xué)生有較豐富的開(kāi)發(fā)經(jīng)驗(yàn),而其他學(xué)生只有幾百行規(guī)模代碼的編寫(xiě)經(jīng)歷。

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

因此,選擇了來(lái)自不同領(lǐng)域的項(xiàng)目供學(xué)生選擇,這些項(xiàng)目有工業(yè)界的、學(xué)校內(nèi)部的,也有學(xué)生自己挑選的,代表了不同客戶類(lèi)型、不同復(fù)雜性和難度級(jí)別、不同體系結(jié)構(gòu)風(fēng)格和技術(shù)的項(xiàng)目。表1顯示了過(guò)去3年中項(xiàng)目來(lái)源的統(tǒng)計(jì)數(shù)據(jù),其中包括與其他課程的聯(lián)合項(xiàng)目、校園用戶、學(xué)生組織的項(xiàng)目和真正的工業(yè)客戶的項(xiàng)目。一些典型的項(xiàng)目有:學(xué)生電臺(tái)的點(diǎn)播(VOD)系統(tǒng)、工業(yè)界公司的高可用信息分發(fā)系統(tǒng)、基于人臉識(shí)別Web API的簽到系統(tǒng)、基于Android藍(lán)牙協(xié)議的車(chē)輛娛樂(lè)系統(tǒng)等。

表1 項(xiàng)目來(lái)源

項(xiàng)目來(lái)源的多重性使得項(xiàng)目種類(lèi)豐富,讓學(xué)生在選擇過(guò)程中有了很高的靈活性,激發(fā)了學(xué)習(xí)興趣,同時(shí)通過(guò)跨個(gè)項(xiàng)目之間的交流也豐富了學(xué)生在實(shí)踐中的經(jīng)驗(yàn)。

3.3 雙贏團(tuán)隊(duì)

在一個(gè)學(xué)期的課程實(shí)踐教學(xué)中,這些大三為主的學(xué)生需要大量的教師指導(dǎo)、頻繁的項(xiàng)目交流和快速的開(kāi)發(fā)反饋才能建立起課程知識(shí)系統(tǒng)的概念,因此需要尋找更多的資源來(lái)幫助學(xué)生進(jìn)行學(xué)習(xí),更好地掌握課程知識(shí)。

在課程教學(xué)中,邀請(qǐng)了用戶代表提供相關(guān)領(lǐng)域的知識(shí),并為每個(gè)項(xiàng)目設(shè)置一個(gè)助教。助教一般由高年級(jí)修過(guò)軟件工程課程的學(xué)生擔(dān)任，這樣,每個(gè)項(xiàng)目小組由多個(gè)開(kāi)發(fā)團(tuán)隊(duì)、一名高年級(jí)學(xué)生助教和一名用戶代表組成。一般來(lái)說(shuō),每個(gè)開(kāi)發(fā)團(tuán)隊(duì)由3～5名成員組成,學(xué)生自由結(jié)合。這樣,每個(gè)學(xué)期大約有40個(gè)小組,每個(gè)項(xiàng)目大約有5個(gè)小組。圖2描述了項(xiàng)目小組和團(tuán)隊(duì)的組織結(jié)構(gòu)。

圖2 項(xiàng)目小組構(gòu)成

這樣的團(tuán)隊(duì)方式被稱(chēng)為“雙贏團(tuán)隊(duì)”,我們希望通過(guò)這種方式來(lái)倡導(dǎo)一種團(tuán)隊(duì)文化,使隊(duì)友都在團(tuán)隊(duì)中占有舉足輕重的地位,作為一個(gè)整體共進(jìn)退的集體。

4 對(duì)項(xiàng)目管理的持續(xù)質(zhì)量控制

如圖3所示,項(xiàng)目分成3個(gè)管理階段。

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

為了更好地支持過(guò)程管理,我們?cè)贕itLab版本控制系統(tǒng)[10-11]基礎(chǔ)上搭建了一個(gè)項(xiàng)目管理平臺(tái),圖4為此項(xiàng)目管理平臺(tái)的體系結(jié)構(gòu)。

圖3 項(xiàng)目開(kāi)發(fā)過(guò)程

圖4 項(xiàng)目管理平臺(tái)

學(xué)生的日常開(kāi)發(fā)工作是使用GitLab進(jìn)行版本控制的,每次提交到GitLab后會(huì)自動(dòng)運(yùn)行Jenkins和Codeface,進(jìn)行編譯、測(cè)試和分析。Jenkins和Codeface對(duì)每次提交產(chǎn)生不同的報(bào)告,這些報(bào)告自動(dòng)發(fā)送給學(xué)生,同時(shí)也發(fā)送給系統(tǒng)中的評(píng)估工具來(lái)對(duì)本次提交進(jìn)行評(píng)估。Jenkins和Codeface都是開(kāi)源的軟件工具,Jenkins可以集成各種插件工具,這樣它就可以支持各種類(lèi)型的項(xiàng)目分析,包括編碼風(fēng)格等。它也可以與Docker和xUnit框架整合,支持自動(dòng)編譯和測(cè)試。Codeface具有各種項(xiàng)目統(tǒng)計(jì)的功能,如版本號(hào)、代碼行數(shù)、注釋行數(shù)等。它也可用于連接到GitLab的數(shù)據(jù)庫(kù)進(jìn)行更深入的過(guò)程分析。

5 項(xiàng)目評(píng)估和結(jié)果

在項(xiàng)目的評(píng)估中有以下原則:

(1) 不只評(píng)價(jià)團(tuán)體成果, 也評(píng)估各成員的貢獻(xiàn)。盡管我們鼓勵(lì)學(xué)生在一個(gè)團(tuán)隊(duì)中同甘共苦,但仍然會(huì)有個(gè)別學(xué)生表現(xiàn)得非常突出,也有的在團(tuán)隊(duì)中貢獻(xiàn)很少。在團(tuán)隊(duì)得分的基礎(chǔ)之上,評(píng)估會(huì)根據(jù)個(gè)人的表現(xiàn)和貢獻(xiàn)賦予相應(yīng)的獎(jiǎng)勵(lì)或懲罰分?jǐn)?shù)。

(2) 不只評(píng)價(jià)最終成果, 也評(píng)估開(kāi)發(fā)中間結(jié)果。在項(xiàng)目管理平臺(tái)的支持下,我們不斷采集項(xiàng)目報(bào)告并評(píng)估項(xiàng)目進(jìn)度,每次項(xiàng)目提交都會(huì)有相應(yīng)的評(píng)價(jià),與傳統(tǒng)的項(xiàng)目評(píng)價(jià)相比,全過(guò)程中的評(píng)價(jià)能給學(xué)生快速反饋和指導(dǎo)。

(3) 不只評(píng)價(jià)軟件產(chǎn)品, 也評(píng)估項(xiàng)目管理過(guò)程。我們?cè)O(shè)置了一些項(xiàng)目管理的評(píng)估點(diǎn),包括工作計(jì)劃的安排和執(zhí)行、團(tuán)隊(duì)成員之間的工作量平衡、客戶參與度和團(tuán)隊(duì)建設(shè)等。

在課程的項(xiàng)目開(kāi)發(fā)過(guò)程中,項(xiàng)目管理平臺(tái)會(huì)根據(jù)收集到的各種統(tǒng)計(jì)數(shù)據(jù),產(chǎn)生當(dāng)前各個(gè)項(xiàng)目開(kāi)發(fā)團(tuán)隊(duì)的評(píng)估結(jié)果,并實(shí)時(shí)顯示在項(xiàng)目管理平臺(tái)上,同時(shí)也會(huì)給出相應(yīng)的分?jǐn)?shù)以及各團(tuán)隊(duì)的排名情況。有了這些評(píng)分和排名,將會(huì)激勵(lì)各個(gè)開(kāi)發(fā)團(tuán)隊(duì),產(chǎn)生同行競(jìng)爭(zhēng)。如圖5所示為系統(tǒng)產(chǎn)生的報(bào)告,圖5(a)顯示的是對(duì)課程中所有的項(xiàng)目進(jìn)行的包括提交、協(xié)作、分支、工作量和工作計(jì)劃在內(nèi)的不同方面項(xiàng)目健康狀態(tài)的統(tǒng)計(jì)。每個(gè)方面都劃分了4個(gè)等級(jí),優(yōu)秀、良好、一般和差,并顯示了每個(gè)等級(jí)包含項(xiàng)目的數(shù)量。圖5(b)是對(duì)每個(gè)開(kāi)發(fā)團(tuán)隊(duì)的統(tǒng)計(jì)數(shù)據(jù),它表明了每個(gè)學(xué)生的行為,如提交、更新、問(wèn)題等。

課程的評(píng)價(jià)標(biāo)準(zhǔn)就是根據(jù)這些評(píng)估原則進(jìn)行設(shè)計(jì)的,如分支評(píng)價(jià)、提交評(píng)價(jià)和協(xié)作評(píng)價(jià)等。

圖5 項(xiàng)目管理平臺(tái)統(tǒng)計(jì)

在軟件的并行開(kāi)發(fā)過(guò)程中,項(xiàng)目管理上有著不同的分支模式[12]。盡管在版本控制系統(tǒng)中廣泛使用分支,但是并行開(kāi)發(fā)中各成員并不能很好地遵守開(kāi)發(fā)規(guī)范,往往導(dǎo)致分支和合并無(wú)法順利完成,并行開(kāi)發(fā)無(wú)法順利進(jìn)行下去。這通常是學(xué)生使用版本控制中遇到的一個(gè)嚴(yán)重的問(wèn)題,可以通過(guò)避免分支來(lái)解決此問(wèn)題,但這就失去了并行開(kāi)發(fā)的意義。在課程中,定義一個(gè)指標(biāo)來(lái)評(píng)估一個(gè)項(xiàng)目的分支是否合理、是否符合團(tuán)隊(duì)開(kāi)發(fā)的模式。例如,一個(gè)評(píng)估點(diǎn)是“不同的任務(wù)應(yīng)該在不同的分支上實(shí)現(xiàn),這些任務(wù)應(yīng)該在稍后合并到主分支”。如果一個(gè)項(xiàng)目沒(méi)有分支,或者沒(méi)有及時(shí)合并分支,項(xiàng)目評(píng)分將會(huì)被拉低。

版本管理中提交到項(xiàng)目庫(kù)也需要遵循一定的準(zhǔn)則,例如應(yīng)以合理的頻率提交更改,過(guò)于頻繁的提交可能表明不夠謹(jǐn)慎,未經(jīng)測(cè)試就提交了；而過(guò)少的提交數(shù)量表明缺乏足夠的版本控制,這兩種情況都將受到處罰。另一個(gè)指標(biāo)是提交的注釋的質(zhì)量,提交應(yīng)該有高質(zhì)量的文檔,這意味著提交應(yīng)該包含足夠的說(shuō)明,短于長(zhǎng)度閾值的注釋將被扣分。

團(tuán)隊(duì)協(xié)作可以衡量團(tuán)隊(duì)成員之間的工作量是否平衡,一個(gè)指標(biāo)是根據(jù)代碼貢獻(xiàn)量來(lái)評(píng)估工作量,然后根據(jù)每個(gè)團(tuán)隊(duì)成員的工作量的標(biāo)準(zhǔn)差來(lái)進(jìn)行評(píng)價(jià)各成員工作量是否平衡,也就是團(tuán)隊(duì)協(xié)作的情況,較小的標(biāo)準(zhǔn)差表明團(tuán)隊(duì)有更好的合作。圖6顯示了一個(gè)開(kāi)發(fā)團(tuán)隊(duì)的各項(xiàng)評(píng)估指標(biāo),其中雷達(dá)圖顯示了該團(tuán)隊(duì)項(xiàng)目質(zhì)量的一個(gè)多維評(píng)價(jià),包括分支、合作、工作量等。

圖6 項(xiàng)目質(zhì)量度量

為了激勵(lì)學(xué)生的積極參與和踴躍競(jìng)爭(zhēng),每個(gè)團(tuán)隊(duì)成員個(gè)人和團(tuán)體也有排名,圖7顯示了每個(gè)人的提交排名統(tǒng)計(jì),包括總提交數(shù)、每周提交數(shù)和每月提交數(shù)。

圖7 提交排名情況

通過(guò)頻繁的反饋和評(píng)估,學(xué)生的工程實(shí)踐能力明顯得到了提高。與其他沒(méi)有使用敏捷開(kāi)發(fā)和強(qiáng)化質(zhì)量控制課程的學(xué)生相比,我們課程的學(xué)生在團(tuán)隊(duì)協(xié)作方面的表現(xiàn)要明顯好于他們。在工程素養(yǎng)方面,圖8顯示了整個(gè)學(xué)期分支和協(xié)作的平均分?jǐn)?shù)變化曲線,可以看出2個(gè)分?jǐn)?shù)在逐漸提高,這表明學(xué)生越來(lái)越習(xí)慣于良好的工程習(xí)慣。

圖8 持續(xù)改善

6 結(jié)語(yǔ)

本文介紹了在軟件工程課程實(shí)踐教學(xué)中3年的探索與研究。課程實(shí)踐采用多樣化的項(xiàng)目設(shè)置,使用定制的敏捷開(kāi)發(fā)模式,設(shè)計(jì)開(kāi)發(fā)了項(xiàng)目管理平臺(tái)能夠支持持續(xù)的質(zhì)量監(jiān)控和評(píng)估,同時(shí)設(shè)計(jì)定義了評(píng)估標(biāo)準(zhǔn)。通過(guò)課程的實(shí)踐教學(xué)過(guò)程,希望能夠幫助學(xué)生在盡可能真實(shí)的環(huán)境中體驗(yàn)現(xiàn)代開(kāi)發(fā)技術(shù)和開(kāi)發(fā)過(guò)程,積累軟件工程的經(jīng)驗(yàn)。

致謝:感謝所有參與到本課程中的教師、用戶以及學(xué)生的支持,特別感謝Wolfgang Mauerer博士和他的團(tuán)隊(duì)提供的Codeface工具,共享他們的知識(shí)和經(jīng)驗(yàn)。

參考文獻(xiàn)(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.