[2019BUAA软工助教]助教学期总结

[2019BUAA软工助教]助教学期总结

一、量化自评

1. 线上

   • 博客点评：https://www.cnblogs.com/ChildishChange/MyComments.html 共 106 条
   • 博客小结：共 7 篇
   • 发布作业：共 21 份
   • 线上交流：
     • 课程群内发布通知与答疑，约900-1000条消息
     • 组内交流：
       • 提不起劲团队：约150-200条消息
       • hardchoice团队：约250-300条消息

2. 线下

   • 评审：三次，alpha两次，gamma一次，约9小时
   • scrum例会：两次，约2小时

二、反思与回答提问

1. 改变的利与弊

   本学期软件工程课程做出的改变有：

   1. 删去个人项目
   2. 增加一轮迭代
   3. 从课程体系的角度，本学期软件工程升级为必修课程，学院共提供了（AI，嵌入式，敏捷）三个方向，我所助教的敏捷软件工程属于其中的一支。

   删去个人项目，精简课程的训练内容和结构，尽快进入团队项目。由于学生在软工课程之前已经接受了大量来自OO课程的训练，这一修改符合北航学生自身情况，同时也是适应北航计算机系课程体系做出的一个合理改变。

   但是增加一轮迭代的做法，有利有弊：

   • 利：在以往两轮迭代时，beta阶段往往靠近学期期末，其余课程大作业/考试等内容均集中在这一段时间内，同学在beta阶段的投入一般小于alpha。而修改为三轮迭代后，同学可以在 alpha、beta阶段完成团队开发的大部分内容，最终成品均较往届更为完善。
   • 弊：当课程进入到gamma阶段后，大作业/考试的问题依然存在，在gamma阶段进行大量的编码工作难度较大，所以gamma阶段做什么，是首要问题。同时由于增加了一轮团队开发，本学期整体工作量较往届均有一定提升，而学分没有对应提升，工作量与学分不对等的矛盾加剧。同时，由于本学期软工升级为必修且增设了两个方向，敏捷软工与另外两个方向相比，训练量更大，评价体系更严格，因此还存在训练量/学分/成绩相对另外课程不对等的矛盾。

   综上，下学期仍然不使用个人项目，但团队迭代如何进行，需要与罗老师进一步讨论。

2. 助教团队的若干问题

   助教团队的问题，主要在我。

   由于软件工程课程之前为选修+小班的模式，因此不需要大量助教的投入，同时也缺少一套针对软件工程课程的助教团队协作的方针。而本学期第一次投入 8 名助教，助教之间缺少明确的职责与分工，8位同学没有作为一个团队活动，这一点问题相当明显，而且这一点责任在我。

   本学期助教的主要的分工：

   1. 点评/评分：我制定评分规则，使用石墨在线表格将点评任务分配到助教个人，通知点评截止日期，并定期查看助教是否完成点评任务。
   2. 团队互动：将11个团队分配给8名助教，其中我，xdt，lc每人负责两个团队，其余助教一人负责一个团队，由我定期提醒助教进行团队例行交流。
   3. 作业：结对作业主要由lc设计，测试工作由xdt进行，其余作业由我发布。

   具体的问题有：

   1. 除我以外的其他助教存在感低
   2. 助教干预团队项目较晚
   3. 助教之间缺少交流

   其中第3点是本学期助教团队最严重的问题，由于缺少交流，信息不流通，导致助教对除自己负责团队以外的其他团队进度了解较少，同时对各自负责的团队进行的干预/指导也跟仅与助教个人相关，没有起到团队集思广益的作用；另外也没有形成规律有体系的交流环节，导致助教合作松散。

   如何打造紧密的软工助教团队，是北航软件工程课程改进的另一个重点，好在这一点可以向其他诸多课程取经。

   另一点是，相比其他课程，软件工程课程难以培养高阶助教：课程时间安排在大三下，当新筛选的助教进行助教工作时，已是大四下，可投入的时间较少，同时，结束当年的助教工作后，除非新助教仍然在北航攻读研究生，否则很难有机会长期从事在校的主力助教工作。对此我想出的办法是：新助教在大四上自愿地担任其他学校的远程助教，积累助教经验，在大四下继续进行北航本校的助教工作，这样可以确保助教们在大四下投入本校的助教工作前积累了一定的助教经验，但助教需要投入的时间又成倍增加。这是目前软工助教培养工作的一个难点。

   https://www.cnblogs.com/HansBug/p/11102715.html

3. 课程周期短，相关内容体现不足

   这部分的内容，我觉得我暂时没有一个好的想法，我只能提一些自己不成熟的看法，希望可以抛砖引玉。

   由于软件工程是一个体系较复杂，综合性较高，且定位为收口的一门课程，想解决这个问题，我们可以借鉴课程中提到的 MVP 原则，仅在课程中保留软件工程最核心的内容，或是课程最能体现的内容（需要慎重考虑）做展开，将其他内容“外包”给其他课程，进一步提高课程之间的联系。

   以“周期短”、“走过场”为例，我们可以提高项目“传承”的比例，减少自选项目的选择，将“传承”项目真正做活；以“与用户的深入互动”为例，在项目真正做活后，这一问题也许能得到极大的改善。

   但有一点我认为，校内课程的定位是模拟实战，想要做到真实实战的效果有其困难所在，我们首先应当考虑的是如何通过有限的模拟，提高同学对软工环节、方法论、工具的认知，而不是让同学在一学期的学习中只是走个过场，然后再考虑如何提高模拟的真实程度。
   关于这一点我暂时还不能给出一些具体的解决方案。

4. 相关指导偏向于抽象

   关于这一点，我认为，首先是助教和老师需要尽早介入团队，对团队环节提供具体的指导。
   另外，本学期有一部分同学认为，老师上课时ppt的内容与书本几乎一致，所以我认为，可以在课前布置相关阅读与思考内容，在课堂上进行环节的演练，当堂的展示与指导。

   以团队贡献分分配为例，可在课堂、课前进行阅读、讨论，在课堂上公布本组的分配原则，并回答老师和其他同学的提问。

   这一点可以参考研究生的软件工程实验：研究生课程课堂主要以学生分组报告上一周工作内容和老师同学提问为主，老师能在课堂上指出学生实践的问题，而组与组之间又能相互学习各自的做法，能较好地解决这一问题。而本科敏捷软工课程，本质上就是一门实验课程，完全可以通过充分翻转课堂的形式，将课堂作为线下实践的验收与指导。

5. 助教与学生之间直接互动偏少

   这部分内容我在上文提到了一些，在这里做一些总结：
   尽早介入团队提供具体的指导
   加强助教之间、助教与老师的交流，形成有规律的交流、汇报环节
   通过助教向同学传递课程的学科定位，课程群设置的原因，帮助同学构建对学科的认知