关于学校教育, 晓庆说: 不收你们钱就不错了

背景

本学期我们(娴静, 唱鑫, 光磊)在北航开了一门课, 研一, 软件学院, 两学分, 十次课, 每次三小时, 周日下午上, 课程名原来叫 现代软件工程, 后来被学校改为 一级实践, 是在机房上的实践课, 我们主要练习了极限编程中几个跟编程密切相关的实践, 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需要老师投入大量精力, 可能应付不过来, 而做了回顾又不行动, 会是反面教材. 出于私心和对课堂效果的信心, 我们决定放到最后做一次回顾. 不做肯定不好.

但因此拖累了最终的效果. 教训并不新鲜: 如果不能投入, 就不要揽活, 否则不会有让自己满意的结果

• 可按水平混合编组, 相对大一点的组

依然有一半有经验的人, 因此我们依然有可能利用现有的资源取得更好的效果. 只是我们并没有好好利用这些学员. 结对范围太小, 并且相对随机. 而课程内容本是练习软件企业中的开发过程, 那么仿照真实的开发团队来组队练习是一种很自然的选择. 这样有经验的就可以带一下没有经验的

• 可按编程语言分组

我们的授课语言用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?