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

一、表

二、图

三、总结

1.反思：

1.点评博客没有分清主次，在个人项目后，仍然在进行第一次阅读作业的点评，没有把重心放在个人项目的测试上。
2.结对项目的测试与总结拖延了较长时间。
3.团队alpha阶段结束后，对软件工程教学的参与度大大降低，缺少与同学们的沟通，对情况缺少了解，没有做到善始善终。

2.量化自评：

线上

• 根据博客园博客的“我的评论”页面，从我进入助教群到本学期结课，一共有19页评论，每页有20条评论，共点评370条。其中点评本校学生博客共320条。其中开学前第零次/第一次作业与个人项目、结对作业平均评论字数较多。团队项目平均字数较少。分析了一下原因，是开学前一个月布置的作业有充足的引用来源与可点评点，而团队项目时期的团队博客普遍为scrum meetting博客。另一方面的原因是进入到下半学期之后时间逐渐不足。
• 另外共撰写了17篇课程博客。

线下

• 本学期的交流活动、alpha展示与beta展示时都到场，另外参与了学期初的第一堂课。
• 个人项目采用了自动测试，由于使用了刘乾学长提供的测试程序，大大简化了测试流程。我在学长的测试程序的基础上进行了一些修改以适应我们的作业要求。另外由于给同学提供了一次改错机会，这里需要对同学重复提交的程序进行测试，结束测试后，统计测试结果并撰写小结博客。
• 结对项目的自动测试完成了新的测试程序，测试所花的时间大大降低。但是试玩15个数独游戏并撰写点评花的时间比较多。
• 与罗老师关于课程安排讨论过数次（多少次不记得了）。
• alpha阶段时，参加了每个团队的一次scrum meeting。

跟前辈刘乾学长进行了一下对比，发现我花在与同学们交流的时间上较少，更多花在了博客园上。下次则应该在交流上多注意。

3.选课的同学们：

这个学期选了这门课的都是大佬，剩下的30个更加是大佬中的大佬：

• 个人项目里，超过半数的同学完美地达成了苛刻的运行速度要求
• 结对项目中，15组同学各有特色的数独游戏让我玩得眼花缭乱（是真的眼花了。。对着九宫格看了一天）
• 团队阶段时，出色的团队合作催生出了优秀的成果

更不用提博客中出现的种种闪光的思想。

• 刘畅、索一奇，本学期最优秀的两位PM，平稳地带领团队走完了两个循环，一个工作细致认真，一个分配任务清晰合理，尽管并不总是一帆风顺，但团队最后仍然很好地解决了出现的问题；游心，beta阶段临危受命成为PM团队的PM（[捂脸]），整个团队最终力挽alpha阶段的劣势，大大提高了团队软件工程的质量。
• 窦鑫泽，在alpha阶段离开了hotcode5团队，加入了NewTeam团队，他在两个团队中都承担了十分重要的工作，并出色完成了任务，在alpha阶段临近结束的时候，我问了他关于转会的一些问题，可以看出，他这学期的收获可以说是相当丰富了。

提问

1.你们小组是怎么决定转会人员的
2.你怎么看待转会环节,哪里好哪里不好,或者有什么要吐槽的
3.新的小组跟之前的小组比哪里好哪里不好
4.你在新的小组里有什么收获
5.对转会环节有什么建议

回答

1.小组决定转会人员的方式：PM询问了无转会团队需要满足什么条件，觉得目前的团队情况不能达到无转会的要求后，综合考量各成员的表现（能力，平时贡献等）决定出一位转会成员
2.我觉得转会环节对于团队和转会人员来说是利大于弊的。团队方面，在实际的商业开发里，团队一定会面临着人员流失或新增成员的问题，转会环节也模拟了这个问题，软工团队要根据转会情况做出相应的应对举措。但减少一个人或者增加一个新人都难免会降低团队工作的效率。转会个人方面，两个小组的团队氛围是不一样的，如果是两个项目不同的小组，转会会学到更多的东西（之前的小组是做网站，而现在的小组是在做安卓App）。但是目前为止我有差不多一半的时间都在熟悉开发工具和环境，刚刚弄清楚网站的搭建过程和前端框架Vue的使用，转会以后又要在电脑装安卓的虚拟机，从头开始学习react-native的使用。过程很痛苦，但是因为有转会后小组成员的提前踩坑，所以react-native的学习走了不少捷径，什么事情都是有两面性的吧。
3.新的小组开发效率更高，任务分配的更加详细，团队氛围也不错，感觉开发工作比之前的小组要清闲，但大部分功能已经在α阶段实现了，进入到β阶段更多的工作是一些细小的功能和界面的美化。
4.在新的小组里的收获主要是技术上的，安卓编程，安卓虚拟机的使用，react-native框架以及相应的组件的使用。
5.我觉得转会环节应该更公开一些。比如在转会的时候，每个组可以发一篇博客来介绍目前的团队工作进展情况，希望新人有什么技能以及新人来了以后会干什么样工作。对于转会的人员，团队也应该发一篇博客，说明自己团队转会的是谁以及为什么转会他。

• 刘子渊，群内最活跃的提问者，提出了许多有参考价值的建议、在个人项目中提供了一份有质量的测试用例。同时，他也是与我交流的同学中最主动的一个。我们关于“如何在教学群内，向课程要求提问”进行了一些讨论，最终得出的结论是：
  • 提出问题时要有理有据
  • 对待有理有据的问题，教学团队需要纳入参考并进行改进
  • 对待提问较多的学生，教学团队需要多一些耐心
  • 提问时可以使用“我应该怎么做”，而不是“我为什么要这样做”，这样说能将意思表达清楚，同时减少误会

嗯，就是这样。。

• 辛德泰，本学期最高分获得者。由于他不是PM，所以跟他的接触比较少（[捂脸]暴露我出另一个问题，需要跟所有同学都进行一定的交流，而不是集中在PM上），但是他的每次作业都可以用“令人眼前一亮”来形容。例如代码复审作业，其他同学的完成效果都差不多，他的作业则在细节上取胜。范老师在刘乾学长的助教小结下评论说：

  看了你的总结，我想起到：“the evil is in the detail”这句话，也就是俗称的：”细节是魔鬼“
  然后去查了下，原话是：“ the devil is in the detail"
  根据维基百科的说法，这句话又是"God is in the detail"的变体，但是维基里没说这两句话具体所指是什么，
  进一步查阅，在english.stackexchange上得到一个比较好的版本：
  根据stackexchange上的帖子，这两句话的内涵如下：
  The details of a matter are its most problematic aspect.
  The idiom the devil is in the details means that mistakes are usually made in the small details of a project. Usually it is a caution to pay attention to avoid failure.
  An older, and slightly more common, phrase God is in the detail means that attention paid to small things has big rewards, or that details are important.
  The devil version of the idiom is a variation on the God phrase, though the exact origin of both is uncertain.

希望辛德泰能继续做“The God/Devil that focus on detail”:D

四、希望同学们在剩下的大学时光里一帆风顺，有所作为:D