软工课程改进建议
建议汇总
本篇博客以同学们的视角来看软工课程，希望得到有价值的建议，推动课程的改进
以下的建议汇总于2018软件工程1班 个人总结 和 2018软件工程2班 个人总结
大家的建议高度相似，概括为以下几点：
- 对于课程没有充足的准备，希望在课程开始或者更早能了解课程具体情况，包括整个课程模块的设置、具体的实践模式、需要准备的技术等
- 关于课程情况我们在本学期开始就不厌其烦地讲了很多遍，无数次地强调前方高能，栋哥开了动员会，亓老师也在蓝墨云发布了课程介绍和要求。大概率是同学们对于传统实践课程还存在刻板印象，这点在短期内无法彻底解决，需要通过教学改革才能消除，而且在这个过程中必须不断创新，不进则退
- 另外一个比较深刻的感受就是：我们总是主观地认为，不懂就讲细些，但实际的情况是讲的越细好像越容易让同学们产生依赖，这个度需要把握
- 任务节奏不够紧凑，前松后紧，后期时间与考试和实践课冲突，导致冲刺效益不够高
- 在课程节奏的把握上我们助教团队确实做得不够好，整个节奏和每次作业的分数占比都是从特定的某次作业切入进行考虑，忽视了从整个软工课程的角度看待某次作业，造成了节奏不够紧凑
- 建议下一届助教团队在一开始就对于整个课程节奏和每次任务有一个规划
- 希望增加作业完成的时间
- 驳回，不会因为时间的增加而使用任务更好地完成，相反deadline才是第一生产力
- 辨别团队摸鱼成员，在分数上进行体现
- 这点确实不好把控，现行的分数制度是依靠团队贡献度折算，可能碍于情面，贡献度无法真实体现组内情况
- 另一角度思考，可以采用栋哥提供的建议：小组答辩组内随机抽人上台演讲，这样也能有效抑制一部分摸鱼情况
- 作业要求不够明确
- 纵观这学期的作业要求，确实动不动就是几k的字数，使得大家不容易抓住重点，希望下届助教团队可以简化作业要求
- 对于团队项目选题定太大的悔恨
- 这点看似和我们助教团队没有关系，但是仔细分析会发现这一定程度反映了我们在选题答辩时错误地引导了大家的问题，我们的“灵魂拷问”慢慢地都变成了为了灵魂而灵魂，同学们的回答也慢慢变成为了回答而回答。渐渐忘记了提出这些问题的初衷是为了尽早帮助同学们发现问题，而不是让同学们在一些不切实际的需求上越走越远
- 希望下届助教可以引导大家往小而美的方向发展，避免在基础不扎实的情况下各种高级概念满天飞
- 增加对于作业（代码）讲解
- 驳回，明明每一次的作业都有相应讲解和复盘
- 对于部分同学需要额外提升的诉求，确实应该考虑进每次的作业里
- 减少团队人数，缩减到5人左右
- 值得考虑，这需要平衡团队效益和助教作业批改压力
其他建议
除了同学们的这些建议，还有联想到了一些其他的建议供参考
- 一部分同学提及团队不够熟悉，技术不够熟悉的问题，加之下学期课时缩减，能否通过在课程前期就布置团队展示，让大家提前做好团队和知识的准备（觉得对部分小组可能有正向作用）
- 课程开始之前就打预防针，让同学们提早学习，准备相关技术，接触了相关技术，就不至于把选题定的过高
- 在看总结的时候看到一个朋友写的总结，有些许扎心，这总结体现了一个不安的事实，我们没有很好地把Git的理念传递给每个同学，本学期教授Git的重点依然是在基础操作上，Git的项目使用场景只进行了基本介绍，可能给大家一种只见树木，不见森林的感觉
这个gitee并不是每个人都觉得好用，我个人并不是很喜欢用这东西不要因为作业而强制使用。自己想用的另说
- 邹老师提到的关于团队项目的建议：
可以多个团队做同样的项目，然后大家比拼，beta 阶段再换人，继续改进，也还是一种可以考虑的方法
- 记得布置“事后诸葛亮会议作业”，可以参考：Alpha冲刺之事后诸葛亮 和 现代软件工程讲义 11 项目管理 - 事后诸葛亮会议
助教工作总是在不断的探索和改进中完善起来，对于下一届的助教团队来说也是这样，所以任重道远，要加油！
