关于大学中开展软件类讨论组一些想法

这个事情最早是我们团队的马博士提出来的，大意是希望团队中软件方向的学生能有一个交流的机会，相互学习，相互带动。

后来陈博士表示支持，这个事情就开始准备，我本人也希望团队中的成员能营造起这样一种学术的氛围，前面也努力过，有些教训和想法，贴出来，大家多提意见。

其实学生报告的方式我也尝试过，应该是陈博士在教育部学位中心的那段时间，当时带着软件方向的研究生和本科导师制的学生一起做过这种尝试，当时是每个学生报一个题目，每周一次，报告完大家讨论，我感觉效果不好，学生基本上是念ppt，后来也稍微改进了一下，每个人设计一个实验，大家跟着做一下，最终结果基础好的学生讲的内容太难，基础不好的学生讲的内容太容易，没有营造起整体学习的那种氛围。

 

教训：软件方向的所有学生都听一个内容，这种一刀切的方式不现实，原因很简单：学生基础差别大，没有共同语言，不论谁主讲都是一种“摧残”。

 

我的想法是：编程不是先学后做的，而是在做中学的。

 

我的建议是：任务驱动——老师推，学生做。老师把握方向，学生为主完成。

把学生分成几个组，每个组技术好和技术差的平衡一下，老师把目前咱们团队的做完的或者没有做完的项目，进行分解任务，根据任务去讨论和学习。每个老师带1-2个组，小讨论以组为单位，时间不固定，大讨论所有同学参与，每周或每两周组织一次，各组汇报自己的进展，讲解关键技术，营造一个竞争的氛围。

 

我给这种方式起了个名字：计划统筹下的市场经济体制。上层老师抓，就行计划经济一样，把时间资源都规划好，起好推动和监督作用；下层充分发挥学生的主观能动性，自主学习，自主讨论，关键问题老师参与决策。

 

举个例子：

最近半年带了几个网络和计算机的本科生，大家就做一个项目（手机基站定位，程序分三块，一块是android手机端，一块是socket端接收手机端数据，一块是web端调用百度地图展示位置），大家总能找到自己感兴趣的领域，我根据学生的兴趣，分了两组，手机端和服务器端，技术好的学生负责一些关键技术和整体架构，技术不好的同学先负责查资料，写些测试类的程序（基本上都是网上能找到的，现成的程序改一下就行的），每天都有汇报（程序提交svn，检查），每周都要看进度，到现在为止，效果还可以，基本上能完成一个项目，有些地方实现的比我自己实现的还要好，学生整体能力也能提高。

 

个人想法，仅供参考。