軟工網絡15教學總結

網絡15課程環節的反饋

根據網絡15的試卷收集反饋，主要談談須要改進的部分：

1. 教材
   • 對話形式不太理解
   • 名詞的解釋偏少
   • 頁碼標識不便於查找
2. 源碼管理
   • 應當增強Git練習
   • 給出如何寫代碼的基礎教學連接
   • 缺乏對代碼的審覈
   • 對源碼控制重視不夠
   • 燃盡圖應與Git綁定：源代碼的提交記錄與燃盡圖上的item以及issue管理對應
3. 團隊項目
   • 題目應儘早告知
   • 持續時間太長（幾乎整個學期）
   • 部分同窗認爲衝刺時間過短
   • 增強對團隊成員分工角色的指導
   • 划水現象、大佬1拖n現象
   • 購買項目，造假問題
4. 複審和打分環節
   • 沒有具體條目，複審時只要求提問題
   • 提供項目複審的排名評分參考
   • 建議：複審時讓負責每一個具體模塊的成員分別講述
5. 課程打分體系
   • 千帆競發圖不容易找到本身的分數
   • 團隊項目比較出彩的應當多加分
6. 博客
   • 部分重複，致使重複寫
   • 過於強調博客
   • 博客量太大
7. 結對編程
   • 考慮設置難度梯度，讓不一樣程度的同窗可根據難易程度去選擇完成
   • 考慮只寫一篇博客，而後給出我的感覺的博客連接

網絡14畢業生的反饋

1. 軟件工程的教學模式很不錯。作的時候比較累（學生與老師），吐槽也多，但回過頭來發現這樣的鍛鍊是有用的，確實有學到東西。
2. 大量使用流行工具，對就業有幫助。
3. 兩極分化。厲害的全作，差的只能寫寫博客與文檔。
4. 同一個學期課程太多。
5. 前期開發基礎不牢，不容易作軟件工程。
6. 不想搞開發的也要學軟件工程？

7. 博客這種方式很好。

   分析

   1.有的課程確實須要必定的量才能起到效果，可是學生老師都比較累。從網絡16級開始，軟件工程列爲軟件開發方向必選，其餘方向選修。能夠下降老師工做量，提升質量。
   2.兩極分化問題：只要存在團隊化合做的課程，都存在這樣的問題。只能經過更細緻的劃分任務來避免一拖n的現象。而且，只要在一個團隊，即便有的同窗沒法編碼，但仍是要完成文檔等，也算通過了必定的訓練。
   3.同一學期課程太多：彷佛沒有好辦法。

教學團隊

本次教學團隊包括周筠老師和助教總教頭劉乾，以及擔任本輪教學的三位助教分別來自北航的王文基和來自集美大學網絡14級的龔曉婷、尤少輝。感謝周筠老師的提醒和鼓勵，劉乾的指導和建議，三位助教的積極配合，在完成本身的學習之餘還須要利用業餘時間對每份做業進行點評。

1. 做爲十分有經驗的劉乾，老是能在關鍵時刻提出很好的建議，幫助你們解決問題，克服困難，指導尤少輝完成性能測試部分
2. 周筠老師在團隊中的積極協調，對每位成員進行協調和談心，督促你們及時完成教學任務
3. 積極參與做業評分標準的制定，每週做業發佈以前須要由助教制定相應的評分標準
4. 在班級羣裏表揚做業完成較好的同窗和團隊
5. 對團隊抱大腿、大佬1拖n現象的探討
6. 鑑於alpha階段對代碼審覈存在的問題在beta階段增強了對源碼的審覈，同時在班級羣裏與各團隊進行交流與提問
7. 針對學生在博客裏提到的一些問題進行討論
8. 針對抄襲和代碼造假問題的探討
9. 王文基參與團隊做業測試部分的佈置，當另外兩位助教須要參加畢設答辯時，主動承擔全部的做業批改
10. 及時解答同窗們關於做業評分的疑問，增強對博客的點評與回覆
11. 尤少輝走入課堂與學弟學妹們面對面交流，分享本身的學習心得
12. 龔曉婷制定問題列表收集

不足：

1. 與同窗們的互動交流有待增強
2. 後期因爲兩位助教須要參加畢設答辯，做業評分有些滯後
3. 如何能讓三位助教之間的打分標準更加一致

課程反思與改進

相比網絡14，網絡15的軟工課程教學作了一些調整：

1. 單獨列出理論知識點，經過課堂小測鞏固知識點
2. 增強課堂對做業的點評
3. 將團隊組隊提早至第三週，爲alpha階段和beta階段衝刺留出空餘時間
4. 分別對alpha階段beta階段進行項目複審和排序
5. 利用碎片時間增強博客評論與互動
6. 邀請學長助教進入課堂，分享學習心得

須要改進部分：

1. 團隊組隊和換人機制？
2. 如何增長同窗們在團隊項目中的參與度，並鍛鍊需求分析已經其餘技能
   • 問題：同窗們的團隊項目每每拍腦殼就想出來，並無很嚴肅地作各類軟件工程的調查。中途拍大腿後悔， 最後拍屁股走人，項目爛尾。
   • 問題：同窗們對於其餘團隊的項目不太關心， 喪失了不少的學習機會。 
     • 採用鄒老師給的建議：解決：作成有趣的場景， 讓同窗們專一於分析各個項目的成功的可能性， 讓同窗們本身用批判的眼光分析問題，這也是很是重要的鍛鍊。
     • 具體步驟：
       • 讓全部團隊根據 NABCD 本身審覈一下本身的團隊項目，把 NABCD 元素加到本身的團隊博客的項目說明中， 同時說明預期的 「項目發佈後3天的用戶量」。 能夠給機會讓同窗們修改團隊項目，全部團隊發表博客。
       • 而後， 全部團隊寫一個博客， 依次評價其餘團隊的項目立項 NABCD， 排名次 （名次沒有並列）。 助教統計全部名次， 名次最低的團隊必須作出重大修改， 包括選一個新的項目。
       • 能夠用風險投資作比喻 ， 每一個學生都是有錢的風投資本家， 要給這個班級的全部項目投資， 10 個團隊項目你只能投6 個， 你投哪些？ 請列出你的選擇。 有些同窗們不是很想創業，作有意思的項目吸引風投嗎？ 這就讓他們練習實際的風投。 例如， 同窗能夠對任意項目投資， 每一個項目能夠投 一元錢。  學期最後前三名的項目， 這個項目組的同窗就能獲得當初投資的錢。 若是這個項目在學期最後沒有進入前 3 名， 這個錢就歸老師分配。 老師拿了這些錢作獎品， 例如：再分給那些投資了前三名團隊的學生。
3. 結對編程
   • 考慮ping-pong式的結對編程（A寫測試，B寫實現，而後 B寫下一個測試，A寫重構和實現）
4. 項目複審環節
   • 要求每一個團隊每一個成員介紹本身負責的部分
   • 針對各個負責部分進行提問
5. 代碼抄襲
   • 能夠整合別人的代碼， 可是要事先說明， 並註明來源。 沒有說明的，視爲抄襲。
   • 增強代碼審覈
   • 能夠在最後彙報階段要求列出代碼簽入的歷史， 並現場演示從代碼倉庫同步代碼，在本機編譯，構建， 併發布到目標機器的過程。
6. 加強與同窗的互動
   • 發佈課程公告
   • 答疑

心得與收穫—生活須要磨練

有學生提到：若是沒有軟工，個人幸福指數爲100（捂臉）我也想說：若是沒有軟工，我會輕鬆不少（^0^）。之因此選擇這樣的方式去開展軟工教學，是由於我認爲經過這種實操「作中學」的實踐方式，偏偏是最能體現軟工的本質含義，可以培養最基本的軟工素養。有強度的練習是軟工的基本要求。沒有必定的實踐量和代碼量談不上在學軟工。

引自吉林大學法學院教授的演講：

教育的本質就是要經過不斷提出新的挑戰、給學生以適當的壓力來幫助孩子迎接挑戰、打敗壓力從而達到自我實現。吃苦這件事情是繞不過去的，老子說：「多易必多難」。人生無處不是選擇，你越是在前半程作出容易的選擇，你就越會在後半程面對艱難的處境。

朋友圈裏曾看到的一段話，深覺得然：
井裏沒有水，而是挖的不夠深；
不是成功來的慢，而是你放棄的快；
因此成功沒有奇蹟，生活須要磨鍊。