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：
- 時序問題。
- 開始的時間是否過於靠后，越后面的時間點，臨近期末會越不好展開。
- 截止日期問題，給的時間不能太長。
- 作業次序問題，例如不能連續一個月都是文檔性的作業，這個點上保證有編程項目的頻率。
- CheckList
- 題目的要求必須明確，盡量少用含糊的概詞，多用具體的量詞。
- 題目要求的檢查點盡量可量化，利於評分
教學進度控制上，主要也在時序和內容上。例如盡量在學期開始有效把個人作業迭代起來。把本來張老師計划安排在11月份才開始的alpha，提前到10月份中旬，避免10月份都沒有編程任務。內容上，張老師認為學校里的敏捷並不容易搞起來，我的建議是教學內容和步驟可以是瀑布的，但項目的迭代進度還是以alpha+beata的scrum沖刺的形式進行。這點上堅持下來了。后面還行。
學生
接着說福大的學生。
FZU的學生基本沒有抄襲的，這點很好，就可以直接關注在具體的練習的內容質量上。FZU的學生還是有部分會反饋，這點實際上不能強求，助教能做的就是堅持陳述句+提問的方式做好每次點評，如有反饋算是收益。
FZU的學生群，有匿名吐槽，不過其實他們只是說說而已，完了該做還是會做，而且在夾帶吐槽的過程中，也實際上會對SE的相關內容進行交互，算是一種增強SE知識點的過程。學生群里引入了北航的個別優秀學生進來，也使得學生群的交流氛圍有互相學習的效果，當然這要適當，不可強求。我覺的這算是一種自然有思辨的課堂環境，張老師做的挺好，松以討論，嚴以規則，適當引導。學生群里也偶爾對單次作業做問卷調查，由於群的氛圍還可以，所以FZU的學生大部分都樂意填寫群里發起的問卷，以及期中的教學質量匿名問卷和期末的匿名自評問卷，這些調查的統計性結果反饋給張老師，利於本次課堂以及下一次課堂的改進。
FZU的學生項目實踐，這學期也在git的使用，以及github上花費了一定的時間，以源代碼版本管理為線，在個人項目上練習基本的源碼版本管理、在結對、團隊項目上練習了多人協作以及issue管理，同時輔以燃盡圖對項目進度有整體控制。有部分學生對git和github的使用和理解已經比較熟練，可以說比很多已經工作了的程序員都掌握的好。雖然因為網絡問題，大家比較折騰了一點。也有老師在說是否可以用國內的git倉庫。但我個人是堅持認為應該用github，我的理由是：
- github是目前全世界程序員最主流的源碼倉庫，連microsoft、google、facebook等知名IT公司都在上面有自己的開源項目主頁，我不知道這能持續多少年（以前svn時代是sf.net）,但目前它是，所以我堅持認為既然要用git的某個倉庫，就應該用它，而非國內的某個git倉庫中心。
- 我希望學生們以后的自己其他項目也都能用github，能直接在一流的源碼倉庫上干活，就不必退而求其次，好的開放社區，長期效果是更好的。當然這兩點只是我個人的看法。
助教
最后說下我自己。我覺的最大的收獲是，把自己能做的基本工作做到位即可。我想SE教學當然不可能一次就能解決所有問題，但在一次的過程中，我是抱着把自己能做的基本工作做到位的想法去的。本來有三個點：出題、點評、評分。不過出題上，張老師承擔較多，我就退化為Review即可，點評這點，做到最核心的要求：保證所有博客都能有及時點評，這點到后面已經習以為常，並沒什么壓力，手機上利用碎片時間刷刷也能點評完，反正一般人每天刷微博刷朋友圈也都浪費很多時間，刷博客點評其實只是切換了這個時間片，點評的內容可以是：
- 無論他做了什么，既然做了，就應該給予簡單肯定。不過明顯太水的就算了。
- 博客本身的bug，例如少了鏈接、沒了照片...等等看似無關緊要的細節，這點也是從鄒老師的一些點評中學習，細節上既然說了，或者要求了，如果沒做到，就可以點評出來。
- 給出進一步迭代的建議。
- 針對性給出提問，例如某一點在SE上的現成的做法，提問+建議，推動實施。
- 緊扣基本點（多看書多看書）不厭其煩指出了，例如alpha+beta，基本都是那些點，學生是“洗耳恭聽，堅決不改”的，如有能及時接收建議反饋改進的就算是收益，退一步“就是不改，但是做完”也算有成。我覺的這些就是需要在每篇博客下“重復”點評，而不是在助教自己博客上給個總結式點評。當然，我想肯定有有人覺的我好煩，那沒辦法，這是一個課程，課程結束我就不會去煩他了。
- 適當的外部鏈接，我也不知道有多少人會去點擊看。
- 去github上fork、star、clone學生的項目代碼，review他們的代碼，例如：編碼規范、模塊划分、單元測試、功能等，能跑的就跑起來體驗。這些都會用在點評和評分上。
- 以上的目標都是為了促進學生能迭代，培養他們對迭代的感覺，如果有效迭代就會看到迭代的力量，進而能自我迭代，達到自舉學習的目標。
- 和老師協商好deadline和要求后，就一定要嚴格執行，沒有嚴格執行就像你的單元測試程序放水一樣，最終會導致整個項目的質量出問題，bug難尋。那么當然有些人會錯過1，2次作業，怎么辦？靠做額外的作業彌補！所以邏輯就是：一次作業發布的規則和deadline就要嚴格執行，錯過了靠增加新的作業和練習補救。既能保證教學項目的迭代，又能增加學生的練習次數。
最后，是評分。這個點上，我基本能做到按時評分，我覺的評分算是教學項目里的單元測試，及時Test，出分，每個角色：教師、學生、助教、其他人，都能看到一個環節的質量和進度，這算是一個教學本身的scrum沖刺。我在這個過程中，認識到無論是學生的SE學習，還是教學本身，保持節奏是一件重要的事情：在一個milestone里，保持連續、均勻、細節到位的迭代。這點也是我希望所有的SE學生們都能意識到（通過已經過去的實踐項目），並且在以后的職業生涯中（無論你干什么）去再次體會，實踐的事情。另外一點是，我認為在每個milestone，都應該對時間是敏感的，充分意識到時間只會越來越少，所以能打提前量的就打提前量，不必每個milestone都到最后才去沖刺，如果不是課堂項目，你提前完成一個milestone，實際上可以利用多余的時間，立刻投入到下一個milestone的前置工作。
評分的內容上（參考：http://www.cnblogs.com/math/p/5066939.html）：
- 迭代完善給出動態的評分機制。畢竟每個老師都不一樣，需要和他們隨時協調。例如alpha和beta，我需要跟張老師協調過程和驗收的比例。例如作業和練習分數的分開。加分的特例等。我采用的是動態的改進評分的表格，並且逐步細化計算的公式。公式展示的是計算的細節，說明我們並不是泛泛給分，而是嚴格考察每個checkitem。不過我也想要是企業里的HR這樣給我們算KPI，我會好煩，太嚴格太細致是令人窒息的，不過這是個人感慨，並不影響我的助教工作。
- 每次給出兩個排行榜：柱狀圖和累積表格。表格的項目，也逐步給出縮寫表頭，我當然喜歡全英文的表頭，以顯“Professional”,不過也會根據情況看是否利於閱讀和排版。這里強調一點就是不給學生的名字，只給學號后3位和博客id，這點我覺的以后的助教都可以參考，反正一錘子解決部分老師對學生隱私的顧慮。然后，堅持表格里有可點擊的超鏈接，當然我覺的理想情況是每個分數項都是對應單篇博客的超鏈接，不過偷懶的話，就只要在博客Id那一列給學生的博客主頁即可。
- alpha和beta階段可以把團隊的具體評分過程也dump出來。alpha和beta的1/3和1/2，3/4的時間點可以私下對那些進度落后的team給個warning，不過我並沒做，主要是自己也忙，而且怕被當作spam。不過評分的時候，可以把過程分的計算給出。這是一個子表，子表的內容也是遵循：累加積分項+映射到單次總分的規則。不多說，用Excel，1/3公式活，1/3編輯體力活，1/3用腳本和工具批處理，我覺的自己以前用Excel並不多，這個過程中反而進一步熟練了。
還有一些其他的細節，也會有利於干活，例如：
- 博客園上我關注班級的老師、學生的所有博客，這樣我只要在博客園個人頁面上的博客那一欄即可看到每天誰更新了博客，保證及時點評。
- 博客園上設置別人的回復信息會提示（我不喜歡它發送的郵件，郵件畢竟會漏看，不如自己主動去刷博客園查看信息提示），這樣能及時收到學生的反饋並進一步跟蹤。
- github上可以適當star學生的項目，利於跟蹤。
- 使用腳本（我用的是LinqPad寫C#腳本，處理日常的統計，批量處理Word、Excel等，我以前買過它的代碼自動完成，.NET又是全功能類庫，方便），我覺的每個程序員都應該掌握1個自己熟練的腳本語言，正則表達式，做日常批處理。
大概這樣，我覺的這些工作，除去點評部分需要經驗的地方，也許並不需要多么資深的業界工程師才能做到，如果助教(無論是校內還是校外)能把這些嚴格做到位，可以完成同樣質量。即使是經驗的部分，我之前也並未有系統的SE學習，反而是在構建之法的SE助教過程中才系統學習，當然如果一個SE班級在基本點上都沒問題，那么會進入進一步比拼SE的知識點上，如果SE的基本知識點上又都沒問題，那么就進入比拼產品了，畢竟產品和用戶才是最終考驗點，從這點來說，我也覺得是需要該課程進一步迭代的地方。我覺的我在基本的要求上做了一些，但是其實如果同樣的過程，換一個學校，一個老師，一些學生，情況又會大不一樣，可能不同情況下所需要的“基本工作”會不一樣。但一旦找到需要的基本點，嚴格執行，應該是一個重要的事情。