现实世界是最好的老师, 我们这些叫 “老师” 的人, 充其量是个助教。 但是有些助教却不让学生见到老师。
****************
老师都想把课教好, 学生都想把课学好. 但是我们常常看到一个学期过后, 老师, 学生都有很多抱怨 (例如: 各种良好愿望和计划在实施中的问题). 看了上面的例子, 我脑海中浮现这样的图画:
游泳教练认为经过各项基本训练, 学员在第三年的时候, 应该达到了能组队游泳渡江的能力, 于是教练幻想这样的画面:
期望学生们综合运用平时训练获得的能力, 组成团队, 互相帮助, 自主学习, 集体渡江成功, 老师和TA 只用在小船上实施必要的救助即可.
但是良好的愿望碰到了尴尬的现实，这是老师在操作系统课上发现的现实:
特别能抄袭。被确认抄袭的人次历史之最，是往届数倍
特别能放弃。抄袭无门后，就大片地放弃作业，人数也是历史之最，往届数倍
特别少交流。网上论坛里的讨论，无论数量还是质量都是史上最低
特别能应试。虽然发帖少，但询问评分细节的帖子却是史上最多
特别缺惊艳。即便是独立完成作业且拿满分的同学，其中也难以见到往届哪种处处惊艳的效果，很多人都只是应付，看不到任何激情。
我不知道在大江大河中游泳, “抄袭, 应试” 是怎么实现的, 所以无法类比。 放弃倒是很好类比, 很多 “游泳健儿”到了江边, 找各种借口 - 不游了!
大学生都有一定的阅历和自学能力, 他们通常能很容易地掌握下图中第一步到第四步。 但是社会要求往往是第五步 - “精通”。 这第四步到第五步之间有一个很大的鸿沟。 要跨过这个沟, 学生要学一些比较乏味而且貌似不太相干的内容, 例如马的骨骼结构, 若干原理, 若干基础实践课程如素描等等。 老师怎么创造一种学习/实践/反馈的环境, 让学生能通过各种手段跨过这个沟。 (参考 卓越大学教师的建议).
在我教的课中, 绝大部分学生都下河里真正地游了好几次, 还完成了一次团体横渡江河的挑战。 他们感觉很累, 但是也很有收获, 算是体会到了实际做软件是怎么回事。 下面是我教 <现代软件工程> 的一些心得:
和领导沟通: 获得各位领导的支持 - 您想培训什么样的学生, 是世界一流, 还是中国一流, 还是本省二流? 有什么样的期望, 就有什么样的课程设计。 我上课的学校中, 它们都把自己定位为世界一流, 或中国一流, 那我就要用世界一流和中国一流的标准来要求同学们, 否则我就是不称职的。 要和本课的 TA 就怎么教好课程达成一致意见。 (我知道很多系领导会说无资金支持 TA, 我认为这是无能的借口 - 非不能也, 是不为也)。明确告诉利益相关者, 这门课实际负担是多少, 估计有多少人会不及格。
和同学沟通: 开门见山, 在第一堂课上花时间讲述 老师期望的师生关系是什么 [是运动员和教练的关系] , 这堂课如何打分 [1/n 的给分体系, 迟交作业 0 分, 不叫作业倒扣分]， 最终分数的分布概况 (20% 优秀, 10% 不及格或刚及格, 其余在二者之间线性分布) (链接) 想学习的学生知道如何努力, 想混的学生也知道怎么才能混过去, 想退课的也可以马上退掉。
简明公开的规则: TA 在每一次作业之后, 都公布所有同学 (只显示学号后几位) 目前的得分, 以及推算出来的最终分数。 根据分数的分布情况, TA 通常把 10% 的同学划到不及格这一栏中。 简化TA 的工作, 晚交作业一律 0 分, 不必说情。
循序渐进: 了解学生的能力, 不出意外的话, 你会发现学生的动手能力很差!
学生之间从来没有正经合作过! 你想让他们马上搞一个团队有各种角色, 完成一个实际的项目是不可能的! 怎么办? 我这门课设计了三种项目:个人项目 (让每个人练练自己的手艺, 同时实践项目管理的工具和操作 check-in, check-out, 简单的测试用例设计)
两人项目 (两个人合作完成一个比较难的作业, 锻炼交流能力, 合作能力。 同时练习软件工程中的 “结对编程”, 接口设计, 代码复审, 简单的界面设计, 同时让学生有机会学到不同语言, 不同的框架设计, 不同的表现层的实现 – WPF, Flash, Silverlight 等 ) 这类项目可以安排两次, 每次换人做。
团队项目 (真正的考验, 但是有了前面的准备和锻炼, 他们已经可以到河里游泳了)
让学生有更多的控制, 激发他们的自我管理意识。 在这三种项目中, 学生对项目的控制越来越多, 要相信学生想做好, 能够做好:
个人项目: 学生可以选择编程语言, 其它由老师指定。
两人项目: 学生可以选择语言, 界面,
团队项目: 学生可以选择做什么, 各人的角色, 如何实现, 如何推广。
给学生控制和希望: 有些学生某个项目搞砸了, 怎么办? 没问题，课程中有一定的分数是各人自由发挥的能挣到的, 例如主动为大家服务写测试工具, 写更多的读书报告, 等等, 都能挣到分数。
学生怎么学习? 不能光干活不反思。 同学们要不断总结 – alpha, beta 阶段都要做正式的 回顾和总结, 并发布博客。 要求学生自己先看教材, 然后发博客提问题, 都是成年人了, 应该能提出一些问题来; 课程结束的时候看看自己最初提出的问题, 估计自己都可以回答了 - 这不就是上课的作用么?
有人打酱油怎么办? 团队项目有分数, 团队中每个人都得一样的分数, 打酱油的成员也得同样多的分数, 怎么办? 给每个团队一定的自由分配的分数, 让每个团队决定如何分配这些分数 (分数不能平均分配, 幸苦工作的人可以得高分, 决定打酱油, 不在乎分数的人可以得低分)。 每个人的付出和结果能更好地结合起来。 这也是给团队非常实际地体验了社会上如何做绩效评估, 团队管理, 如何衡量 “我在团队中的地位”, “我在别人心目中的分量”。
用客观数据来评分: 老师太忙, 不能仔细地批阅每一次作业, 怎么办? 把学生的作业做成比赛, 比程序速度, 比测试用例的数量, 比博客的阅读量… 相对的分数自然就出来了。 团队项目一定要做解决实际问题, 能公开发布和使用的项目, 这样有很多用户给学生们评分。 例如一组同学的魔方程序有3 万多下载; 同一个班级的另一组同学的软件有 10 个下载, 谁好谁坏, 不用老师去查阅代码了。
模拟实战: 据我了解, 大部分软工的”项目”是同学们从头写的 1.0版本, 但是IT 行业的绝大部分软件是有很长历史的系统, 不接触老系统, 如何学到软工的各种原理和实践? 只要肯想办法, 总是有很多途径可以模拟实战的:
把历届学生的项目都用版本控制软件管起来, 这样后来的学生可以在前人的基础上继续开发。
鼓励同学在别人的基础上开发 (开源, 以前的项目, 等等)
在项目的alpha 和 beta 阶段之间, 让部分同学跳槽, 从一个小组换到另一个小组中, 这样同学们就有很多机会亲身体会到 文档的重要性, 如何理解老代码, 等等软件工程的好玩的事。
Deadline - 学生生活是什么驱动的? 是对老师规定的服从, 还是对技术的热情, 还是为中华民族第N次伟大复兴? 还是deadline? 大部分人的作业都是要等到交作业的前一天夜里搞出来的。 在软件工程课上, 一个晚上是搞不出来可以使用的团队项目的, 为此课程设置了很多检查点:
每个阶段的结束都要求公开发布博客
要求项目有两个公开发布 (alpha, beta)
要求每个阶段要有 10 天的 SCRUM 会议, 并把每次会议结果 (每个成员昨天做了什么，今天打算做什么, 碰到什么障碍) 列出来, 并用软件工程的工具自动生成进度表。 进度表的例子:
没有这些检查点, 同学们会在最后演示的时候告诉你 - 我们尽力了, 搞了三天, 这次给我们及格吧, 我们以后一定会继续改进的！然后他们再也没有消息了。
不要盲目追求新: 1999年, 有人问软件工程专家 David Parnas: 将来会有什么令人兴奋的软件工程技术出现? 答: 最有用的技术不在将来,
而是已经在我们中间好些年了, 只不过我们没好好用。软件工程课要把那些久经考验的原则和技术交给学生, 而不能停留在浮光掠影地介绍当前最热门的做法。 老师要展现给学生的是, 软件工程的原则，技术仍然能解决前软件开发的各种挑战 - 老师自己有这个信心和经验么?
附: 教学计划 (http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html)
教学计划总长: 16 周 (扣除放假之后)
授课: 12 - 14 次 老师授课
辅导课: 6 - 8 次 (辅导/交流/演示) 学生主动汇报进展, 心得, 提出问题, 老师及专业人士给予辅导。
学生项目: 个人项目, 结对编程项目 (两个), 团队项目
| Week | Date | Lecture (授课) | Talk (辅导/交流/演示) | Project |
| 1 | 11/1 | Intro (课程简介, 分组) I-project 个人项目介绍 | i-project (个人项目) | |
| 2 | 11/8 | Software Engineering (软件工程概论),Unit Test (单元测试) | ||
| 3 | 11/15 | Personal Software Process (个人软件流程 PSP), Code Quality (代码质量的各种标准) | SilverLight | pair project (1) 结对项目 (1) |
| 4 | 11/22 | collaboration (两人合作), influence (影响说服别人的多种方式) | P1 review | |
| 5 | 11/29 | Team-CMMI (团队结构, 文化, 成熟度模型 CMMI)Development Process (软件开发的各种模式) | pair project (2) 结对项目 2 | |
| 6 | 12/6 | Innovation (软件业的创新)Myths of Innovation (创新的迷思),Innovator's dilemma (创新者的两难) | P2 review | |
| 7 | 12/13 | NABC (项目可行性分析)Spec and PM(软件规格说明书, 项目经理) | Book Report | Team Project Kick Off 团队项目开始 |
| 8 | 12/20 | Testing(测试) | Milestone 1 (里程碑 1) | |
| 9 | 12/27 | Proj. Mgmt w/ TFS (用TFS 进行项目管理) | daily scrum | |
| 10 | 1/3 | Scenarios (基于场景的设计) | daily scrum | |
| 11 | 1/10 | Release (软件的发布) | alpha release | |
| 12 | 1/17 | MSF (微软软件解决方案框架) | Review | Review/BugBash |
| 13 | 1/24 | Dev-History (微软软件开发管理的历史) | feedback | Milestone 2 (里程碑2) |
| n/a | 1/31 | Holiday | Holiday | |
| n/a | 2/7 | Holiday | Holiday | |
| 14 | 2/14 | Risk Mgmt (软件项目的风险管理) | Book Report | daily scrum |
| 15 | 2/21 | daily scrum | ||
| 16 | 2/28 | UI/UX report | beta release | |
| n/a | 3/7 | Postmortem (软件项目的回顾与反思) | ||
| 17 | 3/14 | Final Review (最终汇报, 复审) |
