1、你认为每次项目的评分标准存在哪些问题？你认为的合理评分准则是怎样的？（个人／结对／团队算三个）
- 对个人／结对／团队这三个评分标准的整体来说，大体上看是比较完善合理的，不过就我个人看来还是有一些值得商榷的地方。首先我要感谢老师和助教们的辛勤劳动，才有这一学期大家收获满满的一门课。老师和助教都特别认真和辛苦，把要求我们要写出来的点都很明确地列出来了，也根据这些点给出了非常详细的得分点，让同学们在写的时候知道从哪里入手写。不过在一学期的观察和同学们的交流中我发现，助教在给分的时候对每个得分点的质量要求不够，存在只要有体现就得分没体现就不得分这一问题，可能会导致大家为了得分而只是很敷衍、很表面地体现这个点，并不会主动去思考，这就违背了老师布置这些要点的初衷。我觉得在评分过程中不应该只有黑白，应该区分出一些灰色地带。对于每个得分点，没有体现那肯定不得分，而对于其他不同质量的体现，应该根据质量的高低来给出更加详细的分数，不应该要么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阶段中就因为这个原因被扣了好多分数，如果我们用了前一天一样的截图就可以因为有体现这个得分点就不扣分吗？我觉得当我们在博客中说明清楚没有展示运行截图的原因之后，老师可以考虑着适当扣一些分数，而不是全部都扣掉。（这一点因为涉及到我们小组的分数，扣了不少的分，所以可能存在不客观的情况，我只是在此提一下，也希望助教看到可以跟我多交流，帮我解答这个疑惑。）
2、你的团队项目是否成功？如果重来一次你是否还会选择这个团队？为什么成功／失败？
我觉得我参加的两个项目都是很成功的，参加的这两个项目中我都是作为组长进行统筹分工。如果再让我选择一次，我还是会选择这两个团队，因为我的队友们实在都太给力了，太可爱了！
我在alpha阶段参与的项目是“四则运算自动生成器”，这一阶段我们完成了除登录/注册之外的所有功能，还在不断需求分析、用户反馈的过程中额外完成了一些新功能，最后被老师评为第一阶段的优秀博客。我觉得第一阶段中我们团队成功的关键在于需求分析时切实找到了这个软件的真正用户以及在冲刺的七天中坚持每日的用户短反馈模式。在进行第一次需求分析的时候，我们团队偷懒了，以我们自身的角度脑补了这款“四则运算生成器”应该具备的功能。我们也果然被老师、助教们看出来了，冲刺第一天需求分析的博客被怼的很惨。多亏了老师们及时指出了我们的错误，我们才知耻而后勇，让我们的需求分析真正落地。我们不仅采访了几个小孩在上小学的叔叔阿姨，还找到了一个小学三年级的数学老师，让我们的软件真真正正地面向它的用户群体。不仅如此，我们在alpha的七天冲刺里还坚持每天收集用户的短反馈，我们把每天完善好的软件发给她们使用，根据她们的反馈意见再不断修正。也正因为如此，我们的软件才增加了许多之前我们根本想不到的新功能。
在alpha阶段结束之后，老师要求我们每个组都执行一次换人机制，由于那时我觉得我们组的功能在第一阶段都实现得差不多了，就主动申请换到其他组去继续锻炼自己。第二个团队的项目是“英语词典”，虽然在Beta阶段中的博客得分不是很高，但我还是觉得我们团队是很成功的。我觉得第二阶段中我们团队成功的关键在于分工明确，队员的执行力强。在每次老师布置完任务之后，我们就会一起把老师安排的任务分解，根据每个人的特长分配到个人，每个人都很及时、主动地完成自己的任务，队员之间的默契程度也越来越高。
3、总结一下你们团队在做项目时大家的时间安排情况，可以匿名写。
我们团队在做项目时大家的时间安排比较自由，不同的队员安排的时间都不太一样，不过大部分同学都是利用晚上的时候来完成自己的项目任务。我们团队的工作模式是：在老师布置完作业之后，我会根据老师作业博客里要求体现的那些得分点进行分工，要求他们在截止时间的前一天晚上十一点前把他们各自完成的部分用Word文档的形式发给我，然后我再根据他们的文档进行整合串联，对写的不好的部分进行修改。因此，我们团队每天除了站立会议以及遇到问题大家在讨论组里互相讨论之外，大部分时间大家都是独立完成各自的任务，所以每个成员具体的时间安排我可能不太清楚。不过可以确定的是，由于这个学期课比较多，大家白天的时候一般都在上课，所以几乎都是在晚上完成自己的项目任务，每个人一周差不多安排出一个晚上的时间来就够完成自己的任务了。
4、软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。请问你们在项目的 需求/设计/实现/测试/发布/维护 阶段（一共6 个阶段）中都学到了什么 “知识点”， 每个阶段只要说明一个知识点就可以。
- 需求阶段：需求分析一定要落到地上，一定要找真正的用户对象，而不能靠自己的“脑补”；需求分析也不是一蹴而就的，应该坚持多次地采访、回访用户；
- 设计阶段：功能设计要从实际出发，设计功能时往往会去百度现有的同类软件具备哪些功能，这一做法不是不可，但是绝对不能因为这个而束缚住自己的想法和思路，要勇于创新、勇于尝试；
- 实现阶段：在实现功能的过程中，要继续保持与需求分析用户的联系，最好要把每天完成的软件都发给用户使用，然后根据用户每天的反馈不断修正功能和增加功能，坚持这样的短反馈，会受益匪浅；
- 测试阶段：测试人员不能只包括团队成员，最好找一些完全不熟悉这个软件的同学来测试，看看程序界面是否友好，操作是否有困难；另外，测试应模拟多种平台、环境以及一些特殊情景，保证软件的兼容性以及在特殊情况下的可用性；
- 发布阶段：软件在发布的时候最好同时附上使用说明书，说明书的内容包括软件具备的所有功能、软件的使用方法以及注意事项等；
- 维护阶段：在维护过程中也应该不断收集用户的反馈，不断完善软件。
5、PS：自己想说的话。
刚开始知道这门课改革的时候其实内心是拒绝的，毕竟上一届是只要期末做个小项目出来就给过了，而我们却要在平常的每周里都付出辛勤的努力。不过大家不也都是一边抱怨这门课多么占用时间、自己多么不想写博客，而又一边按照老师的要求按时提交博客作业吗？现在想起来还是挺感谢这门课的，让大三这一年显得充实了不少，一定程度上也让大家保持着紧密的联系，为班级同学们留下了几十张“并不情愿”的合照。很感谢这一学期以来老师以及助教们的辛勤付出，才让我们这么顺利、这么原汁原味地体验了一把从idea到APP的艰苦历程，真的收获很多，不说技术上增强了多少，至少文字表达在这十几万的博客中提升了不少。
这种教学方式虽然真的很“烦”，但真的很有收获，希望以后的新生能在大一刚刚进来的时候就体验这种教学模式（反正那时候我已经毕业了，让新生接受最残酷的历练吧hhhh），这样他们就能从一开始就养成良好的学习习惯，不像我们这样大一大二松惯了，大三突然紧一下，很多人都会抱怨。最后对考试提一个小想法，建议把最后一题改到第一题，这样大家都会超级认真地写对软件工程这门课的建议，然后原来的1、2、3题改成2、3、4题，这样设计应该会比较合理一点，老师希望得到的信息也会更完整一点。