軟體工程(FZU2015) 助教總結

SE_FZU目錄：[1](http://www.cnblogs.com/math/p/4820808.html) [2](http://www.cnblogs.com/math/p/4827832.html) [3](http://www.cnblogs.com/math/p/4833301.html) [4](http://www.cnblogs.com/math/p/4852995.html) [5](http://www.cnblogs.com/math/p/4870584.html) [6](http://www.cnblogs.com/math/p/4890133.html) [7](http://www.cnblogs.com/math/p/4916062.html) [8](http://www.cnblogs.com/math/p/4919227.html) [9](http://www.cnblogs.com/math/p/4935697.html) [10](http://www.cnblogs.com/math/p/4976461.html) [11](http://www.cnblogs.com/math/p/5066939.html) [12](http://www.cnblogs.com/math/p/5100034.html) [**13**](http://www.cnblogs.com/math/p/5104644.html)

本次建構之法-SE助教工作，和福州大學張老師協作，福大學生基本發揮出了一定水準，在此做個小結。

教師

張老師本身的SE教學經驗足夠豐富，對教學工作中的教師、助教、學生的角色定位清晰，整體節奏和安排合理，同時在題目細節、時間和進度上能接受我的建議，采用更緊湊的風格，加上FZU學生的整體有效配合（一群認真想要學好SE的大學生），是以整體進度還不錯。在時間上，張老師能根據學生的具體情況做适當調整；實踐項目上，張老師堅持在主線上以個人項目、結對項目、團隊項目循序漸進疊代，并且在項目内容上保持增量式，同時輔以練習、案例分析、增補作業等做為補充，保持學生練手的節奏；在評分規則上，我和張老師的協商都挺有效率，一旦協商确定就不再改動。整體上和張老師的協作是有效率的，主線是：充分協商->各自嚴格執行（課堂内，網絡上）。張老師也堅持讓學生們在做每個環節的時候都使用工具，學生們在整個SE過程中，練習和使用了相對多的工具，這點在他們的SE期末總結上也展現出來，我覺的這是一個好的要素，工程上的過程是多階段的，分工是多角色的，每個階段，每個角色都能充分利用甚至制造工具去提高效率，則有章法。

針對張老師，我重點談下題目設計和教學進度控制兩點。

題目設計上，如果全部推給助教，實際上助教并不能一上來就設計出良好的循序漸進的SE題目，我在這點上亦一開始還是有所擔憂，不過這學期，張老師主動承擔了大部分的題目設計，他根據自己學校學生的特點，針對性的設計了适合他們的增量題目，我覺的整體上有利于教學的循序漸進展開。我在這個點上做的是review題目的活，主要還是review：

1. 時序問題。
   • 開始的時間是否過于靠後，越後面的時間點，臨近期末會越不好展開。
   • 截止日期問題，給的時間不能太長。
   • 作業次序問題，例如不能連續一個月都是文檔性的作業，這個點上保證有程式設計項目的頻率。
2. CheckList
   • 題目的要求必須明确，盡量少用含糊的概詞，多用具體的量詞。
   • 題目要求的檢查點盡量可量化，利于評分

教學進度控制上，主要也在時序和内容上。例如盡量在學期開始有效把個人作業疊代起來。把本來張老師計劃安排在11月份才開始的alpha，提前到10月份中旬，避免10月份都沒有程式設計任務。内容上，張老師認為學校裡的靈活并不容易搞起來，我的建議是教學内容和步驟可以是瀑布的，但項目的疊代進度還是以alpha+beata的scrum沖刺的形式進行。這點上堅持下來了。後面還行。

學生

接着說福大的學生。

FZU的學生基本沒有抄襲的，這點很好，就可以直接關注在具體的練習的内容品質上。FZU的學生還是有部分會回報，這點實際上不能強求，助教能做的就是堅持陳述句+提問的方式做好每次點評，如有回報算是收益。

FZU的學生群，有匿名吐槽，不過其實他們隻是說說而已，完了該做還是會做，而且在夾帶吐槽的過程中，也實際上會對SE的相關内容進行互動，算是一種增強SE知識點的過程。學生群裡引入了北航的個别優秀學生進來，也使得學生群的交流氛圍有互相學習的效果，當然這要适當，不可強求。我覺的這算是一種自然有思辨的課堂環境，張老師做的挺好，松以讨論，嚴以規則，适當引導。學生群裡也偶爾對單次作業做問卷調查，由于群的氛圍還可以，是以FZU的學生大部分都樂意填寫群裡發起的問卷，以及期中的教學品質匿名問卷和期末的匿名自評問卷，這些調查的統計性結果回報給張老師，利于本次課堂以及下一次課堂的改進。

FZU的學生項目實踐，這學期也在git的使用，以及github上花費了一定的時間，以源代碼版本管理為線，在個人項目上練習基本的源碼版本管理、在結對、團隊項目上練習了多人協作以及issue管理，同時輔以燃盡圖對項目進度有整體控制。有部分學生對git和github的使用和了解已經比較熟練，可以說比很多已經工作了的程式員都掌握的好。雖然因為網絡問題，大家比較折騰了一點。也有老師在說是否可以用國内的git倉庫。但我個人是堅持認為應該用github，我的理由是：

1. github是目前全世界程式員最主流的源碼倉庫，連microsoft、google、facebook等知名IT公司都在上面有自己的開源項目首頁，我不知道這能持續多少年（以前svn時代是sf.net）,但目前它是，是以我堅持認為既然要用git的某個倉庫，就應該用它，而非國内的某個git倉庫中心。
2. 我希望學生們以後的自己其他項目也都能用github，能直接在一流的源碼倉庫上幹活，就不必退而求其次，好的開放社群，長期效果是更好的。當然這兩點隻是我個人的看法。

助教

最後說下我自己。我覺的最大的收獲是，把自己能做的基本工作做到位即可。我想SE教學當然不可能一次就能解決所有問題，但在一次的過程中，我是抱着把自己能做的基本工作做到位的想法去的。本來有三個點：出題、點評、評分。不過出題上，張老師承擔較多，我就退化為Review即可，點評這點，做到最核心的要求：保證所有部落格都能有及時點評，這點到後面已經習以為常，并沒什麼壓力，手機上利用碎片時間刷刷也能點評完，反正一般人每天刷微網誌刷朋友圈也都浪費很多時間，刷部落格點評其實隻是切換了這個時間片，點評的内容可以是：

1. 無論他做了什麼，既然做了，就應該給予簡單肯定。不過明顯太水的就算了。
2. 部落格本身的bug，例如少了連結、沒了照片...等等看似無關緊要的細節，這點也是從鄒老師的一些點評中學習，細節上既然說了，或者要求了，如果沒做到，就可以點評出來。
3. 給出進一步疊代的建議。
4. 針對性給出提問，例如某一點在SE上的現成的做法，提問+建議，推動實施。
5. 緊扣基本點（多看書多看書）不厭其煩指出了，例如alpha+beta，基本都是那些點，學生是“洗耳恭聽，堅決不改”的，如有能及時接收建議回報改進的就算是收益，退一步“就是不改，但是做完”也算有成。我覺的這些就是需要在每篇部落格下“重複”點評，而不是在助教自己部落格上給個總結式點評。當然，我想肯定有有人覺的我好煩，那沒辦法，這是一個課程，課程結束我就不會去煩他了。
6. 适當的外部連結，我也不知道有多少人會去點選看。
7. 去github上fork、star、clone學生的項目代碼，review他們的代碼，例如：編碼規範、子產品劃分、單元測試、功能等，能跑的就跑起來體驗。這些都會用在點評和評分上。
8. 以上的目标都是為了促進學生能疊代，培養他們對疊代的感覺，如果有效疊代就會看到疊代的力量，進而能自我疊代，達到自舉學習的目标。
9. 和老師協商好deadline和要求後，就一定要嚴格執行，沒有嚴格執行就像你的單元測試程式放水一樣，最終會導緻整個項目的品質出問題，bug難尋。那麼當然有些人會錯過1，2次作業，怎麼辦？靠做額外的作業彌補！是以邏輯就是：一次作業釋出的規則和deadline就要嚴格執行，錯過了靠增加新的作業和練習補救。既能保證教學項目的疊代，又能增加學生的練習次數。

最後，是評分。這個點上，我基本能做到按時評分，我覺的評分算是教學項目裡的單元測試，及時Test，出分，每個角色：教師、學生、助教、其他人，都能看到一個環節的品質和進度，這算是一個教學本身的scrum沖刺。我在這個過程中，認識到無論是學生的SE學習，還是教學本身，保持節奏是一件重要的事情：在一個milestone裡，保持連續、均勻、細節到位的疊代。這點也是我希望所有的SE學生們都能意識到（通過已經過去的實踐項目），并且在以後的職業生涯中（無論你幹什麼）去再次體會，實踐的事情。另外一點是，我認為在每個milestone，都應該對時間是敏感的，充分意識到時間隻會越來越少，是以能打提前量的就打提前量，不必每個milestone都到最後才去沖刺，如果不是課堂項目，你提前完成一個milestone，實際上可以利用多餘的時間，立刻投入到下一個milestone的前置工作。

評分的内容上（參考：http://www.cnblogs.com/math/p/5066939.html）：

1. 疊代完善給出動态的評分機制。畢竟每個老師都不一樣，需要和他們随時協調。例如alpha和beta，我需要跟張老師協調過程和驗收的比例。例如作業和練習分數的分開。加分的特例等。我采用的是動态的改進評分的表格，并且逐漸細化計算的公式。公式展示的是計算的細節，說明我們并不是泛泛給分，而是嚴格考察每個checkitem。不過我也想要是企業裡的HR這樣給我們算KPI，我會好煩，太嚴格太細緻是令人窒息的，不過這是個人感慨，并不影響我的助教工作。
2. 每次給出兩個排行榜：柱狀圖和累積表格。表格的項目，也逐漸給出縮寫表頭，我當然喜歡全英文的表頭，以顯“Professional”,不過也會根據情況看是否利于閱讀和排版。這裡強調一點就是不給學生的名字，隻給學号後3位和部落格id，這點我覺的以後的助教都可以參考，反正一錘子解決部分老師對學生隐私的顧慮。然後，堅持表格裡有可點選的超連結，當然我覺的理想情況是每個分數項都是對應單篇部落格的超連結，不過偷懶的話，就隻要在部落格Id那一列給學生的部落格首頁即可。
3. alpha和beta階段可以把團隊的具體評分過程也dump出來。alpha和beta的1/3和1/2，3/4的時間點可以私下對那些進度落後的team給個warning，不過我并沒做，主要是自己也忙，而且怕被當作spam。不過評分的時候，可以把過程分的計算給出。這是一個子表，子表的内容也是遵循：累加積分項+映射到單次總分的規則。不多說，用Excel，1/3公式活，1/3編輯體力活，1/3用腳本和工具批處理，我覺的自己以前用Excel并不多，這個過程中反而進一步熟練了。

還有一些其他的細節，也會有利于幹活，例如：

1. 部落格園上我關注班級的老師、學生的所有部落格，這樣我隻要在部落格園個人頁面上的部落格那一欄即可看到每天誰更新了部落格，保證及時點評。
2. 部落格園上設定别人的回複資訊會提示（我不喜歡它發送的郵件，郵件畢竟會漏看，不如自己主動去刷部落格園檢視資訊提示），這樣能及時收到學生的回報并進一步跟蹤。
3. github上可以适當star學生的項目，利于跟蹤。
4. 使用腳本（我用的是LinqPad寫C#腳本，處理日常的統計，批量處理Word、Excel等，我以前買過它的代碼自動完成，.NET又是全功能類庫，友善），我覺的每個程式員都應該掌握1個自己熟練的腳本語言，正規表達式，做日常批處理。

大概這樣，我覺的這些工作，除去點評部分需要經驗的地方，也許并不需要多麼資深的業界工程師才能做到，如果助教(無論是校内還是校外)能把這些嚴格做到位，可以完成同樣品質。即使是經驗的部分，我之前也并未有系統的SE學習，反而是在建構之法的SE助教過程中才系統學習，當然如果一個SE班級在基本點上都沒問題，那麼會進入進一步比拼SE的知識點上，如果SE的基本知識點上又都沒問題，那麼就進入比拼産品了，畢竟産品和使用者才是最終考驗點，從這點來說，我也覺得是需要該課程進一步疊代的地方。我覺的我在基本的要求上做了一些，但是其實如果同樣的過程，換一個學校，一個老師，一些學生，情況又會大不一樣，可能不同情況下所需要的“基本工作”會不一樣。但一旦找到需要的基本點，嚴格執行，應該是一個重要的事情。