關於學校教育, 曉慶說: 不收你們錢就不錯了

背景

本學期我們(嫻靜, 唱鑫, 光磊)在北航開了一門課, 研一, 軟體學院, 兩學分, 十次課, 每次三小時, 周日下午上, 課程名原來叫 現代軟體工程, 後來被學校改為 一級實踐, 是在機房上的實踐課, 我們主要練習了極限編程中幾個跟編程密切相關的實踐, TDD, 重構, 結對, 簡單設計, 持續整合等.

我們打算講一下我們碰到的問題. 這不同於做開發項目. 我們可能是軟體開發的熟手, 但學校教育, 100人的課堂, 完全是不同的問題域. 以至於有人問是不是billable, 我們說沒多少錢的時候, 曉慶說: "不收你們錢就不錯了". 誠哉斯言.

下面講一下我們對問題的理解, 對應的方案, 和經驗教訓. 我們有意識的盡量不提我們的課程內容, 因為具體的課程內容是與我們將要談論的問題域沒有關係的. 換句話說, 如果我們教授的不是軟體開發而是財務或者證券投資, 只要學生數量同樣很多, 差距同樣很大, 我們依然會遇到並要解決這些問題.

問題

比較大的問題有:

• 課堂規模帶來的效果問題: 100人左右的大班, 如何保證學生的聽課效果? 包括老師輔導答疑的針對性
• 水平差異帶來的排課問題: 基本沒有什麼編程經驗的, 佔一半; 3~5年經驗的, 佔百分之二三十. 還有幾個十年左右經驗的. 課程的深淺難易該如何把握?
• 實踐課, 如何考試?
• 如何獲知學生的反饋以便及時調整教課內容?
• 然而對我們來說, 最重要的問題是, 如何保證學生能學到東西?
• 其實還有一個問題, 如何協助學生學會學習. 但這個問題不該是一堂實踐課獨立承擔的. 我們不必妄自尊大大包大攬, 只需儘力對此有所貢獻即可, 比如最簡單的做法就是穿插一些說教

先說最重要的問題.

如何保證學生能學到東西

對問題的理解

學校開這門課的目的, 是希望學生在理論之外, 能接觸和瞭解企業裡現在正在用的開發實踐, 使學校教育不至於太脫節. 然而企業中除了有學校沒有的實踐, 更重要的是, 還有學校裡碰不到的問題. 十次課, 刻意練習某些實踐或許能有小成, 但實踐易老, 問題永生, 在教授實踐的同時, 不妨礙我們扔出企業裡碰到的各種實際問題, 引發學生思考和討論. 這是我們的底線, 總是可以做到的. 有了這個打底, 我們再深化幾個具體的常用的實踐, 當可以保證學生不至於空手而歸.

另外有一些演算法類的知識, 比如git和github, 簡單易學, 沒有副作用, 而且肯定有價值, 這些總是可以順便教和學的.

那怎麼驗證學生學到了呢? 布置並檢查作業, 鼓勵學生分享等. 直接通過做真實的項目來驗證? 這可以是一種選擇, 本學期出於一些原因, 我們沒有這麼做, 後面會提到.

我們的做法

• 分享並練習我們工作中碰到的真正的問題

在練習中碰到的一些知識點, 我們會儘力舉一個實際發生過的例子. 比如版本控制系統, 我們會講有的企業限制開發人員刪除檔案的許可權, 讓大家分析政策的原因, 後果, 以及更好的做法是啥.

另外一個例子是工作中經常人來人往, 那知識如何傳遞? 針對這個問題, 我們會穿插讓學生交換pair來類比這種情境.

• 布置作業並在下節課開始請同學上來示範

這可以確認至少部分同學是做了作業的, 並且可以獲得老師針對性的點評. (後面會講到課堂規模的原因, 不是每個人都會得到老師一對一的點評, 因此上來示範作業是很好的學習機會和對自己掌握程度的檢驗)

• 鼓勵學生回答問題, 分享, 寫部落格, 這是加分項

學生對問題的回答, 和把知識總結分享出來, 都可以證明他學到了. 我們設計了一些環節和機制, 比如課前有一刻鐘的分享時間, 同學可以上來做一個快速的演講; 還有微博交流平台, 同學可以寫部落格, 把連結@給我們. 而為了鼓勵這些行為更多的發生從而讓我們驗證學生的掌握程度, 我們設計了加分項. 前面說的這些, 包括示範作業, 都可以加分, 算在最後的總成績裡.

• 不論客戶在做什麼, 給他一些其它方面的建議

這是溫伯格的諮詢法則之一. 軟體開發是知識工作的典型代表, 涉及技術, 組織, 心理, 社會行為的方方面面. 我們總可以給出與課程內容沒有直接關係, 但依然很有用的建議.

效果以及經驗教訓

• 效果一般.

由於其它的一些原因, 導致我們的驗證機制發揮的作用有限. 比如每次上來示範作業的, 課上積極回答問題的, 總是那麼幾個人. 沒有人@給我們他/她的部落格連結.

雖然驗證機制發揮的作用有限, 那我們有沒有別的辦法確認同學們是否學到東西了呢? 在最後的Retrospective Meeting中, 我們分了四個組, 每個組都有人說沒學到什麼實際的東西, 每個組也都有人說課程內容很實用, 學到不少.

• 經驗

而在Keep Doing一欄中, 很多人都提到了希望老師持續分享真實的項目問題. 這至少說明我們唯一的優勢確實發揮了優勢.

很多人多次提到, 我們講過的對知識的三個層次的劃分(Mystery, Heuristic, Algorithm), 對他們很有啟發. 溫伯格的諮詢法則也再次發揮了作用.

• 教訓

我們工作經驗的優勢和溫伯格諮詢法則協助了我們, 而我們設計的驗證機制則沒有. 目前的驗證機制只是挑出了那些好學的學生, 而好學的學生是本就不需要擔心的. 那如何讓不那麼好學的學生也能有所收穫呢? 在這一點上, 在本學期, 我們是失敗的. 這是個開放問題, 我們後面會有所涉及, 也想聽聽大家的意見.

總結一下就是, 部分人從這門課學到了東西, 部分人沒有. 而根據我們的資料, 這個結果跟學生的軟體開發經驗的多少, 和我們的課程設計, 直接相關. 下面是第二個問題, 課程設計

水平差異對課程設計和課堂教學的挑戰

對問題的理解

課程設計應當遵循幾個原則:

• 儘可能因材施教. 因此需要瞭解學生目前的軟體開發水平
• 應該留有根據反饋進行調整的空間. 不必完全按照學期開始前制定的教學大綱進行

我們的做法

• 第一節課問卷調查

我們設計了調查問卷, 問題涉及學生的編程年限, 熟悉的語言, 版本控制系統, 開發實踐等. 最終的結果是前面提到的, 基本沒有什麼編程經驗的, 佔一半; 3~5年經驗的, 佔百分之二三十. 還有幾個十年左右經驗的. 水平比我們預計的要低不少. 我們在授課風格上, 做了不同於給企業進行培訓的改變. 如下所述

• Teach By Example

給企業進行培訓我們基本用的是對比式, 即讓學員先按他們自己原來的方式做練習, 犯各種錯誤, 我們給予點評, 然後show一下更好的做法, impress他們一下. 放到這課堂上行不通了, 學生們根本就沒有"原來的方式", 讓他們自己做, 什麼都做不出來. 我們從第二節課開始調整了教課風格, 先帶著學生做第一個練習, 有了example之後, 學生結對把剩下的做完. 對, 結對

• 組隊學習

為讓沒什麼基礎的學生不至於太過艱難, 我們讓學生結對來完成練習. 最終的考試也是按pair算成績. (當然另一個原因是結對本就是我們的課程內容之一)

• 儘可能用最簡單的語言特性

語言不是重點, 重點是軟體開發中的各種思想. 講課中不涉及任何複雜的領域知識. (實際上這有點一廂情願. 一半的學生連編程都不會還談啥思想)

• 課程進行一段時間後, 做一次對後續課程內容期望的調查

我們的課程分成三部分, 在第二部分時, 我們對學員有了更多的瞭解, 覺得他們未必喜歡或者覺得我們原先安排的第三部分的內容有用, 我們便做了一個調查, 給了學生們更多的選擇.

效果

效果一般. 有工作經驗的人覺得很實用, 而初學者一頭霧水. 我們分析了一下, 有兩個主要原因

• 老師的投入程度. 開課前我們得知是實踐課, 很高興, 因為我們的業餘時間有限, 有兩個人即將當爸爸, 到時肯定很忙, 而我們手頭有各種現成的實踐課的課程教程, 且嫻靜剛從TWU授完課回來, 總之無需花太多時間準備. 而在第一節課的調查問卷結果出來後, 面對一半學生基本沒什麼經驗的情況, 我們沒有做出太多調整, 依然使用的是針對企業內訓的課程, 僅僅在風格上把以練為主改成以教為主. 這造成了對於有工作經驗的人覺得很實用, 而初學者一頭霧水.
• 學校的課程順序. 實踐課依賴一些基礎知識, 而教授這些基礎知識的課程居然也在本學期同時進行, 比如Java語言, 居然還是選修課. 如果我們的課程安排到下學期會好一點. 這已經與學校主管老師溝通, 希望在下一年調整課程順序

經驗教訓

• 需要投入

如前所述. 雖然我們每周都會花時間來討論下一節課的要點, 業餘也會把代碼和ppt寫好, 也要花費周末的時間去上課, 但並沒有認真的去設計針對學生使用者的課程, 導致效果不是很好

• 只在課程結束時做了一次回顧, 時間有點晚

我們總共11次課分了三部分, 本可以在每部分結束時做一次回顧, 但由於幾個原因, 我們選擇了放到最後再做. 一是在我們根據觀察主動做出一些調整後, 每節課都能看到課堂的進步, 比如回答問題的多了, 上來示範的代碼的品質也逐漸提高, 並且在我們宣布從第五節課進入考試模式後, 上座率也維持在高位, 覺得效果還可以. 二是前面提到的投入問題, 眾口難調, 如果回顧會議形成一些action需要老師投入大量精力, 可能應付不過來, 而做了回顧又不行動, 會是反面教材. 出於私心和對課堂效果的信心, 我們決定放到最後做一次回顧. 不做肯定不好.

但因此拖累了最終的效果. 教訓並不新鮮: 如果不能投入, 就不要攬活, 否則不會有讓自己滿意的結果

• 可按水平混合編組, 相對大一點的組

依然有一半有經驗的人, 因此我們依然有可能利用現有的資源取得更好的效果. 只是我們並沒有好好利用這些學員. 結對範圍太小, 並且相對隨機. 而課程內容本是練習軟體企業中的開發過程, 那麼仿照真實的Team Dev來組隊練習是一種很自然的選擇. 這樣有經驗的就可以帶一下沒有經驗的

• 可按程式設計語言分組

我們的授課語言用Java, 但Java不是重點. 實際上我們不限制學生用其它語言來做練習和考試, 但我們沒有跟學生說清楚這一點, 也沒有為其準備開發環境. 機房的環境每次都會被恢複成原始鏡像, 而我們讓機房老師只是幫我們把Java的環境做到了鏡像裡. 在回顧會議中, 學生提出按語言分組會順利的多. 明年如果還有機會, 我們應該試一下.

• 做個相對更完整的項目

基於前面分組的假設, 我們可以整合資源做個相對完整的項目. 本學期的練習比較零散. 這還是跟對課程設計的投入不足有關.

後來唱鑫無意中從網上發現了鄒欣(就職微軟, 具有多年在學校教授軟體工程的經驗, 本學期也在北航開課, 課程名稱正是現代軟體工程. 他的微博@程式員鄒欣)老師的教學大綱, 分組做項目也是被採用的授課方式.

第三個問題是100人左右的大班, 如何保證學生的聽課效果?

課堂規模帶來的效果問題

對問題的理解

教室很大, 但硬體設施足以保證每個學生都看的清楚和聽的清楚. 短缺的是老師資源. 平均每個學生只能分到百分之三個老師. 如何有針對性的答疑, 如何充分的利用各種機會跟學生溝通, 是我們開始認為比較重要的問題

我們的做法

• 一個老師主講, 另外兩人輔導

每節課我們都有一個主講的老師. 當他/她在教室前面講課時, 其他兩人要在教室中來回走動, 就近回答學生的問題. 當開始做練習時, 三位老師都在教室中走動答疑

• 擴大答疑的影響範圍

當學生問了有代表性的問題時, 請他用麥克風給全班複述一遍, 然後老師也面向全班來答疑

• 建立微博交流平台

每節課的三個小時是有限的. 課後學生當然可以留下來問問題. 而更靈活的方式是線上交流. 我們建立了課程的微博帳號: @1級實踐_北航. 課件我們會放在對應的微盤裡. 學生有問題可以@我們. 我們也會推送一些參考資料, 像Tech Radar, 甚至公司裡的活動, 比如OpenParty, BQConf, TechLady等.

效果

尚可. 回顧會議中沒有出現諸如有問題得不到及時回應之類的less well. 而當課堂上學生對老師的講解不是很理解時, 他們也會對我們說不懂我們為什麼要那麼做, 我們講解的時候就會多用幾種方式把事情說清楚

而微博平台發揮的作用不大. 交流基本單向, 我們上傳課件, 學生下載. 當然原因不在微博本身.

經驗教訓

• 可嘗試分組

與前面沒有利用學生裡面比較senior的人來協助彌補水平差異一樣, 我們也沒有利用他們幫我們傳遞知識. 如果分組, 則每個人的問題會首先經過小組, 小組覺得沒答案, 才會上升到老師這兒. 而老師也不需要看100個人50對pair, 只需照顧不超過10個小組.

第四個問題是如何考試.

實踐課, 如何考試

對問題的理解

因為是必修課有學分, 所以無論如何我們都要給學生一個成績. 有幾種方式是行不通的:

• 試卷. 我們都不知道有什麼題目能反映出學生的實踐水平
• 一份原始碼的snapshot. 首先你無法確定代碼來源, 但更重要的是我們不認為對實踐的踐行和理解與原始碼的品質有簡單的因果關係. 原始碼的品質受多種因素的影響. 學生的基礎差別也比較大.

有幾個原則我們認為是合適的:

• 學生的課堂參與, 在課堂上的實踐和練習, 應該被考慮在最後的成績中
• 必須有實際的編程任務被考慮在最後的成績中, 但要避免只看最後的結果
• 可以有些開放式的題目, 比如針對軟體開發中的某個問題, 學生談談自己的看法, 類似論文
• 避免到課程最後再考試, 要持續考試

我們的做法

綜合上面的幾點原則, 我們在課程初期確定了考試方式和內容.

• 學生的課堂實踐做為加分項

回答問題, 示範代碼, 示範作業, 分享心得等, 每次5分, 10分封頂. 這是加分項, 其它還有總分100分的考試. 學生如果這10分到手, 其它成績只要超過50分, 就能及格

• 把課堂上沒做完的需求變化做為考試題

一個小項目, 課堂上做為教課內容, 我們會帶著學生一起做一部分, 而最後會留兩個新的需求變化做為考試題目, 佔80分

• Github的提交曆史考慮在內

為避免抄襲, 我們會考慮github的提交曆史. 如果考試代碼只有一次提交, 或者幾個人的repository的曆史大量重合, 則影響成績

• 留一道開放式的問題作為論文題目, 佔20分

這個由於最後課程沒能達到理想的效果, 取消了

• 學期開始就公布考試方法, 提前四周公布最後的考試題目

效果

等著同事們一起幫忙做code review呢, 按pair提交, 五六十份代碼!

經驗教訓

• 持續考試. Continuous Examination

課堂參與度一直不算高, 學生主動的問題也不多. 可是自從我們提前四周公布考試題目後, 學生突然對題目很關心, 都紛紛來澄清需求, 甚至來問一些比較深入的問題, 像控制台列印輸出的測試如何自動化等. 這給了我們很大啟發. 雖然之前我們也知道每學一點就應該validate一點, 但都是通過作業的形式進行的. 不做作業也沒任何措施. 學生並沒有表現出對作業的興趣. 而對考試題目卻真正關心起來. 這跟諮詢和做項目是一樣的, 要搞清楚stakeholder的利益所在…

所以可以考慮的一種做法是每節課都有一個成績. 比如10節課, 每節課10分. 學生會被迫從一開始就關心每一節課的內容

• 分組做項目, 按組算成績

我們採取的考試方法太關注細節了. 看鄒欣老師的課程設計, 最後的學生作品要求是真實的產品, 發布到公開的市場, 有真正的外部使用者. 給學生一學期(三個月左右)的時間做一個有用但無需太多功能的項目是合適的. 10節課, 磨合一個團隊也說的過去, 因此最後的成績也可以按團隊來給.

Tips匯總

• 投入
• 利用學生自身的力量
• 持續反饋
• 持續驗證
• 理解stakeholder利益所在
• 不論課程內容是啥, 教點別的

到最後發現居然跟在公司帶團隊做項目很像, eh? 不同的問題域, 解決方案的原則是一致的, eh?