时间：2017.03.01 - 2017.0620
一、开学初对自己的期望
1. 和老师同学及时有效沟通
2. 保证点评的及时性和高效性
完成情况：
1. 对同学的咨询可以做出百分百及时回复，基本能及时向老师反应同学的问题。
2. 有两次在外地，作业点评完成的不是很好。
二、班级情况
1. 班级博客:软工-网络1413（集美大学）
2. 教师:张敏老师
三、本学期助教博客
1. 班级介绍：
2. 个人作业：
集美大学网络1413第十二次作业成绩（个人作业3） -- Alpha阶段个人总结
3. 结对作业：
4. 团队作业：
集美大学网络1413第七次作业成绩（团队三） --需求改进&系统设计
集美大学网络1413第八次作业（团队四）-- 第一次项目冲刺（Alpha版本）成绩
集美大学网络1413第九次作业成绩（团队五） -- 测试与发布（Alpha版本）
集美大学网络1413第十次作业成绩（团队六） -- 展示博客（Alpha版本）
集美大学网络1413第十一次作业成绩（团队七） -- Alpha冲刺之事后诸葛亮
集美大学网络1413第十三次作业成绩（团队八） -- 第二次项目冲刺（Beta阶段）
集美大学网络1413第十四次作业成绩（团队九） -- 测试与发布&博客展示（Beta版本）
集美大学网络1413第十五次作业成绩（团队十） -- 项目复审与事后分析（Beta版本）
四、个人总结：
1. 评分标准：得益于张敏老师出题的细致和其他三位助教在石墨的评分规则制定还有群里各位老师的建议，在这块节省了自己很多时间，只是偶尔提出了几点意见，享受了团队工作的乐趣：）
2. 博客点评：本学期博客点评累计200条，两次在外地，点评可能不及时，感谢邹老师百忙中帮忙点评，只能尽力消灭了零回复，赞博客园的查看零回复博文功能。
3. 博客评分：除了在外地评分拖后了一小会，其余还是能争取每周发布评分，基本都能得到同学的认可，除了alpha阶段按时发布博客的评分点导致个别组痛失得分来求情（但规则就是规则，大家也都理解了，beta阶段做的好多了）。
4. coding评分：看一份好的代码是一种享受，看不规范的代码真的痛苦，好的消息是本学期大部分代码都可以编译并执行，不好的是代码规范方面有待加强。团队coding时也有借助网上某些功能代码的，希望真的可以自己掌握。
5. 和同学交流：同学们对微信的回复还是很及时的，就是博客上评论的回复后来也是通过分数的督促完成的。
6. 和老师交流：张敏老师已经做的很好了，有时候简单的沟通下出现的同学的建议等。
总的来说，这学期只是本分的完成了自己班级的工作，经常加班回去，或者周六日学车回去，或者从外地回去看到其他三位助教已经制定了详细的评分细则，很是感激。
特别不好的是：
1. 班级男神团队的失败，其实从一开始看出端倪就不应该只是在博客上询问，得到回复的几率微乎其微，应该多私下和他们沟通的。
2. 另一同学因为手术没有在beta阶段任何团队，不该理所当然认为被分配到其他班级团队了，还是负有一定责任的。
五、对同学们的建议
首先，我还是很佩服至始至终坚持下来的同学们，我也经历过大三到大四阶段，不管是考研、保研、出国留学、找工作等，每一项都足以压得人喘不过气来。
1. 团队：-- 以绝大多数人勤奋程度之低，还不足以去拼天赋。
在评分的过程中，其实就可以发现，如果有幸分到一个好团队，水涨船高，大部分情况下该团队的所有同学分数都会比较高；如果不幸分到一个相对差一点的团队，就成了一个和尚挑水吃（个人），两个和尚抬水吃（结对），三个和尚没水吃（团队）。
但是反观人生，每个人出生都掌握着一副被分配到的手牌，不管你拿的是好是坏，总还是要尽力打的精彩。更何况同一所学校，同一个班级，同一门课程，真的达到了需要我们去只拼运气的时候吗。如果真的足够重视，回过头想，在一个很坏的团队里，你为什么不能去做那个稍微努力点的人呢。而且如果工作后，想要进入一个好的团队，不也得需要你自己用能力说服别人吗？
2. 结对：-- 取其精华
本学期只完成了两次结对编程作业，私认为，这是一个很好的学习对方优点的过程，比如对方解决问题的思路等。
3. 个人：-- 蝴蝶效应
当你老了，回顾一生，就会发觉：什么时候出国读书，什么时候决定做第一份职业、何时选定了对象而恋爱、什么时候结婚，其实都是命运的巨变。只是当时站在三岔口，眼见风云千樯，你做出选择的那一日，在日记上，相当沉闷和平凡，当时还以为是生命中普通的一天。
——陶杰《杀鹌鹑的少女》
所以，尽可能不要虚度年华，也不要放弃，种一棵树最好的时间是十年前，和现在！！！
4. 时间：-- 合理利用一切时间碎片
推荐大家去读一下《暗时间》。
珍惜在学校还有人愿意教你，还有你讨论公平与否的平台，还有为你提分的附加作业，但是别人能做到的，请你也尽可能做到。比如展示的博客，比如提升能力的coding。
六、关于课程的一点建议：
这是第三次做助教了，张敏老师制定的教学计划是我见过最为详细的，很负责。
1. 博客：
可以要求一下统一的格式。
2. coding：
建议可以在课程初期增加对git使用的教学，并且有一个简单的项目贯穿始终，让同学基本每周都会有代码的check-in和check-out。而不是像最后团队里代码能力好的个人秀。
3. 评分：有同学建议结对编程过程中也引进互评。至于评分细则方面，认为每一次布置作业的博文中已经很详细的写出了，只要认真看，同学们是不会有遗漏点的。
4. 好多工具都只是走过场，比如leangoo或者PSP，大多数同学还是不能体会到其作用，可能得有一个良好的监督及执行制度。
七、感谢：
感谢邹老师、周老师、张老师给我本次当助教的机会，也感谢你们对我的包容，相比于其他助教，我做的实在不算好。
愿景总是美好的，但从学期初搬家、周中工作、周末学车、途中旅游散心等，步调偶尔有点落后，感谢邹老师和周老师的及时督促:)，才坚持下来。我要向你们努力学习暗时间的利用。
感谢群里的各位老师，你们都是我学习的榜样，你们对教学的那种热情，是我所缺乏且敬佩的，我努力向你们学习。
感谢同学们对我理解和支持，偶尔也让我会想起了校园时光。
附、同学们对课程的建议
1. 你认为每次项目的评分标准存在哪些问题，你认为的合理评分准则是怎样的（个人/结对/团体算三个）
同学一：
个人：对于评分来说，总体上还可以，每个具体的得分点列的比较清晰，围绕整个项目展开，但是编程能力因人而异，有些同学相对薄弱，对于比较难的编程题目可能要比较长时间才能完成，然而假如老师的时间是一周之内，某些同学没有按时完成但是有在努力编程做，我认为还是可以给出相应的分数的。在给个人评分时可以添加一项进步分，鼓励编程基础相对薄弱的同学再接再厉。再有，我认为在代码规范这一块要占比较大的分数，助教们对代码的审核应该要加强些，严格规范大家的代码编码形式，指出不符合一个程序员编码规范的地方。
结对：对于结对编程来说，我觉得最大的问题就是个人工作量的透明度不够大，这其实也是这种编程模式本身就存在的一种问题，每个人在结对编程中的贡献是不一样的，我认为每个部分的分数应该有相应的规定，然后对号入座，我觉得结对编程可以尝试改变一下模式，不是一个人做另一个人看，而是分工合作。
团队：团队评分标准相对来说是比较公平公正的，我认为最大的优点就是在团队互相评分以及提出贡献比的这种方法，不仅只从老师的角度去评判整个团队，还加强了民主性、公平性。缺点或者不足之处，就是针对不同的团队项目有不同的难度，所以这样针对每个项目的功能实现的要求应该有适当的区别，比如难一些的项目实现的功能可以少一些，相对简单的项目就可以要求实现更完善更全面的功能，评分标准也就可以有一些改动，希望除了看展示博客之外还可以参考其他的一些内容。我看了其他班级的最后总评分，有的班级总体成绩很高，有的班级偏低。
同学二：
个人：我认为个人评分的环节还是比较合理的，但是我希望可以再表现的多样化一点，因为个人作业主要是编程技术，而学好软件工程这门课并不只依赖于会编程，所以我认为在个人评分标准中，还可以再加入一些其他的评分，培养一些除了编程之外的能力。
结对：结对编程中就会出现两人比分太相近的因素，当然这些不可抗力是很难避免的，但是，结对作业中多数同学都会有出现工作分配不均的，虽然表面上看起来好像是没什么，但实际还是可以用一些必须运用到专业知识去回答的问题、任务在个人博客中做出解释，这样能减轻一些存在明显贡献差距的小组却两人平分差不多的情况。
团队：团队平分我认为是三个中最为公平、最合理的评分体系。首先，有体现各个同学的区分度，即使是在一个团队中，每个人所做的贡献不同，得分自然就有高低；其次，团队评分有照顾到协作方面的问题，如敏捷开发阶段，基本上所有的团员都要轮过一遍到两遍，每天不同的同学负责不同的内容；再者，还加入了各个小组给其他小组的打分，这又多了一个站在旁观者角度看问题的方向，这是团队项目的评分中很成功的一点。
同学三：
个人：觉得评分细则详细也基本合理，助教也做了点评，如果有改进的话就是增加自评以及把评分细则量化。（比如5分代表非常好，4分代表很好这样）
结对：可以两个人互相评分，像团队一样算出贡献权重。
团队：虽然有团队自评和互评的部分，但是不够细化，团队可以让每个人自己写对其他人的评分，最后取平均算团队权重（这样大家比较不尴尬…）
同学四：
个人：我认为个人评分的环节还是比较合理的，因为我自己的基础不好，完成作业的时候也没有讨论的对象，所以评分不能跟结对和团队的相比。
结对：结对编程是虽然有两个人一起讨论完成的，但是我觉得两人的分配不一样，难度也不一样，所以我觉得两人的评分有一定的差别。
团队：我觉得团队评分是最合理的，因为每个人的难度差别有点大，对于我来说觉得写代码的难度很大，还有其他的分配都难度不一样，分数的差别也不一样。
同学五：
我认为助教对我们一视同仁。但是吧，个毕竟每个学生的基础是不一样的，像我的基础就比较差。个人作业是我自己尽力写的，是可以运行的，但是结果并不怎么好。结对编程就比较靠另一个人了，自己心有余而力不足。团队作业由于我个人的原因没有及时参与，这是让我很后悔的事情；就算能力再差但是也没有主动去与其他小组进行沟通，这是我在这门课程最失败的地方。对于评分，助教还是很用心的经常会有互动，对于我提交的作业助教会以邮件的形式给出他的意见；而且对于评分有异议的地方也可以直接大胆向他指出。
同学六：
在个人作业方面，我觉得对于评分标准来说，可能太过于追求细节，没有注意每个人，每个学生的特点，我觉得如果改的话，可以把学生按照平时表现，分为几等，然后进行评分。
在结对编程方面，我认为两个人的分工透明度不够高。到底谁做的多，谁做的少，具体分工又是怎样，没有一个明确的评分标准。我觉得可以像团队作业那样，设置一个自评和互评作为参考。另外还可以写上具体的分工，让助教参考，去给出合理的分数。
在团队作业方面，我觉得在团队作业中，团队中每个人的贡献不能按照一个标准来划分，就像一个队长和一个编程员的比较，我觉得这就是不能比较的，大家都有用心做，不能按照做的事的重要程度来划分。其余的我觉得还可以。
同学七：
个人作业我觉得挺好的，题目也比较容易，对于我这个基础比较差的人都可以完成题目基本要求，而且助教对各项评分也很详细，很棒。
结对编程方面：我认为两个人的分工透明度不够高。到底谁做的多，谁做的少，具体分工又是怎样，没有一个明确的评分标准。我觉得可以像团队作业那样，设置一个自评和互评作为参考。另外还可以写上具体的分工，让助教参考，去给出合理的分数。
团队作业：我觉得班级映射分有点奇怪啊，为什么要以一个班级最高分作为评分标准呢？假如我是那个最高分，我会不会想着反正我都是最高分了，下次可以偷偷懒？另外每个班的水平参差不齐，这样搞的可能某位同学虽然在本班差一点，可是放在全部人中，他不一定最差啊！我认为就按照给出的分数算就很好，没必要再映射分了。最后一点，我认为就是助教回复这一点也算在评分标准里面，大家都是用个人邮箱注册是博客，基本上每个人都是一个邮箱。团队博客的时候都是临时找的邮箱，很难做到及时回复助教的博客。这一点希望改进吧。
同学八：
个人:无
结对：结对作业评分每个人的贡献量不太好评估给分
团队：--在作业下发的过程中已经明确将分值分配清楚例如写什么占几分，感觉助教在评分过程中自主性有点小，希望给予助教对博客的整体评分分值大一点。 --是否可以把博客互动的评分更换为奖励分，就是有互动的可以加分。不过这样好像不容易调动积极性。
最后整合评分建议：以班级排名第一同学的分数为100分的话是不是缺乏与其他班级的比较性，而且班级第一名越优越那么整体班级的水平可能会更低，是否可以四个班级有一个统一衡量标准或者将班级前三拿出来作比较来评定一个比较过的分数。
2. 你的团队项目是否成功，如果重来一次你是否还会选择这个团队，为什么成功／失败？
同学一：
我认为我的团队项目是成功的，如果重来一次我依然愿意选择这个团队。首先，我的团队成员们都很团结，不管是当下遇到什么事情，或者是时间赶不及，大家都有我们是一个团队的思想，去完成当日自己的任务；其次，我们团队的PM无论是从编程技术上，还是管理层面，都把我们团队带领的很好，每周都会做详细地计划安排，落实到每一个人，这才让大家有一个更清晰的思维，更清楚未来几天自己要如何合理安排时间去完成；最后，整个团队氛围很融洽，每当遇到矛盾我们都会当面沟通解决，避免争吵，互帮互助，共同进步，来完成我们的项目。
同学二：
比起其他团队的完成度，团队项目应该不算成功。失败的地方是大家对于项目的实际理解和能力不够，导致项目进度拖延严重。至于再重来一次，首先人生没办法重来，其次事情发展有时候不取决于个人意愿，既然一定要组队就一定要选一个团队。如果这个团队项目不成功，其实也是自身的问题。换一个团队也是一样，再来一次也没什么特别的选择倾向。Alpha和Beta都在这个团队，还是挺有感情的。
同学三：
我觉得我的团队项目是成功的，如果重来一次我愿意选择这个团队还有之前的团队，因为团队的成员交换之后我到了我现在的这个团队。我之前团队的项目是作业查重，这次项目是用微信签到和请假。因为我们团队非常团结，每次遇到不会的地方都在群里讨论或者在开小会的时候一起讨论。各个阶段都会分配好，还会在开会的时候会总结已经完成的功能和遇到的问题，一起讨论要改进地方，提高项目的完整性。
同学四：
我的团队组名是男神组合，对于这几次的团队项目不论是对我还是对团队都是失败的。首先，组内缺少有责任心的同学，对于写博客都是各种搪塞；其次，我们这组的平均水平过于低下，在各方面比如编程，设计框架等方面没有出色水平；最后，也是自己的原因，太懒散，没有真正将这个组合视为一个团队，不懂分工合作；而且自己也没有把团队作业放在心上。如果重来我不会选择这个团队，我会积极去组建新的团队。虽然我的能力有限，但是我可以学习。真的非常抱歉并且十分后悔没有加入团队的工作，如果重来一次我一定好好加入团队的工作。
同学五：
我的第一个团队项目是失败的，失败的原因很简单，第一：大家都不会，大家都没积极性，大家都明白对方是怎么的水平，不管怎么做也就那个样子，没有动力去想把项目做好。第二：大家都不是情愿的成为一个团队的，当然这不是一群成年人的做法，但是大家积极性就是调不起来。如果可以重来，我会去找一个具有自制力和拥有积极性的团队。
同学六：
我最开始是在男神组合团队的，在这里我的感受如下：我希望老师以后在组建团队的时候，询问班级情况，强弱搭档，这样才会进步。不要让大家自由组队，剩下的人在没有经过个人的同意的情况下，就莫名其妙的成为一队了，大家你不情我不愿，去哪写出好的代码。
在新的团队中，我如沐春风，很快融入新的集体，很开心。
总结一下你们团队在做项目时大家的时间安排情况，可以匿名写；我们基本上都是在晚上挤时间做的，到了大三了，考研的考公的就业的，都要准备了，还有课程，时间很紧。不过时间就像海绵中的水，只要去挤还是会有的。但是有时候还是会出现今天的任务没有完成，明天去做的，但是还是只能默默写上这是昨天完成的。
同学七：
团队项目最终大家认为完成了各自的目标，我依旧会继续选择这一个队伍，在这个过程中大家给予了很大的帮助，感谢大家。
3. 总结一下你们团队在做项目时大家的时间安排情况，可以匿名写
同学一：
我们团队在时间分工安排上还算是比较平均的，负责编写代码的两位主要同学花费的时间确实是很多的，因为代码需要不停的调试修复，那他们主要的任务就是完成主要代码功能；而剩下的同学，我们也做了不同的分工，采取轮流的形式，需求分析、撰写博客、测试代码、展示发布等等，每个人都要参与投入。我们会尽量避免有个别同学“打酱油”的情况发生，例如今天你的任务比较轻松，只需要撰写博客，那你明后天可能就需要配合两位编写代码的同学，去完善他们写出来的功能，去测试，去修复bug等等，总之，在合理的范围内，我们会尽量让每个人所花在这个团队项目上的时间平均。
同学二：
由于我不是pm，对于大家的安排情况不太了解。alpha版本的时候个人编写的是代码的导入功能，必须先导入才能实现后续的其他功能，所以我很早就写完功能交付了，后面也参与了前端以及接口的代码编写工作，但是由于技术水平有限，没有太大产出。其他零碎的时间就帮助博客的内容撰写，然后beta阶段所有人员就进行bug修复和界面改进。大家上课和自己的事情都比较忙，时间安排比较靠自觉了。
同学三：
我们团队主要时间安排就是每个人的分工不同而所用时间不一样，也就是两个写代码的同学的所有时间最长吧。因为代码每天都要更新，尤其是在冲刺阶段，但是其余的队员的所花费的时间也不短，每个人都有分工好的工作。分工有参与已经写完的功能进行完善功能，参与测试的，参与界面优化的，撰写和发布博客等。时间安排的很均匀。
同学四：
大家的时间安排我不知道，因为各自的基础不一样，编程的速度也不一样。我就说说在男神组合时期，后期因为我自身的关系渐渐没有参与。在起初创建男神组合的时候，我主要负责写博客，还有与组长讨论关于Java代码，那段时间因为在复习Java对于Java的编程能力还是有一些。但是组员的积极性不高，没有真正的融入到一个组合。所以当我手术结束后，被告知组合解散，然后十分的茫然不知道自己该怎么做，不懂询问别的小组，就那样一个人销声匿迹，这是我非常后悔的事情。
同学五：
在第一个团队的时候就不说了，项目已经失败了。在第二个团队项目中，我们的时间安排都是按照项目中时间和计划来规划我们自己的时间的。在冲刺的阶段中，我们都保持了一天有1个小时的时间来对项目有具体的改进，我们都很自觉，积极性也不错。
同学六：
时间安排情况：团队后期主要进行了分工，代码能力强的同学负责程序编写，审核测试人员负责测试找漏洞，日常博客管理同学负责安排日常开会时间活动安排的具体事宜。个人负责不同部分，时间不好评价。
4. 软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。请问你们在项目的 需求/设计/实现/测试/发布/维护 阶段（一共6 个阶段）中都学到了什么 “知识点”， 每个阶段只要说明一个知识点就可以。
同学一：
需求：需求分析一定要适应市场，且要具有竞争性和可行性，不能太理想化。
设计：建立以文字为主的文档，用图形构造模型。
实现：首要任务是完成规定的任务，要定期做进度小结。
测试：可分为黑箱和白箱，可以先进入功能测试阶段做大体的测试。
发布：学会接受设计变更，不断提高软件质量，修复存在的一些小问题。
维护：进行回归测试，总结回顾整个项目。
同学二：
需求：必须对用户进行真实的访问调查，而且必须在alpha阶段结束后倾听用户的反馈，并根据能力水平，bug来改进需求。可以用模拟故事场景等方法。
设计：项目正式开始时先进行原型设计，并编写项目计划书，这样整个项目流程才清晰有序，对产品的框架有一定了解。
实现：可以用leangoo对整个项目进行细化分解，追踪整个项目进度，最后用燃尽图直观显示。
测试：首先每段代码编写后代码人员必须进行自测，代码无误后再上传Coding，最后项目完成后进行性能测试
发布：发布后收集用户反馈，对beta阶段或者项目的优化收集信息，而不是发布之后就不管了。
维护：定期更新版本，优化系统，修改bug，这样才能保证项目的活化，不会流失用户。
同学三：
需求：根据不同的用户，了解不同的需求，满足用户的需求。
设计：用图形构造界面的美观。
实现：完成用户需求的任务。
测试：可以查出自己的实现的不足，改进不足方面。
发布：改进功能存在的问题。
维护：总结整个项目。
同学四：
需求阶段：学到了你做的产品是最终是要面向市场的，所以用户很重要，要知道自己的产品的用户是谁，他们有什么样的需求，然后按照需求设计。这样的初衷才不会让你的结果跑偏。
设计阶段：顶层设计很重要，做产品前一定要有清晰的思路，先要做好整个架构的设计。
实现阶段：实现代码的时候要谨慎一点。
测试阶段：测试阶段要考虑全面些。
发布阶段：发布产品的时候要让用户知道这个产品的特性，优点，让用户有眼前一亮的感觉。
维护阶段：维护很重要，这是守住用户的关键，好的售后总是更让人喜欢。
同学五：
需求阶段：学会使用NABCD模型进行需求分析，还有如何撰写需求说明书；
设计阶段：学会了使用功能优先级，选择最核心的杀手功能；
实现阶段：学会使用燃尽图掌握项目进度；
测试阶段：学会使用测试工具对代码进行测试；
发布阶段：学会了展示博客的编写，如何对项目进行展示；
维护阶段：学会了维护阶段的具体做法，需要如何维护，如何使得用户得到最好的用户体验。
同学六：
需求阶段：以前从来不考虑别人想法，只是单纯的完成作业就好了，现在会去考虑，虽然可能完不成那样的要求，但是还是去考虑。
设计阶段：有明确的计划很好，这样有整体观念。以前都是走一步是一步。
实现阶段：代码规范很重要，代码规范很重要，
代码规范很重要，重要的事情说三遍
测试阶段：没有规范么想说的
发布阶段：我认为这个功能说明这个特别好
维护阶段：这个还是去听用户的说法好。
补充：考试题量实在太大了，监考老师都问我写这么多，不累吗？
同学七：
需求：不可以局限于个人、小圈子来看待问题，同一个事情每个人有不同的需求不同的看法，切实了解客户需求很重要。
设计：界面的美观是吸引客户眼球的敲门砖。
实现：想法与实际编写过程有差距。
测试：意想不到的漏洞时刻回来必须时刻待命。
发布：在发布之前要进行详尽的内测，否则之后会有更多问题。
维护：项目说明书简洁详细很重要。