软件工程课是计算机科学与技术系核心课程之一，是软件工程方向学生的重要专业课，对学生形成正确的软件开发理念有举足轻重的作用。如何能在有限的课时里，让学生对这门包含众多内容的课程有系统了解，并培养一定的实践能力，难度较大。尽管我有多年实际开发软件项目的经验，所做过的项目各式各样，直接讲案例学生听起来新鲜，但因为学生几乎没有项目开发的经验，未必能领会其中的妙处，还需要对案例选择整理，转化成学生容易听懂、易于接受的形式，这些都给课程的讲授带来很多挑战。现将我在讲授这门课的过程中的一些做法和体会归纳总结一下。
软件工程不是纯理论课，是实践性较强的课。没有公式，没有定理，只有方法，只有“最佳实践”。学生在别的课程里，习惯了学公式和定理，但软件工程课给出的方法，丝毫没办法在理论层面证明，只能在实践中不断应用和练习，才能理解并体验到它们的好处，死记硬背不起任何作用。面对在软件开发方面经验近乎空白的大学生，把这些经验性的方法直接讲给他们听，无法说服大家。课堂上太多的“经验”，会让这门课变成一门枯燥沉闷的纯理论课。本来学生对纯理论课就提不起兴趣，老师再照本宣科，他们自然就选择坐在课堂里玩手机或是睡觉。
我曾看到过微软邹欣老师的博客，以及他所著的《构建之法》，阅读这些内容，对我启发非常大。《构建之法》中，邹欣老师通过丰富生动的故事和隐喻帮助学生建立软件工程的思维习惯，同时，要求学生以实际软件产业内的软件开发团队配合和管理方式开展自己的软件项目，要开发真实的软件，并且在互联网上发布，要走出去找到真实的“用户”，要倾听用户的真反馈，引导学生在“做中学”（leanringbydoing），而不是“学后做”（doingafterlearning），靠自己“做”的过程中的经验和教训总结真正属于自己的 “最佳实践”。在这些启发下，本学期我们进行了大刀阔斧的改革，强调实践，强调学生在“做中学”，明显改善了教学效果。
我编过很多年软件，也做过大大小小很多软件项目的负责人，本以为对软件工程过程比较熟悉，讲课是很容易的事，实际教学后发现并非如此。开发软件面对的是机器，不太需要说话；讲课面对的是学生，全靠语言表达。编软件目标是可靠好用，教学更多的是吸引调动学生，教会学生。在几年的教学过程中发现的突出问题是，软件工程作为计算机专业课，除了包括像数据库、程序设计等专业内容外，还有很多设计原理、项目经验的内容，概念性比较强，不那么有趣。学生听枯燥的条条框框多了就容易犯困。
本学期我改变了授课内容的次序，从学生们最感兴趣的写代码入手，逐步引导他们思考对代码书写规范的思考、对代码性能分析与优化的习惯培养；再逐步扩大软件的规模与复杂度，引入软件架构的思想，让学生持续书写代码和学习新的开发技术；刻意强调真实用户的重要性，引导真实用户为学生们提出各式各样需求的变更，再辅之以考核时间上的压力，让他们自然接受结对编程、快速迭代、持续集成等敏捷开发的思想；当学生们发现靠自己掌握的现有技术实在无法“敏捷”起来的时候，再引导他们考虑设计思维，考虑需求，考虑是否该引入这样那样的建模。这样一步步下来，下一阶段要学习和训练的知识与技术，恰恰就是学生们在上一阶段里所遇到的无法解决的难题，于是自然而然勾起了他们继续往下走的兴趣。我们把将近30%的课堂时间用于课堂讨论，而不再是传统的“老师讲、学生听”。
学生过去为完成课上布置的实践软件项目，需要学习很多新知识，像编程语言、开发环境等，所需学习时间较长，学得差不多的时候，将近半学期过去了，用来编程的时间就不多了，不利于激发学生软件开发的热情，培养开发能力。
针对这种情况，在前几年上课时，我就有意识地选出优秀学生，在下一年指导学弟学妹，把开发思路、工具方法等介绍给他们，减少初期入门花费的时间。这样一届一届地下来，学习效果一直有所改善，上届学生的经验得到一定程度的继承，这种做法得到了学生的支持。为培养学生项目管理的能力，课上学生被分成了4-6人的小组，每组选出一名组长担任项目负责人，项目的分工、计划、过程管理都由组长来安排，并要求学期结束前每组集体在课堂上演示运行本组的软件成果。助教定期召集组长开会，检查项目进展情况，组长再检查落实每位成员任务完成的情况。这样的组织结构和未来实际工作的场景比较相似，大家共同努力完成同一个目标，有助于学生培养团队协作的能力，积累开发经验。从目前的情况来看，各组都能按进度完成预定的目标，收到了预期的效果。
（供稿：高等教育研究与评估中心）