现代软件工程 教课心得

现实世界是最好的老师, 我们这些叫 “老师” 的人, 充其量是个助教。 但是有些助教却不让学生见到老师。

****************

老师都想把课教好, 学生都想把课学好. 但是我们常常看到一个学期过后, 老师, 学生都有很多抱怨 (例如:  各种良好愿望和计划在实施中的问题).  看了上面的例子, 我脑海中浮现这样的图画:

游泳教练认为经过各项基本训练,  学员在第三年的时候, 应该达到了能组队游泳渡江的能力, 于是教练幻想这样的画面:

 

期望学生们综合运用平时训练获得的能力, 组成团队, 互相帮助, 自主学习, 集体渡江成功, 老师和TA 只用在小船上实施必要的救助即可.

 

但是良好的愿望碰到了尴尬的现实，这是老师在操作系统课上发现的现实:

1. 特别能抄袭。被确认抄袭的人次历史之最，是往届数倍
2. 特别能放弃。抄袭无门后，就大片地放弃作业，人数也是历史之最，往届数倍
3. 特别少交流。网上论坛里的讨论，无论数量还是质量都是史上最低
4. 特别能应试。虽然发帖少，但询问评分细节的帖子却是史上最多
5. 特别缺惊艳。即便是独立完成作业且拿满分的同学，其中也难以见到往届哪种处处惊艳的效果，很多人都只是应付，看不到任何激情。

我不知道在大江大河中游泳, “抄袭, 应试” 是怎么实现的, 所以无法类比。 放弃倒是很好类比,  很多 “游泳健儿”到了江边, 找各种借口 - 不游了!

大学生都有一定的阅历和自学能力, 他们通常能很容易地掌握下图中第一步到第四步。  但是社会要求往往是第五步 - “精通”。 这第四步到第五步之间有一个很大的鸿沟。  要跨过这个沟, 学生要学一些比较乏味而且貌似不太相干的内容,  例如马的骨骼结构,  若干原理, 若干基础实践课程如素描等等。 老师怎么创造一种学习/实践/反馈的环境, 让学生能通过各种手段跨过这个沟。 (参考 卓越大学教师的建议).

在我教的课中, 绝大部分学生都下河里真正地游了好几次,  还完成了一次团体横渡江河的挑战。  他们感觉很累, 但是也很有收获, 算是体会到了实际做软件是怎么回事。  下面是我教 <现代软件工程> 的一些心得:

1. 和领导沟通: 获得各位领导的支持 - 您想培训什么样的学生, 是世界一流, 还是中国一流, 还是本省二流?  有什么样的期望, 就有什么样的课程设计。  我上课的学校中, 它们都把自己定位为世界一流, 或中国一流, 那我就要用世界一流和中国一流的标准来要求同学们, 否则我就是不称职的。    要和本课的 TA  就怎么教好课程达成一致意见。  (我知道很多系领导会说无资金支持 TA,  我认为这是无能的借口 - 非不能也, 是不为也)。明确告诉利益相关者, 这门课实际负担是多少, 估计有多少人会不及格。
2. 和同学沟通: 开门见山, 在第一堂课上花时间讲述 老师期望的师生关系是什么 [是运动员和教练的关系] ,  这堂课如何打分 [1/n 的给分体系, 迟交作业 0 分, 不叫作业倒扣分]， 最终分数的分布概况  (20% 优秀,  10% 不及格或刚及格,  其余在二者之间线性分布)  (链接)  想学习的学生知道如何努力, 想混的学生也知道怎么才能混过去, 想退课的也可以马上退掉。
3. 简明公开的规则: TA 在每一次作业之后, 都公布所有同学 (只显示学号后几位) 目前的得分, 以及推算出来的最终分数。 根据分数的分布情况,  TA 通常把 10% 的同学划到不及格这一栏中。 简化TA 的工作, 晚交作业一律 0 分, 不必说情。 
4. 循序渐进: 了解学生的能力,  不出意外的话, 你会发现学生的动手能力很差!    学生之间从来没有正经合作过!   你想让他们马上搞一个团队有各种角色, 完成一个实际的项目是不可能的!  怎么办? 我这门课设计了三种项目:
   1. 个人项目  (让每个人练练自己的手艺, 同时实践项目管理的工具和操作 check-in, check-out, 简单的测试用例设计)
   2. 两人项目  (两个人合作完成一个比较难的作业, 锻炼交流能力, 合作能力。 同时练习软件工程中的 “结对编程”, 接口设计, 代码复审, 简单的界面设计, 同时让学生有机会学到不同语言, 不同的框架设计, 不同的表现层的实现 – WPF, Flash, Silverlight 等 )  这类项目可以安排两次, 每次换人做。
   3. 团队项目 (真正的考验, 但是有了前面的准备和锻炼, 他们已经可以到河里游泳了)
5. 让学生有更多的控制, 激发他们的自我管理意识。 在这三种项目中, 学生对项目的控制越来越多, 要相信学生想做好, 能够做好:
   1. 个人项目: 学生可以选择编程语言, 其它由老师指定。
   2. 两人项目: 学生可以选择语言, 界面,
   3. 团队项目: 学生可以选择做什么, 各人的角色, 如何实现, 如何推广。
6. 如何处理学生讨价还价？ 很多学生给老师说：我基础差，软件工程课能不能高抬贵手，意思意思就行了，不要写那么复杂的软件。 回答：这就是本校本专业的底线。  给学生控制和希望:  有些学生某个项目搞砸了, 怎么办? 有的学生代码经验特别少，怎么办？　没问题，课程中有一定的分数是各人自由发挥的能挣到的,  例如主动为大家服务写测试工具, 写更多的读书报告, 写深入的分析报告，等等, 都能挣到分数 -- 软件工程不光是写代码。另外，要让学生小组之间互相评比，这样就把矛盾从“老师 -- 学生” 之间不断讨价还价，变成 “学生 - 学生” 互相比拼。
7. 怎么教，怎么学? 老师不能陷入传统的 “老师 - 学生” 模式出不来，在这个模式下， 老师不断地 "敲黑板" - 同学们，敏捷的12原则要记住啊，期末要考！ 但是学生未必领情，敲碎黑板又如何？   老师可以引入别的模式， 例如组织结对编程来促进 【学生 - 学生】的互动和学习， 通过团队项目，团队贡献分来促进 【学生 - 团队】的学习； 通过团队评比来促进 【团队-团队】的学习； 通过公开的博客和公开的软件管理和发布来促进 【团队 - 社会】的互动。   学生不能光干活不思考， 同学们要不断总结 – alpha, beta 阶段都要做正式的 回顾和总结, 并发布博客。 要求学生自己先看教材, 然后发博客提问题, 都是成年人了, 应该能提出一些问题来; 课程结束的时候看看自己最初提出的问题, 估计自己都可以回答了 - 这不就是上课的作用么? 学生团队要互相评比，评比的时候不要打分（A组 90 分，B组 89 分...) 因为这样分数会太接近。 要采取无并列排名次的方法， 每个小组给别的小组排名次，同时写140 以上的点评（优点，缺点，闪光点），排名次之后，可以看到大家公认的优秀小组得分会远远超过那些无所作为的小组。
8. 有人打酱油怎么办? 团队项目有分数, 团队中每个人都得一样的分数, 打酱油的成员也得同样多的分数, 怎么办? 给每个团队一定的自由分配的分数, 让每个团队决定如何分配这些分数 (分数不能平均分配, 幸苦工作的人可以得高分, 决定打酱油, 不在乎分数的人可以得低分)。 每个人的付出和结果能更好地结合起来。 在一个阶段结束后，每个团队必须有至少一个成员离开，自己寻找新的团队。 这也是给团队非常实际地体验了社会上如何做绩效评估, 团队管理, 如何衡量 “我在团队中的地位”, “我在别人心目中的分量”， "我的竞争力"。
9. 用客观数据来评分: 老师太忙, 不能仔细地批阅每一次作业, 怎么办?   把学生的作业做成比赛, 比程序速度, 比测试用例的数量, 比博客的阅读量… 相对的分数自然就出来了。 团队项目一定要做解决实际问题, 能公开发布和使用的项目, 这样有很多用户给学生们评分。  例如一组同学的魔方程序有3 万多下载; 同一个班级的另一组同学的软件有 10 个下载, 谁好谁坏？
10. 模拟实战: 据我了解, 大部分软工的”项目”是同学们从头写的 1.0版本, 但是IT 行业的绝大部分软件是有很长历史的系统, 不接触老系统,  如何学到软工的各种原理和实践?   只要肯想办法, 总是有很多途径可以模拟实战的:

1. 把历届学生的项目都用版本控制软件管起来, 这样后来的学生可以在前人的基础上继续开发。
2. 鼓励同学在别人的基础上开发 (开源, 以前的项目, 等等)
3. 在项目的alpha 和 beta 阶段之间, 让部分同学跳槽, 从一个小组换到另一个小组中,  这样同学们就有很多机会亲身体会到 文档的重要性, 如何理解老代码, 等等软件工程的好玩的事。

Deadline - 学生生活是什么驱动的? 是对老师规定的服从, 还是对技术的热情, 还是为中华民族第N次伟大复兴? 还是deadline?  大部分人的作业都是要等到交作业的前一天夜里搞出来的。 在软件工程课上, 一个晚上是搞不出来可以使用的团队项目的, 为此课程设置了很多检查点:

 

1. 每个阶段的结束都要求公开发布博客
2. 要求项目有两个公开发布 (alpha,  beta)
3. 要求每个阶段要有 10 天的 SCRUM 会议, 并把每次会议结果 (每个成员昨天做了什么，今天打算做什么, 碰到什么障碍) 列出来, 并用软件工程的工具自动生成进度表。 进度表的例子:

没有这些检查点, 同学们会在最后演示的时候告诉你 - 我们尽力了, 搞了三天,  这次给我们及格吧, 我们以后一定会继续改进的！然后他们再也没有消息了。  

不要盲目追求新:  1999年, 有人问软件工程专家 David Parnas: 将来会有什么令人兴奋的软件工程技术出现? 答: 最有用的技术不在将来,
而是已经在我们中间好些年了, 只不过我们没好好用。软件工程课要把那些久经考验的原则和技术交给学生, 而不能停留在浮光掠影地介绍当前最热门的做法。 老师要展现给学生的是, 软件工程的原则，技术仍然能解决前软件开发的各种挑战 - 老师自己有这个信心和经验么?

 

附: 教学计划  (http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html)

北航的软件工程教学计划：

　　http://www.cnblogs.com/SivilTaram/p/5656582.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	NABCD (项目可行性分析)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 (最终汇报, 复审)