這學期已經結束，助教的工作也告一段落。第一次當助教，這一學期，有收穫也有教訓，還是用文字記錄下來，給自己一個總結，也給其他人一個參考。
背景
這學期開設軟體工程的班級是南通大學大三的學生，共計44人，採用的教材是《構建之法》，講師鞠老師，我是助教。
作業透過部落格的方式完成。主要的溝通方式是透過部落格的點評和QQ群。在分工上：
- 作業：作業題目由講師擬定，助教參與提供意見
- 點評：講師和助教共同對作業在部落格上點評
- 評分：講師評分，助教根據作業結果反饋做的好的和不好的
前期準備工作和計劃
在學期初，和鞠老師有討論過一些準備工作和計劃。大概是：
- 瞭解學院領導對於課程結果的期望。由於這學期南通大學是試點教學，希望教學中可以考慮學院領導期望，以後可以繼續採用新的教學模式進行教學
- 準備一個實際專案讓學生分組完成
- 課程安排參考《構建之法》的課程安排建議
實際執行情況
和學院領導溝通的結果
鞠老師跟學院領導溝通後，學院領導對這門課的期望結果是：
- 沒有硬性的考核指標；
- 期望最終的學生對教師的評價儘量好；
- 期望能帶出少量動手能力較強的學生（學生團隊）；
- 確保那些較差的學生能透過課程的學習（考試），達到基本要求。
相對來說這個要求還是比較寬鬆的，正常應該可以達到。最終結果還需要鞠老師那邊反饋一下。
實際專案的準備
在討論專案時，鞠老師和我都提出了很多想法，比如做手機App、做網站應用等，中間也有和鄒老師溝通，發現絕大部分想法還是脫離實際，沒有考慮到學生的技術基礎和硬體條件，最終討論的結果是做一個Android的手機App，第一版本做簡單的Hello World，第二版本做一個簡易計算器，第三版本學生自己選題。
實際課程安排
作業一
第一次作業主要是開通部落格，同學們基本上都能完成，也有個別同學是大段抄襲。鄒老師對這次作業題目也有很好的點評：
老師怎樣出題目，才能預防抄襲？
- 不要出“綜述” 這樣的題目， “綜述瀏覽器的發展”。。。 學生只能抄別的綜述。 可以出 “結合自己的具體使用經歷，描述瀏覽器的發展，和自己的體會”。
- 學生可以引用別的文獻，但是要註明來源。
- 講究現場感，例如結對程式設計的總結，一定要有照片顯示兩個人坐在一起程式設計。
- 先把醜話說在前頭， 一旦出現沒有註明的引用，同學間相互抄襲，一律倒扣這次作業所有分數。
作業二 多維陣列求和
這次作業是參考構建之法的課程安排，對每個人的程式設計能力進行摸底，讓每個人練練自己的手藝。
實際作業大家完成的非常不理想，第一次作業直到有一位同學完成後，並且他寫了個小工具幫助分享給大家，後面的同學們才陸續完成，並且都和第一個同學的結果差不多。同時因為整體完成情況不理想，作業時間點有後延。
在改完作業後，和鞠老師溝通了下，一方面透過QQ群給大家補課，講了幾次作業，鞠老師也在課堂上對作業進行了講解。但講解和補課效果不理想，一方面薄弱的程式設計基礎沒辦法透過短期培訓彌補，另一方面透過網路的教學效果也不好。
透過這次作業我們也發現像林傑、張振淵這樣的核心同學如果能好好培養，是能帶動其它同學的。但可惜這樣的同學還是太少，所以後面發揮的帶頭作用也有限。
因為學生的作業提交都有延遲，導致一直對學生們沒有打分結果。在鄒老師提醒後，開始透過部落格公佈了打分情況。
作業三 類的最佳化
這是第一次結對程式設計實踐，同時希望對作業二的問題進行改進最佳化。實際情況和作業二一樣，完成結果不理想，有很多同學時間點到了沒有完成作業，所以後來作業時間點有後延。
這兩次程式設計作業完成情況非常糟糕，總結下主要有兩方面的原因：
- 題目本身設計存在問題。學生對於二維三維陣列的理解費力，還需要考慮類的概念
- 學生基礎比較差。南通大學的學生第一學期沒有C語言課程，直接上手C++，其他課程也幾乎沒什麼程式設計練習，缺少實際動手能力。
作業四 軟體分析
這是第一次團隊作業，對軟體進行分析。這次作業鞠老師在佈置時要求比較細，另外沒有程式碼要求，基本都能按照要求完成，但也有的組比較敷衍了事。
作業五 專案的NABC以及計劃
這是第二次團隊作業，進行了團隊分工，確定了PM，讓各個團隊根據《構建之法》的學習分析專案的NABC以及計劃。從作業情況下，學生們對於NABC的理解還有所欠缺，對專案計劃的制定偏理想化，缺乏可操作性。
作業六 電梯系統之結對程式設計
由於前幾次程式設計作業完成不理想，所以這次程式設計作業設計的時候，鞠老師和我反覆商量了下，嘗試降低難度，將一個可以執行的程式故意修改了幾個Bug，讓學生可以簡單分析程式碼並修改即可除錯透過。程式碼釋出到了Github上。
結果一個星期後，沒有一個同學提交作業，中間詢問也沒有什麼反饋，懷疑是Github操作對大家還太難，於是把程式從Github發到了QQ群，即使如此，最終這次作業沒有提交的。
此次作業結果對鞠老師和我“打擊”蠻大，一方面對學生的程式設計基礎很過失望，另一方面我們也對自己作業的設計有懷疑。同時我們也感覺到學生對課程已經沒有什麼信心和興趣。面對這種情況，我們最終決定對這批學生，後面還是偏向理論教學，減少程式設計作業，同時增加課堂互動。
作業七 構建之法互動遊戲
這次課堂互動是鞠老師和我的一次嘗試，目的是增強課堂互動，讓學生能更多參與到構建之法的學習。
這次教學和作業的嘗試非常成功，所有同學都非常投入的參與到這次課堂互動和後續的部落格作業。但在設計上還是有些不足：
- 重點不突出。雖然大家熱情很高，但是和構建之法的教學聯絡偏弱
- 週期偏短。這是個很好的主題，但是如果只是一個單次的作業，一次互動和作業發揮有限，學習有限。如果能設計成一個系列，就可以透過系列完整的學習各個知識點。
作業八 南通大學教務管理系統分析
這次作業主要是透過實踐學習如何需求分析。從作業來看，基本上大家都能發現問題，但是缺少系統科學的分析依據，更少有同學能提出科學的改進方案。
作業九 課程總結
總結一下學生們反饋的問題：
-
反饋最多的是PPT英文比例過多
這個有點出乎意料，但這麼多反饋說明還是要正視這批學生的英文基礎，儘可能用中文的PPT -
程式碼量太少。
整個學期下來，基本都在100行程式碼左右，少數幾個同學程式碼行數超過1000，個別說每天幾百上千行的可信度不高。
這部分主要原因在於我和鞠老師的程式設計作業佈置過少，然後同學們自己在業餘時間也少有編碼的。 -
課堂互動不夠
部分同學反映課堂上互動不夠，容易走神。這個問題我們在中期有所調整，嘗試更多互動，另外在以後的課程還要更多考慮如何和學生之間更多互動，增加學生參與度。
比如有個學生提到了其中一個老師的教學方式可以借鑑的：建議的話希望還是學習陳耀老師的教學方法吧，或許在他的課程上你聽著可能覺得很隨意講的東西簡單卻一遍又一遍的去講解，但是我們從中反而能發現很多實用的東西。第二節課開始又叫我們回憶上節學過什麼教過什麼，加深了我們的記憶。記得他每次問我們上節課講了什麼回答不上來他會叫其他同學回答，切不回去怎麼數落你而是想你記住然後叫你記下來別忘了。http://www.cnblogs.com/lxy95/p/5069547.html -
有同學更喜歡板書的形式，而不是PPT
這個問題我覺得一方面部分學生還是習慣傳統的教學模式，另一方面也是課堂互動不夠導致大家覺得無聊。所以如果能增強互動，應該會好很多。 -
沒有實踐專案，偏理論知識
有幾個同學對參與實際專案是有期望的，但最終我們的專案沒有能做成，還是偏理論教學。
實際工程專案從一開始就有考慮和準備，但是前期的程式設計作業，效果很不太理想，估計大家平時編碼比較少，基礎比較薄弱，所以在後面的電梯結對作業的時候，也針對性調整了，改成在完整專案基礎上改錯，但即使難度降低，整體完成情況還是很不理想，所以最終鞠老師和我商量後調整成課堂上的虛擬專案。 -
語言基礎不夠
從作業情況和反饋來看，這批學生的程式設計基礎確實相對比較薄弱。如果從大一開始重新學習，我會首先自學C語言。大一的時候學校給我們安排的第一門程式語言課程是C++，由於我們從來沒有程式設計的基礎，而C++又相對較難，所以C++學的很艱難，程式設計基礎沒有打好，對程式設計也有了稍許畏難情緒。C語言可以說是程式設計的入門語言，C語言和C++有相通之處，而C語言相對於C++要簡單，容易理解一些，所以我會先自學C語言。 -
軟體專案管理工具的使用偏少
軟體專案管理工具也是軟體專案管理很重要的一環，這個之前沒有考慮過，以後要考慮在課堂中適當介紹並作為作業要求。
總的來說，如鄒老師所言，學生們的部落格有很多有價值的反饋，從某種意義上說， 他們是我們的老師。希望這些反饋對其他老師和助教也有幫助。
總結
以上是上學期的實際執行情況，整體情況不算好，從中有很多經驗教訓。對這些問題總結一下的話主要有這些問題是需要改進的。
改善溝通
溝通問題存在多方面：
-
老師、助教和學生之間的溝通
這次溝通方面一直是很困擾我的一個問題，透過QQ群效果非常不理想，同學們參與度非常低，部落格的點評也少有回覆，這個在鞠老師課堂上提醒後有所好轉，另外很多同學不知道部落格的評論回覆可以郵件訂閱，導致不能及時看到點評。
另外周老師建議學生助教的方式是個值得嘗試的方式，如果有學生作為溝通橋樑，也許能有所改善 -
助教和老師的溝通
在上學期的助教過程中，和鞠老師的溝通還是比較順暢的，很多次作業、調整都是一起商量後的結果。當然還是有改進的地方，比如有時候鞠老師的作業佈置下去了我還不知道。
另外就是分工上也有些模糊的灰色地帶，比如評分這事，我偷懶就沒評分，只是點評。 -
和鄒老師、周老師以及其它助教的溝通
在很多問題上，鄒老師和其它助教已經積累了很多經驗，請教一下可以避免很多問題。同時讓鄒老師及時指導我們進度也有助於及時發現問題。上學期這方面做的不好，還需要加強。
及時反饋
在這次教學過程中，我們一個很大的教訓就是在作業上沒有及時反饋。
- 打分
如果遲遲沒有打分結果公佈，對做的好的學生沒有及時肯定，對於做的差的也沒有給低的分數，不利於激勵和懲戒。這部分需要改進。 - 答案
每次作業可以公佈標準答案，讓學生們可以有標準可以參考。 - 調查
在最後一次作業，做了一次調查反饋，學生們反饋了很多有價值的資訊，所以未來還可以繼續以作業的形式在期中就做一些調查反饋。根據反饋的結果能有及時調整。
程式碼和專案實踐
本次教學，最終沒能進行實際專案實踐，確實是一大遺憾。另外在程式設計作業的佈置上，難度的梯度設定還不夠合理，一開始的作業遠高出了學生的程式設計能力。
以後在程式設計作業的設計上，要從較低的難度開始，根據學生的水平，及時調整後續的難度，提供適合學生水平的作業，不至於打擊學生的積極性和自信心，也讓學生有一點挑戰。
另外上程式碼的行數上，參考鄒老師的標準，可以以1000行為標準。
提高學生參與度和積極性
這次有一點值得肯定的是我們設計的課堂互動遊戲，極大的提高了學生參與度和積極性，只是在設計上還太粗躁，曇花一現後後繼乏力，還需要更多的形式和方式來讓學生積極的參與到學習中。
整體規劃
在學期初時，我們理想的認為只要簡單按照《構建之法》上面的課程安排即可，但是實際上這更多的是一個參考。
- 根據學生能力的不同需要靈活的做出調整。
- 執行時要嚴格，不能有Delay，不然後面一環套一環，就像我們這次，後面很多安排根本就沒辦法實施。
- 在前半學期要多安排內容。鄒老師在一開始時就提醒過我們，在一開始時要多安排內容，這樣學生期末時，就不至於因為要忙考試而單獨進度。
結束語
其實《構建之法》的教學本身也是一個專案：
- 需求分析：分析學生和學院需求，瞭解學生的能力水平
- 設計階段：合理的計劃、老師和助教明確的分工
- 實現階段：嚴格的執行最開始的規劃設計、根據情況及時調整
- 穩定階段：學生們熟悉了新的教學模式，按時完成階段的作業
- 釋出階段：學生們能運用構建之法的知識，分析問題，完成專案
- 維護階段：課程結束了，學生們和老師們都有總結
在教學的過程中，做中學，不斷改進學習。