【2017上半年集美大学1412软工实践_助教博客】助教总结
开学初对自己的期望
翻看之前自己本学期开学初写的日志，当时写下的三个小目标是：
因此担任助教本学期的目标有三个：
- 提高评分速度
每次作业的deadline三天之内就将每个同学的成绩公布出来 - 提高博客点评质量
参照飞龙博士的点评方式，联系构建之法的书本内容，在博文点评中争取能够提出具有深度的问题，加深同学对书本和实践的理解 - 消灭0点评博文
多利用碎片时间，每晚11点前check 一下消灭当天的零点评博文，为博客园的班级博客打开零点评博文功能点个赞
目标1完成的很不好，因为评分速度的问题，本学期没少被邹老师和周老师批评，目标2完成的只能算是个及格分，评论的深度和邹老师、飞龙博士相比还是有很大的差距。目标3打个70分，尤其是alpha和beta阶段，基本都能每天消除0点评，但是在其他作业中还是有0点评的博客遗漏。
班级情况
本学期助教博客
【2017集美大学1412软工实践_助教博客】个人作业1——四则运算题目生成程序 成绩公示（2017-03-13 02:07）
【2017集美大学1412软工实践_助教博客】结对编程项目1——四则运算 成绩公示
【2017集美大学1412软工实践_助教博客】个人作业2——必应词典测评 成绩公示
【2017集美大学1412软工实践_助教博客】结对编程2——单元测试 成绩公示
【2017集美大学1412软工实践_助教博客】团队作业1 成绩公示
【2017集美大学1412软工实践_助教博客】团队作业2 成绩公示
[【2017集美大学1412软工实践_助教博客】团队作业3——需求改进&系统设计 成绩公示[(http://www.cnblogs.com/deerCode/p/6804845.html)
【2017集美大学1412软工实践_助教博客】团队作业4——第一次项目冲刺（Alpha版本）小组 成绩
【2017集美大学1412软工实践_助教博客】团队作业5——测试与发布（Alpha版本）
【2017集美大学1412软工实践_助教博客】团队作业6——展示博客（Alpha版本）
【2017集美大学1412软工实践_助教博客】个人作业3——个人总结（Alpha阶段）
【2017集美大学1412软工实践_助教博客】团队作业7——Alpha冲刺之事后诸葛亮
【2017集美大学1412软工实践_助教博客】团队作业8——第二次项目冲刺（Beta阶段）
【2017集美大学1412软工实践_助教博客】团队作业9——测试与发布（Beta版本）
【2017集美大学1412软工实践_助教博客】团队作业10——项目复审与事后分析（Beta版本）
每周在助教工作上花费的时间4-6小时不等，和上学期相比，效率基本持平。
不过得益于上学期的在福州大学助教的经验，在记录分数时直接套用上学期留下的表格，对于excel更为得心应手。
个人总结
一学期下来，评论共计240条，时间花费累计大约60个小时左右。一学期下来，收获也挺多
1. 团队配合
上个学期是和室友一起做助教，有什么问题在一个屋子里就全解决了。这个学期不同的是和郑蕊、西瓜、科桥组队打怪，每个人负责一个班级。大家做事也挺有默契，既能互相促进提意见，有时候也会集体拖延成绩的发布，这个过程没少被邹欣和周老师、飞龙博士在群里催促。知易行难，正如软工实践一样，在实践中才能更好的学会团队配合。郑蕊老师堪称本次助教F4团中的大姐大，大部分的评分标准都是由她制定的，每次作业的评分，她都是第一个完成的。西瓜和科桥做事都很认真，尤其是西瓜童鞋对同学们博客的评价和我比要认真的多，真的完全做到了一个标准好学长的模范角色。
2. 好的方面
本学期的助教工作，相比上个学期更为从容。有上个学期的经验加成，效率提高了些许，这是其一。
其二经常在本班群里转发并AT大家。邹欣老师经常在班级群里分享一些东西，为了提醒大家看到，利用管理员的小特权@所有人
其三成绩更新速度相比上个学期提高很多。上个学期在福州大学助教工作中，甚至因为个人原因有两周没发布成绩的情况出现，这学期由于助教团队的互相监督，有极大的改善。
3. 需要改进的地方
A. 和同学们的互动需要加强
和西瓜相比，和同学们的互动就少的多。一方面对同学们的直接指导不够，只是停留在了博客层面。另一方面，博客的评论回复算不上特别及时，提高博客评论的回复频次，这是下一步需要提高的地方。
B. 成绩纰漏情况
用同学反映成绩表格中学号和超链接不对应，有的同学成绩在改正后在总成绩中没有及时更新。这个属于不仔细。俗话讲，慢工出细活。在评分时，应先把excel升级成2013以上的版本，这样超链接才能随着表格排序一起变化。此外，在评分整理表格不应太过急躁，确保正确的前提下完善数据的整理更新，尽可能的减少纰漏。
C. 时间节点观念
譬如本学期开始的助教目标1，作业deadline结束3天之内完成成绩的更新，这学期尽管有进步，但是满足这个时间点的次数寥寥。成绩的评定速度还需要进一步提高。
同学们对课程的建议
1. 你认为每次项目的评分标准存在哪些问题，你认为的合理评分准则是怎样的（个人／结对／团队算三个）
同学一
个人：个人的评分感觉很合理，也很细致，助教也做出了相应的点评，每个人做的成功与得到的分数一致。
结对：个人觉得可以像团队编程一样，添加一个贡献分，毕竟两个人的合作，做的量还是会有不同的。
团队：这个时候一个很明显的问题，就是每个班级的助教评分标准有差异，不同班级之间映射的分数相差波动还是有的，这是因为助教的不同导致，还有一个问题是团队复审的问题，有时候评价太过于主观片面，我认为存在不公平因素，导致不平衡。还有一个就是贡献分，感觉贡献分其实并没有发挥什么作用（1-5）的区分，大部分也都是平均分配了。还有！个人认为人员调动真的没什么意义。
同学2
对个人／结对／团队这三个评分标准的整体来说，大体上看是比较完善合理的，不过就我个人看来还是有一些值得商榷的地方。首先我要感谢老师和助教们的辛勤劳动，才有这一学期大家收获满满的一门课。老师和助教都特别认真和辛苦，把要求我们要写出来的点都很明确地列出来了，也根据这些点给出了非常详细的得分点，让同学们在写的时候知道从哪里入手写。不过在一学期的观察和同学们的交流中我发现，助教在给分的时候对每个得分点的质量要求不够，存在只要有体现就得分没体现就不得分这一问题，可能会导致大家为了得分而只是很敷衍、很表面地体现这个点，并不会主动去思考，这就违背了老师布置这些要点的初衷。我觉得在评分过程中不应该只有黑白，应该区分出一些灰色地带。对于每个得分点，没有体现那肯定不得分，而对于其他不同质量的体现，应该根据质量的高低来给出更加详细的分数，不应该要么0分要么1分，助教可以根据这个点的质量给1分、0.9分、0.75分、0.5分、0.1分等等。
举个例子，对于一个2分的得分点，我发现助教评分的时候经常要么给0分，要么就是2分，偶尔会给1分，因此几乎只要有体现每个要点的博客都能得到都能得到差不多的分数。这偶尔会让每次写博客都尽力写到最好的我有点小意见，为什么我写的这么认真可是分数还是跟那些点到为止的博客差不多呢？心里难免有些不舒服，经常想着自己也随便写写，只要体现得分点就好，没必要展开写，反正分数也差不多。虽然每次都这么想，但每次也都是写的特别认真，相信还有一些特别认真的同学跟我有这样的小想法，希望老师可以考虑一下这个问题。（这个只是我个人的感觉，也有可能助教就是这么做的而我自己没有发现，如果是这样的话我真的要向老师和助教好好道歉了，助教要是有什么需要说明的欢迎在评论区交流哦！）
① 对于“个人项目”的评分标准：个人项目的评分是实实在在的，每个人的分数不存在分配的问题，因此我觉得个人项目的评分还是很合理的，我指不出存在哪些问题，在我看来就是perfect！
② 对于“结对项目”的评分标准：在我看来，结对编程评分时两个队友的得分应该有所区分，而且不应该两个人合写一篇博客，应该每个人就自己负责的那部分或者自己编程实现的那部分功能来写自己的博客，然后助教根据各自的博客来打分。因为当结对编程两个人只需要交一篇博客的时候，可能会存在明确分工的问题，可能就会有一个人编程一个人写博客的情况，这明显就违背了结对编程的精神。当自己写自己的博客的时候，也可以一定程度上遏制打酱油现象的发生，就算平常没怎么参与编程，为了写这篇博客也会尽力向同学请教，使自己更熟悉这个项目，这样才写的出来博客。
③ 对于“团队项目”的评分标准：首先，我觉得团队贡献分算法最后得出的团队贡献分不合理。这个算法只成就了团队中贡献分最高的那个组员（一般是主要负责编程的组员），当然他们拿最高的5分我觉得是他们理所应当的，只是其他几个组员的贡献分也太低了。就我个人来说，作为小组的组长以及团队贡献分第二高的组员，平日里也付出了不小的努力，不过最后的分数跟其他大部分的同学一样都是1分，我觉得这个区分度就太小了，在5分之下应该适当地给一些4分、3分或者2分，而不是几乎都是1分。另外，在两个阶段的冲刺中，都有一个得分点是每日进度的功能展示截图，每一天都有2分。我的问题是当某一天只解决了一些微小的问题或者大部分的时间都在探索如何解决问题的过程中的时候，软件的运行过程截不出与上一天有所不同的图片该怎么办?我们小组在Beta阶段中就因为这个原因被扣了好多分数，如果我们用了前一天一样的截图就可以因为有体现这个得分点就不扣分吗？我觉得当我们在博客中说明清楚没有展示运行截图的原因之后，老师可以考虑着适当扣一些分数，而不是全部都扣掉。（这一点因为涉及到我们小组的分数，扣了不少的分，所以可能存在不客观的情况，我只是在此提一下，也希望助教看到可以跟我多交流，帮我解答这个疑惑。）
同学3
个人：个人的评分标准总体上不错，但是我觉得要因人而异，比如有的同学编程基础相对薄弱，那么评分时应该着重在他的进步上，也就是相比上次有进步就给进步分，并且进步 分比重较大，这样有利于鼓励同学们持续不断的进步，并且在进步中体会的编程的快乐，这和孔子的因材施教有异曲同工之妙。合理的评分准则应该是类似“按劳分配”的原则，就是 看你做了多少，并且是否认真在做。基于大量的观察发现：基础差的同学有时候并不是不愿意去学好代码，而是因为刚刚开始入手的时候比较难，这个时候很需要进步分的鼓励才能 更有动力去写代码，并且在学习中进步。
结对：结对的评分标准挺好的，就是有些同学基础比较差，结对的时候做的比较少，但是另一个同学碍于面子就把功劳平分了。这样子对那个脑力劳动更多的同学来说并不公平， 应该有个差异化的分数，比如总分100，可以6，4分贡献分。
团队：一般团队都是有一个核心的，就是队长。团队的评分一般是贡献多的拿多分，其他人分剩下的贡献分。每个团队的实力不一样，应该体现出差异化，并且按照刚刚个人项目 评分标准的提议给每个团队进步分，让同学们更有信心和耐心做好。
2. 你的团队项目是否成功，如果重来一次你是否还会选择这个团队，为什么成功／失败
同学1
我觉得我们团队前期是成功的，后期就有点失败了。前期我们团队的分数一直都是较为高的，到了后面，因为人员的调动问题，我们团队失去了一个主心骨的成员，从此团队的开发过程一直在走下坡路。如果从来如果重新来一次我还会选择这个团队。我们团队的成功在于一个出色的领导人，失败在于失去主心骨后的颓废。
同学2
我觉得我参加的两个项目都是很成功的，参加的这两个项目中我都是作为组长进行统筹分工。如果再让我选择一次，我还是会选择这两个团队，因为我的队友们实在都太给力了，太可爱了！
我在alpha阶段参与的项目是“四则运算自动生成器”，这一阶段我们完成了除登录/注册之外的所有功能，还在不断需求分析、用户反馈的过程中额外完成了一些新功能，最后被老师评为第一阶段的优秀博客。我觉得第一阶段中我们团队成功的关键在于需求分析时切实找到了这个软件的真正用户以及在冲刺的七天中坚持每日的用户短反馈模式。在进行第一次需求分析的时候，我们团队偷懒了，以我们自身的角度脑补了这款“四则运算生成器”应该具备的功能。我们也果然被老师、助教们看出来了，冲刺第一天需求分析的博客被怼的很惨。多亏了老师们及时指出了我们的错误，我们才知耻而后勇，让我们的需求分析真正落地。我们不仅采访了几个小孩在上小学的叔叔阿姨，还找到了一个小学三年级的数学老师，让我们的软件真真正正地面向它的用户群体。不仅如此，我们在alpha的七天冲刺里还坚持每天收集用户的短反馈，我们把每天完善好的软件发给她们使用，根据她们的反馈意见再不断修正。也正因为如此，我们的软件才增加了许多之前我们根本想不到的新功能。
在alpha阶段结束之后，老师要求我们每个组都执行一次换人机制，由于那时我觉得我们组的功能在第一阶段都实现得差不多了，就主动申请换到其他组去继续锻炼自己。第二个团队的项目是“英语词典”，虽然在Beta阶段中的博客得分不是很高，但我还是觉得我们团队是很成功的。我觉得第二阶段中我们团队成功的关键在于分工明确，队员的执行力强。在每次老师布置完任务之后，我们就会一起把老师安排的任务分解，根据每个人的特长分配到个人，每个人都很及时、主动地完成自己的任务，队员之间的默契程度也越来越高。
同学3
我觉得在beta阶段我们团队是成功的，合作的很愉快，如果重新来一次我还会选择这个团队。我们团队的成功主要是由于我们团队的氛围很好，大家一起学习一起进步，分工明确。不懂的问题团队成员之间会互相解答，队员之间都非常乐于助人。
3.总结一下你们团队在做项目时大家的时间安排情况，可以匿名写
同学1
没什么好匿名的吧，说真话的话，也就晚上才有时间做这些事情，早上一个个都在上课，做这个，讲道理是不合实际的，不是说这门课不重要，而是因为我们不能因为这门课放弃其他的东西，我们的实验课是很多的，压力，我们也是有的。
同学2
我们团队在做项目时大家的时间安排比较自由，不同的队员安排的时间都不太一样，不过大部分同学都是利用晚上的时候来完成自己的项目任务。我们团队的工作模式是：在老师布置完作业之后，我会根据老师作业博客里要求体现的那些得分点进行分工，要求他们在截止时间的前一天晚上十一点前把他们各自完成的部分用Word文档的形式发给我，然后我再根据他们的文档进行整合串联，对写的不好的部分进行修改。因此，我们团队每天除了站立会议以及遇到问题大家在讨论组里互相讨论之外，大部分时间大家都是独立完成各自的任务，所以每个成员具体的时间安排我可能不太清楚。不过可以确定的是，由于这个学期课比较多，大家白天的时候一般都在上课，所以几乎都是在晚上完成自己的项目任务，每个人一周差不多安排出一个晚上的时间来就够完成自己的任务了。
同学3
做项目的时候我们都会把大部分时候用来思考如何写出更好的代码，一般是这样安排的：小李一般喜欢晚上的时候去图书馆写代码，并且会带上一两个有空的组员一起，这样可能就是一晚上都把时间花在软件工程上了；小王负责写一个模块的代码，他喜欢一个人，很享受一个人写代码的乐趣，但是我们经常会开小会议讨论组员之间的代码写的怎么样，是否有bug。
4. 软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。请问你们在项目的 需求/设计/实现/测试/发布/维护 阶段（一共6 个阶段）中都学到了什么 “知识点”， 每个阶段只要说明一个知识点就可以。
同学1
①需求阶段：关注用户，而不是关注功能，一款产品的成功是建立在用户良好的使用反馈上的，一意孤行，是不可取的。
②设计阶段：项目正式开始时先进行原型设计，把客户的需求实际地转化成功能来实现。需要考虑各方面的因素。
③实现阶段：实现阶段是整个最核心的阶段，主要是团队之间的代码开发，交流。通过燃尽图等来分析自己团队的进度，收获最多的阶段。
④测试阶段：单元测试。对于自己写好的代码，一定要经过测试才能上传到coding。软件的测试过程中，及时收取bug，用户反馈。
⑤发布阶段：通过各种手段将自己的软件进行发布，发掘更多用户。
⑥维护阶段：定期更新版本，优化系统，修改bug，这样才能保证项目的活化，不会流失用户。
同学2
- 需求阶段：需求分析一定要落到地上，一定要找真正的用户对象，而不能靠自己的“脑补”；需求分析也不是一蹴而就的，应该坚持多次地采访、回访用户；
- 设计阶段：功能设计要从实际出发，设计功能时往往会去百度现有的同类软件具备哪些功能，这一做法不是不可，但是绝对不能因为这个而束缚住自己的想法和思路，要勇于创新、勇于尝试；
- 实现阶段：在实现功能的过程中，要继续保持与需求分析用户的联系，最好要把每天完成的软件都发给用户使用，然后根据用户每天的反馈不断修正功能和增加功能，坚持这样的短反馈，会受益匪浅；
- 测试阶段：测试人员不能只包括团队成员，最好找一些完全不熟悉这个软件的同学来测试，看看程序界面是否友好，操作是否有困难；另外，测试应模拟多种平台、环境以及一些特殊情景，保证软件的兼容性以及在特殊情况下的可用性；
- 发布阶段：软件在发布的时候最好同时附上使用说明书，说明书的内容包括软件具备的所有功能、软件的使用方法以及注意事项等；
- 维护阶段：在维护过程中也应该不断收集用户的反馈，不断完善软件。
同学3
需求阶段：学到了你做的产品是最终是要面向市场的，所以用户很重要，要知道自己的产品的用户是谁，他们有什么样的需求，然后按照需求设计。
设计阶段：顶层设计很重要，做产品前一定要有清晰的思路，先要做好整个架构的设计。
实现阶段：实现代码的时候要谨慎一点。
测试阶段：测试阶段要考虑全面些。
发布阶段：发布产品的时候要让用户知道这个产品的特性，优点，让用户有眼前一亮的感觉。
维护阶段：维护很重要，这是守住用户的关键，好的售后总是更让人喜欢。
5. 自己总结
同学1
以前并没有尝试过这种写代码的方式，第一次意识到，团队间的代码开发，效率相对于个人，竟然会高这么多。相对于传统的教学模式，按部就班，意义确实不大，这种新模式，确实能够极大的锻炼我们的能力，总之，这学期，收获良多。
同学2
开始知道这门课改革的时候其实内心是拒绝的，毕竟上一届是只要期末做个小项目出来就给过了，而我们却要在平常的每周里都付出辛勤的努力。不过大家不也都是一边抱怨这门课多么占用时间、自己多么不想写博客，而又一边按照老师的要求按时提交博客作业吗？现在想起来还是挺感谢这门课的，让大三这一年显得充实了不少，一定程度上也让大家保持着紧密的联系，为班级同学们留下了几十张“并不情愿”的合照。很感谢这一学期以来老师以及助教们的辛勤付出，才让我们这么顺利、这么原汁原味地体验了一把从idea到APP的艰苦历程，真的收获很多，不说技术上增强了多少，至少文字表达在这十几万的博客中提升了不少。
这种教学方式虽然真的很“烦”，但真的很有收获，希望以后的新生能在大一刚刚进来的时候就体验这种教学模式（反正那时候我已经毕业了，让新生接受最残酷的历练吧hhhh），这样他们就能从一开始就养成良好的学习习惯，不像我们这样大一大二松惯了，大三突然紧一下，很多人都会抱怨。最后对考试提一个小想法，建议把最后一题改到第一题，这样大家都会超级认真地写对软件工程这门课的建议，然后原来的1、2、3题改成2、3、4题，这样设计应该会比较合理一点，老师希望得到的信息也会更完整一点
感谢的话
在这里首先感谢周老师和邹老师的孜孜不倦的鼓励支持，在思想上有松懈的时候，总会及时的掏出小皮鞭鞭策一下更好的上路。邹欣老师也用实际行动阐释了一个真正行动者是如何做事情的。为了推进软工实践改革这一件事情，坚持不懈，几年如一日的出现在各个班级同学博客的评论区中，佩服不已。
其次感谢张老师和助教小伙伴，张老师的作业布置的很细致，三个助教小伙伴也让我看到了自己身上还需要提高的地方。
最后感谢同学们一学期以来的陪伴，虽然未曾谋面，但衷心祝愿这次课程经历在成为优秀程序猿/媛的道路上迈出了一大步。
