? ? ? ?本學(xué)期的敏捷軟件開發(fā)課程要求學(xué)生自己組隊(duì)（4人）使用Scrum方法開發(fā)一個(gè)項(xiàng)目。我們一隊(duì)四人雖然以前沒有實(shí)際scrum開發(fā)經(jīng)驗(yàn)爷肝，但是靠課上以及參考資料的指導(dǎo)，還是在努力踐行Scrum流程與思想金赦。本文內(nèi)容包括以下三部分：在校研究生踐行Scrum的固有困難夹抗、我們的實(shí)踐過程及過程中對(duì)流程的適應(yīng)與改造、Scrum對(duì)于學(xué)生的一般性課程項(xiàng)目的潛在價(jià)值兔朦。

在校研究生踐行Scrum的固有困難

? ? ? ?顯然沽甥，Scrum實(shí)踐已經(jīng)默認(rèn)了應(yīng)用的團(tuán)隊(duì)是一個(gè)全日制工作的、工作技能熟練的開發(fā)團(tuán)隊(duì)亥曹。在此基礎(chǔ)上恨诱，才有可能組建“全職能團(tuán)隊(duì)”，才有可能“把辦公桌安排在一起”蛇受，并在旁邊樹立看板作為信息輻射器厕鹃，讓大家隨時(shí)了解Sprint進(jìn)度之類的信息。
? ? ? ?而這些要求把将，對(duì)于在校研究生來說忆矛，并不現(xiàn)實(shí)。首先洽议，大家選的課程并不相同漫拭，在大家的閑暇時(shí)間重疊不多的情況下，還有可能有其他活動(dòng)占去這些寶貴時(shí)間儿捧。這導(dǎo)致能夠做到一起工作挑宠、即時(shí)交流反饋的機(jī)會(huì)很少各淀。其次，（由于本專業(yè)熱門）一部分研究生本科并非本專業(yè)碎浇，基礎(chǔ)薄弱奴璃，影響工作質(zhì)量，本人所在團(tuán)隊(duì)就有這種情況抄课。即使是基礎(chǔ)較好的學(xué)生雳旅，如果課程項(xiàng)目提出了對(duì)新技術(shù)/框架的使用需求，也會(huì)變成基礎(chǔ)薄弱的開發(fā)者抵拘，影響工作效率與質(zhì)量型豁。
? ? ? ?綜上所述，在校研究生踐行Scrum的固有困難是“共同工作時(shí)間少導(dǎo)致交流受阻”與“水平不足墩瞳、需要大量時(shí)間來學(xué)習(xí)和踩坑導(dǎo)致工作效率氏豌、質(zhì)量低”。受這兩個(gè)因素影響泪电，在校研究生想要采取某些Scrum實(shí)踐可謂困難重重纪铺。比如：由于工作效率低鲜锚，人數(shù)也不多苫拍，所以幾乎不可能支持結(jié)對(duì)編程旺隙；由于共同時(shí)間少，協(xié)作靠QQ群垄提，所以請(qǐng)求到響應(yīng)的時(shí)間間隔很長周拐。

我們的實(shí)踐過程及過程中對(duì)流程的適應(yīng)與改造

? ? ? ?本團(tuán)隊(duì)從使用故事地圖進(jìn)行需求分析之后妥粟，便開始進(jìn)入迭代開發(fā)階段。從那時(shí)到假期有三周半备恤，我們便決定把時(shí)間分成3個(gè)迭代锦秒，每個(gè)迭代持續(xù)一周。
? ? ? ?首次會(huì)議包括對(duì)這三個(gè)迭代的功能點(diǎn)的大致劃分以及對(duì)Sprint1的故事的分解惭笑、分工生真。在會(huì)議上，我們得到了以下商討結(jié)果：

1. 由于沒有“客戶參與”川蒙，驗(yàn)收標(biāo)準(zhǔn)就沒法非常精確长已。雖然之前大致寫了故事驗(yàn)收標(biāo)準(zhǔn)术瓮，但設(shè)計(jì)得復(fù)雜還是簡單，要不要復(fù)雜的安全性保障機(jī)制等等恬汁，都沒有說明辜伟。所以我們最終同意從流程中去掉每周展示會(huì)議脊另，只要前后端調(diào)試成功尝蠕，前端開發(fā)能夠覆蓋功能點(diǎn)即可载庭。
2. 由于共同開發(fā)時(shí)間不好找廊佩，所以“進(jìn)度自行把握”，取消每日站會(huì)顽铸，不規(guī)定共同開發(fā)時(shí)間料皇。
3. CI平臺(tái)作為敏捷開發(fā)關(guān)鍵要素之一践剂，應(yīng)當(dāng)盡快搭建并納入使用。前端由于微信小程序的特殊性質(zhì)优质，不使用CI军洼。
4. 兩名同學(xué)開發(fā)SprintBoot框架的后端、兩名同學(xué)開發(fā)微信小程序前端避乏。協(xié)作依靠后端發(fā)布甘桑、更新api文檔扇住，溝通靠QQ群。
5. 計(jì)劃按照故事點(diǎn)的數(shù)目將所有故事平均分到三個(gè)迭代中去锄贼。第一次迭代完成優(yōu)先級(jí)最高的1/3的故事點(diǎn)的需求女阀。

? ? ? ?在這樣的結(jié)果下屑迂，我們開始了Sprint1開發(fā)惹盼。本人與另一名同學(xué)A負(fù)責(zé)微信小程序前端惫确。提出前端使用微信小程序形式的就是A同學(xué)，而本人其實(shí)并不熟悉微信小程序開發(fā)掩蛤。在Sprint1的一周內(nèi)陈肛，團(tuán)隊(duì)內(nèi)的主要交流便是api文檔的發(fā)布句旱。以及在QQ群里對(duì)于api文檔的少量修改要求。我們主要感受到的問題包括：

1. “注冊(cè)/登錄”等輔助功能其實(shí)不比普通的業(yè)務(wù)故事的工作量要少腥泥，然而在故事地圖里面沒有寫到這些功能港华。
2. 后端SpringBoot技術(shù)比較簡單，負(fù)責(zé)的B冒萄、C兩名同學(xué)很快就完成了api設(shè)計(jì)與實(shí)現(xiàn)橙数，配合CI自動(dòng)部署灯帮，兩天就完成了Sprint1的開發(fā)工作。而前端與其進(jìn)度差異巨大迎献。對(duì)于本人腻贰、B、C冀瓦，學(xué)習(xí)微信小程序開發(fā)都是較大的工作量翼闽。這使得我們無法按照Scrum說明的“有余力的開發(fā)者應(yīng)當(dāng)主動(dòng)承擔(dān)更多任務(wù)”，給B尼啡、C分配前端任務(wù)询微。而我也幾乎只是完成了微信小程序的大致學(xué)習(xí)拓提。
3. 由于沒有共同工作時(shí)間隧膘、沒有站會(huì)，交流只靠QQ群蹦疑，所以當(dāng)A發(fā)現(xiàn)了api設(shè)計(jì)不合理之處并在QQ群要求修改時(shí)萨驶，得到反饋的時(shí)間間隔相當(dāng)長腔呜。
4. 在上面1、2膝但、3的情況疊加下谤草，A幾乎只完成了注冊(cè)丑孩、登錄功能。從前端來看略贮，Sprint1的故事全都沒有完成。

? ? ? ?對(duì)于以上問題古拴，我們?cè)赟print1回顧會(huì)議上面進(jìn)行了仔細(xì)分析真友，認(rèn)為問題的根源是交流不暢盔然。所以我們?cè)赟print2中進(jìn)行以下流程改進(jìn)：

1. 根據(jù)每人的課程表，（雖然不容易挺尾，也要）規(guī)劃出都有空閑的共同工作時(shí)間站绪，即使每兩天只能規(guī)劃3小時(shí)恢准，也能對(duì)于難度較低的本項(xiàng)目起到幫助。
2. 每兩天（與共同工作的頻率一致）晚上11點(diǎn)在一間宿舍開一次站會(huì)涂召，交流共同開發(fā)以及自己零碎時(shí)間開發(fā)的成果敏沉。
3. 作為一種松散的要求盟迟，大家多看看QQ群，盡可能及時(shí)處理其他成員提出的要求轮锥。

? ? ? ?經(jīng)過改進(jìn)以后要尔，我們?cè)赟print2工作效率上升明顯赵辕。我們清空了Sprint1遺留下來的故事，也完成了Sprint2新計(jì)劃的故事饲握。雖然本人學(xué)習(xí)完成、效率提升對(duì)這個(gè)結(jié)果有貢獻(xiàn)衰粹，但我們明顯能夠感到：共同工作笆怠、及時(shí)交流修改的流程確實(shí)為整體經(jīng)驗(yàn)不足的團(tuán)隊(duì)帶來了提升蹬刷。
? ? ? ?在Sprint2的工作中，我們?nèi)匀辉庥隽艘恍╅_發(fā)上的障礙：

1. 在后端同學(xué)更新完api文檔之后泡态，發(fā)布的是Markdown格式的某弦。由于api的更新不是在共同工作時(shí)間完成的而克，更新時(shí)有時(shí)負(fù)責(zé)前端的同學(xué)在上課或者沒帶電腦只有手機(jī)拍摇，就不方便檢查api的設(shè)計(jì)缺陷馆截。如果后來忘記充活，就會(huì)一直等到前端開發(fā)到這個(gè)接口時(shí)，才會(huì)發(fā)現(xiàn)問題蜡娶。這時(shí)修改又會(huì)耽誤時(shí)間混卵。
2. 后端雖然寫了單元測試，但由于對(duì)測試框架的不熟悉窖张，發(fā)生過把request parameter當(dāng)成request body(json)的情況幕随，還測試成功了（說明實(shí)現(xiàn)代碼寫錯(cuò)了）。結(jié)果前端根據(jù)api開發(fā)宿接，怎么也調(diào)不好赘淮，最終發(fā)現(xiàn)是后臺(tái)開發(fā)經(jīng)驗(yàn)不足導(dǎo)致。

針對(duì)這些問題睦霎，我們?cè)赟print2回顧會(huì)議上，研究出了一些解決辦法：

1. 每次上傳更新的api副女，也在QQ群里傳一份pdf格式的蛤高，保證前端開發(fā)者即使只有手機(jī)也能及時(shí)檢查。這樣有機(jī)會(huì)使一些api修改提前。
2. 除了自動(dòng)化的單元測試戴陡，也使用Postman軟件進(jìn)行每個(gè)接口的測試塞绿。Postman測試用例可以導(dǎo)入導(dǎo)出。當(dāng)后端開發(fā)自測成功恤批，便導(dǎo)出易讀易理解的Postman測試用例集合給前端開發(fā)异吻，保證兩組人對(duì)于api有著共同理解。

? ? ? ?接下來我們將開始Sprint3的開發(fā)开皿。在本迭代內(nèi)涧黄，我們有可能會(huì)繼續(xù)調(diào)整流程，使得流程更加適合我們的具體情況赋荆。

Scrum實(shí)踐對(duì)于學(xué)生的一般性課程項(xiàng)目的價(jià)值

? ? ? ?在本次Scrum實(shí)踐中（雖然項(xiàng)目還沒有結(jié)束）笋妥，我們體會(huì)到了許多Scrum實(shí)踐對(duì)于我們課程項(xiàng)目的價(jià)值：

1. CI工具的使用。我們使用了Jenkins對(duì)系統(tǒng)后端進(jìn)行了自動(dòng)構(gòu)建部署窄潭，每當(dāng)Github代碼更新春宣，便集成一次。這使得我們?cè)诔跗诒緛淼沧驳拈_發(fā)有了一絲光明嫉你。過去開發(fā)C-S架構(gòu)項(xiàng)目月帝，調(diào)試時(shí)可能需要頻繁修改，也就伴隨著頻繁的手動(dòng)構(gòu)建部署幽污，令人不勝其煩嚷辅。這次我們部署好Jenkins一套，雖然SonarQube只起到了令人心煩的作用距误，但其它部分都實(shí)打?qū)嵉販p少了我們的工作量簸搞。甚至當(dāng)測試出現(xiàn)問題（unstable build）或部署失敗（failure）准潭，還能自動(dòng)發(fā)郵件提醒趁俊。
2. 短迭代周期確實(shí)降低了修改成本。雖然我們目前只完成了兩次迭代刑然，但由于后端開發(fā)經(jīng)驗(yàn)不足寺擂，api頻繁修改。令人欣慰的是泼掠，由于每個(gè)迭代新增的故事點(diǎn)數(shù)目可控怔软，新增的api數(shù)量也可控，這樣犯錯(cuò)范圍小择镇，影響范圍小爽雄。這樣在迭代結(jié)束時(shí)，本迭代內(nèi)的設(shè)計(jì)缺陷都能夠修復(fù)沐鼠，下一次迭代對(duì)之前api的影響很小挚瘟，后端數(shù)據(jù)庫設(shè)計(jì)每次修改幅度小叹谁，前端實(shí)現(xiàn)修改幅度也小。我們的項(xiàng)目才能夠快速進(jìn)步乘盖。如果按照以前一次設(shè)計(jì)完所有接口焰檩，開發(fā)時(shí)到處都是問題，可能所有接口會(huì)因此修改多遍订框，相應(yīng)的前端開發(fā)也會(huì)嚴(yán)重受阻析苫。
3. 多迭代周期配合任務(wù)看板降低了拖延癥發(fā)生風(fēng)險(xiǎn)。如果粗放地將三周半時(shí)間劃為一個(gè)長Sprint穿扳，將所有故事點(diǎn)一次全放進(jìn)看板衩侥，那么即使合理設(shè)置了截止時(shí)間，團(tuán)隊(duì)成員在看到長長的任務(wù)清單矛物，也會(huì)望而生畏茫死，想把任務(wù)往后拖。這種情況一般只發(fā)生與學(xué)生團(tuán)隊(duì)履羞，不影響職業(yè)開發(fā)者（畢竟被老板開了就沒飯吃了）峦萎。一個(gè)迭代周期任務(wù)未完成的看板（尤其是變成紅色的日期）能給學(xué)生帶來更大的危機(jī)感，促使學(xué)生在下一個(gè)迭代進(jìn)行努力工作忆首。同時(shí)爱榔，迭代的順利完成會(huì)成為對(duì)團(tuán)隊(duì)成員的激勵(lì)，使其更有動(dòng)力接受下一次的挑戰(zhàn)糙及，治愈拖延癥详幽。這對(duì)于職業(yè)開發(fā)者也適用。