工作總結

本學期主要完成了以下工作：

• 點評：本學期一共對部落格作業點評了97次。

• 作業佈置：基於去年的作業要求進行修改，佈置了熱身部落格作業、個人部落格作業、團隊貢獻分規則、團隊任務拆解、技術規格說明書、功能規格說明書、scrum部落格、測試報告、釋出宣告、事後分析、個人總結等部落格作業。

• 評分：本學期一共對139份部落格作業進行了評分。

• 黃衫評選、收件資訊收集、獲獎部落格催促。

• 分數彙總和計算：團隊專案評審結果、團隊個人貢獻分彙總、個人總分彙總計算。

• 監督相關助教完成相關的程式碼測試、部落格點評和評分工作。

• 團隊轉會協商工作等。

期末調研問卷中收集到的意見

• 減少團隊專案中的部落格要求，給更多學習時間，從而更好地完成專案
  • 任務量大，尤其前期個人及結對專案時部落格作業太多，我們當時還有馮如杯、計算機網路，根本顧不過來寫那麼多繁瑣的部落格作業。
  • 課程前緊後鬆，學期初的強度太大了，進入團隊專案後強度稍減弱。可以縮短團隊專案的間隔時間，比如將測試周和評審周合併，還有中間換人周這種時間都可以適當分給學期初。
  • 在團隊專案過程中多做一些對團隊有輔助性作用的事情，能讓我們更加集中精力於團隊協作的內容，而不是被條條框框約束
  • 目前這門課程的作業負擔略重，既然個人作業、結對作業、團隊作業都是必不可少的環節，我建議把時間和經歷用在刀刃上，適當減少部落格作業的數量。
  • 希望部落格中，能夠引導學生總結所學知識和不足之處，能夠談技術談方法而不是大談感想和記流水賬
  • 一些不必要的部落格可以不用寫
• 前期準備(個人專案/結對專案，或加入新的作業)最好可以跟團隊專案相關聯
• 轉會機制希望可以不要那麼強行
• 可以不考核工作量，鼓勵同學們開發更有意思的東西
• 建議個人專案和結對程式設計專案開發出OJ實時測評反饋的平臺
• 個人作業不建議加入競賽性質的東西
• 多些指導，團隊專案的過程中太鬆了：
  • 增加一些對遠端協作的指導
  • 對於Github等工具的使用是否可以給與一些規範或指導
  • 團隊專案指導太少
  • 建議課程組提供標準的各種文件的書寫規範，方便的話希望拿一些企業內部的文件的規範為我們舉例，專案管理的標準流程也請在課程開始提供，沒必要完全讓同學們自己摸索，所謂課程不就是教同學們少走彎路嗎
• 希望在未來的課程中課程組能夠土工更多的資源，包括伺服器的和專業技術上的，可以讓往屆的同學給學弟學妹面對面展示專案，比從部落格讀來的更生動真實
• 增加討論課，與老師、助教直接交流軟體工程思想，可能是疫情影響，錄播課效果較差
• 6系考期比較靠前，正好與beta衝刺重合，希望能調整一下
• 希望課程組提供的伺服器能更好一些，不要讓同學們在伺服器這方面卡太久
• 可以適當延長團隊專案的執行總時間，減少前面部分的學習時間。
• 希望能調整個人專案和結對專案的形式，可以更加多樣化一些
• 希望能有一個更開放的問答平臺，可以與其他團隊、有經驗的軟體工程人員交流在開發過程中遇到的問題

反思

• 在點評方面：由於自己的技術儲備、知識儲備比較少，因此點評的時候經常翻來覆去問的都是那麼幾個共性問題，沒法給出一些針對性的建議和意見。我覺得這樣的點評可能並沒有太大意義，後面可以考慮讓幾位能力比較強的助教專門負責點評。
• 在部落格評分機制方面：為公平起見，考慮助教評分的標準可能不同，建議直接每次的作業都只由1人評分，並改為等級評分制，從實踐角度來說，我覺得是可行的，因為當評分標準確定後，評分工作其實不會花費過多時間。
• 關於助教總結：其實一部分是記錄流水賬，一部分是記錄遇到的問題和解決方案，前者其實我覺得沒有必要記錄，而後者其實可以記錄到一篇部落格中，每週更新，便於對比，也便於下一屆的助教檢視。
• 很多同學提到，在開發中這一點是很重要的， 一定要有有經驗的人去帶， 要不很容易陷入低效程式碼重複編寫的迴圈，我覺得是十分在理的，每個團隊都必須有一個技術頂樑柱，根據這一點，我覺得在之後的團隊人員構建時，課程組可以做些工作，而不是讓同學們自由組隊。課程組可以設計激勵機制，比如先讓有軟體開發經驗、學習能力強、並且願意帶新生的大佬站出來，然後以其為中心，構建團隊，當然該大佬也能夠獲得一定的分數獎勵。
• 根據期末的課程反饋問卷，下面分別針對各個作業和階段進行反思：
  • 熱身作業和個人部落格作業：可以考慮合併起來成一個大的部落格作業，時間變成2-3周，開學前就可以佈置，因為看教材確實需要一些時間。
  • 個人專案和結對專案：與團隊專案脫離，且偏向於演算法設計，測試起來也比較麻煩。可以考慮將個人和結對專案改成更偏向於開發框架的個人作業，讓大家瞭解一些常見的開發框架，最好有多個題目可供選擇。可以選擇給出完整自洽的教程，也可以選擇不做過多指導和約束。結對專案，可以在個人專案的基礎上進行提升，做進一步開發，讓同學們學習一些更難掌握的開發框架和技巧。
  • 軟體案例分析：可以從這裡開始，就讓大家自己去思考自己在團隊階段要做什麼軟體，並進行調研，自行選擇幾個相關軟體案例進行分析。不僅讓同學們學會如何分析軟體，而且讓同學們能夠通過對軟體的對比調研，來初步規劃自己的軟體開發想法。因此，本作業佈置時，就可以考慮給出一些備選的、可以繼續開發的、上幾屆的軟體，或者是老師認為的、有需求的、從零開發的軟體，作為一個參考，讓同學們去調研相關的軟體並進行分析。
  • 團隊專案選擇和開發：我覺得可以對往屆所有專案做一個分類整合整理，給同學們提供思路，也避免重複造輪子。很多同學反映團隊階段的部落格量太大，而在部落格內容方面，很多同學也反映希望更加偏向技術和方法，而不是大談感想和記流水賬。每日例會確實需要開展，但是每天記錄一個流水賬scrum部落格確實沒有必要，如果只是為了記錄每天的進度，那麼完全可以有更合適更精簡的記錄方法。