「作業回饋機制」的設計理論,是幫助學習者釐清目前自身的學習狀況,找出盲點,或發現讓自己進步的具體落點。同時,也幫助回饋者能發揮自身專業,給予明確的、有建設性的回饋,協助他人成長。
以下是 AC 的回饋機制設計原則:
- 作業批改標準
公開、透明
,學生知道自己的作業是如何被審查,也能夠主動攻略審查標準。 - 明確區分「現階段必達成的首要目標」和「有餘力時的行動方向」,幫助學習者聚焦適合自己的攻略目標
- 引導學習者的焦點放在
Meet Expectations
與 持續行動
- 明確區分各級評分 (指 Try Harder / Meet Expectations / Exceed Expectations) 的意義,讓
評分和行動建議意義一致
- AC 制定明確的驗收標準,讓助教回饋有一致的標準,但同時也保留助教依個人經驗發揮的空間
- 引導助教觀察學生作業中的具體事實,並在回饋時分享自己的觀察
最後,為了讓助教社群內部的批改經驗有系統地傳承,並推動本機制的進化,我們決定將批改標準開源到 GitHub 上。若有任何意見,歡迎發出 issue 或 pull request 給予意見。
同學在寫作業前、助教在批改作業前,請務必詳讀以下說明。
設計理念
機制說明
三種結果
作業批改素材
助教的作業批改流程
學生的寫作業流程
小結
一份作業,經過批改,可能得到三種結果:
結果 | 說明 |
---|---|
Meet Expectations | 助教判斷同學已掌握本階段的學習成果,可繼續前往下階段的學習。 |
Try Harder | 助教判斷同學需要停下來釐清問題,修正之後再繼續前進。 |
Exceed Expectations | 代表作業品質在某些地方特別用心、展示了很好的技術內涵或優化創意,值得做為同儕觀摩的榜樣。若同學收到此評價,建議可在作業頁面或註解裡,和同儕分享更多你的思路,幫助其他人成長。 |
包括:
- 作業規格
- 驗收標準
驗收 【產品功能與規格】 時,批改標準是「缺一不可」。規格有缺漏的產品不代表完成。請助教/同學優先留意,若有缺漏就會得到 Try Harder
。
確認規格達成後,第二步助教會按 【驗收標準】 中提示的重點來驗收作業內涵,也可以說是驗收學生的學習成果。每份作業性質不同,會有不同的驗收重點,並非每作業都會列出所有的重點。
此時助教的回饋大致會有兩種方向:
- 目前觀察到做得不錯的地方,鼓勵學生繼續保持好習慣
- 目前觀察到有需要改進的地方,建議學生之後要多注意
若助教驗收時判斷有重大問題,需要提醒學生立即修正,則會給出Try Harder
,否則即為 Meet Expectations
;或者,當學生的作業品質大幅超越期待,值得推薦給其他同學觀摩、傚法時,助教則會給出 Exceed Expectations
。
以下是作業批改流程說明,無論你是學生或助教,都請詳細閱讀,了解回饋的意義:
- 打開 GitHub 上的詳細批改標準
- 檢查【產品/程式規格與功能】有無滿足?→ 若有缺漏,給出
Try Harder
- 根據【驗收重點】列表來驗收作業細節中,評估學生表現是否達到現階段的期待水平
- 有哪些地方達到期待?→
回饋學生時,請盡量告訴他,你透過哪些細節,觀察出他確實達到期待,鼓勵保持好習慣
- 有哪些地方未達到期待?→
回饋學生時,請盡量告訴他,你透過哪些細節,觀察出他確實沒有達到期待,還有進步空間、建議繼續加油
- 有哪些地方達到期待?→
- 特殊情況:
- 若有「重大錯誤」或是「非常不應該發生的問題」→ 給出
Try Harder
,提醒同學要停下來調整 - 感受到非常令人驚歎的品質、超越期待的水準,值得推薦給其他同學傚法、觀摩 → 給出
Exceed Expectations
- 若有「重大錯誤」或是「非常不應該發生的問題」→ 給出
- 若無發生特殊情況 → 給出
Meet Expectations
,代表助教認同學生已完成現階段的必要學習,可以繼續往前進
最後,讓我們用 AC 學生的角度,說明理想中的、與作業批改標準互動的方式。
- 詳讀題幹說明 & 產品功能與規格
- 設定目標 & 刻意練習重點:根據你自身的狀況,你會為自己訂下什麼樣的目標?你打算投入多少時間心力?
- 寫作業
- 看似告一段落後,拿出規格 & 驗收標準來評估:
- 規格是否都達成了? → 若有缺漏,一定要優先補上
- 驗收重點是否都滿足了? → 當然以盡量滿足為目標,但如果需要再投入很多時間心力,則要再評估一下、量力而為
- 若上述兩項達成後,行有餘力,可以進一步思考如何提升品質、優化產品
- 或者,就提交作業,往下回合邁進吧!
以上,是 AC 回饋機制的說明。衷心期待此機制能讓學習者保持進步、讓回饋者助人成長。若有任何意見,歡迎透過 issue 或 pull requests 功能給予意見。