软工实践个人总结

一、请回望第一次作业，你对于软件工程课程的想象

1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？

我的期待就是能和团队一起完成一件有意思的事情，在这个过程中慢慢补足自己上面所列出的一些缺陷，希望在结束课程后，自己与先前的对比能够发现有许多进步与收获。
我希望我能每天坚持学习一点新的东西，改掉自己有的一些懒散的习惯，养成每天规划总结的好习惯，和小组的每个成员一起努力、共同进步。

• 对于我自己写下的期待，感觉完成了90%。有和团队一起协作配合，有完成自己的作品，还差一些的可能就是项目做到一半的时候自己感觉做的事情并不是很有“意思”。
• 至于“增强计算机专业的能力和就业竞争力”，还是有达到一部分的。毕竟在这期间接触了许多以后可能会经常遇到的工作流程，也锻炼了自己不断解决问题的能力。
• 不足就是看到的、了解得越多就更知道自己的短板更多，要学的也还有很多，还是有漫漫学习长路要走。虽然以后没有软工课了，但是自己还是要有定期规划和总结的习惯，才能检验自己每一阶段的成果。

2）总结这门课程的实践总结和给你带来的提升，包括以下内容：

1、统计一下，你在这门软件工程实践中，完成了多少行的代码；

• 3000行左右

2、软工实践的各次作业分别花了多少时间？（做一个列表）

- 作业	用时（小时）
第一次博客作业	10
第一次个人编程作业	26
第一次结对编程作业	16
第二次结对编程作业	21
团队选题	10
需求分析	13
现场编程实战	12
Alpha冲刺	42
Beta冲刺	36
最终答辩	18
合计	204

3、哪一次作业让你印象最深刻？为什么？

• Alpha冲刺。为了做出第一个版本的来演示，前后端在答辩前几天都在熬夜加班，最后一天也见到了凌晨四点的福大吧，天还是暗的。作为组长，他们在一起熬夜的时候，我也要在，我既要做完自己负责的部分，也要负责前后端不断的进度沟通和成品检验等等琐事，在活动室他们最晚的一个人到几点走我就是几点走，既可负责开门又可负责关门。。。

4、累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答

• 合计204个小时。平均每周花13个小时。

我打算平均一天投入2个小时，也就是一周大概14个小时用在这门课上。

5、学习和使用的新软件；

• Axure RP9、WinScp、Navicat for MySQL

6、学习和使用的新工具；

• ProcessOn、Excel

7、学习和掌握的新语言、新平台；

• 新学语言：JavaScript
• 新平台：Github、Codacy

8、学习和掌握的新方法；

• 结对编程、项目管理

9、其他方面的提升。

• 沟通协调、解决突发问题的能力，学习新技术的能力

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

• 团队进度安排很重要。并不是给组员分配一个任务说你尽快完成就能有很好的效果，比较好的方式应该是对每项工作选择一个合适的期限，再将这个期限分成多个小阶段，每个阶段都要主动检查或者要求其主动汇报阶段性成果，一个阶段的不过问很可能就导致了一个阶段的无所事事。给与适度的压力与期限才能更好的让每个成员有自己的目标（更好更认真地在团队中干活）。

• 自己也要有清晰的目标。最好一开始就像好自己想从这门课中获得什么，如果想多学些知识和技能，就不要担心自己不会也不要怕累，有了自己定的目标就要肯付出，花了足够的时间，自然就会有所成长，有所收获。当然也不能盲目自信夸下海口，把各种难题都揽到自己身上，合理评估自己的能力，选择一个自己比较能完成的工作去做好，就是对团队最好的贡献。

三、这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？

• 感谢自己吧。在后来繁杂的团队项目中能够坚持下来，虽然很多事可能都积压在组长这，但是也积极地去完成，没有逃跑没有放弃。做好了自己应该做的，也经历了一些未曾经历过的。只要有定下自己的目标，有属于自己的信念，就应该是不会轻言放弃的。

四、个性发挥，包括图文、照片和创意等

• 很遗憾没有拍下凌晨四点的福大。应该是到了那时候，自己最想做的就是上床睡觉吧。
• 既然没有图接下来就说一点自己想说的。
• 我的想法是进行改革的尝试总是好事，多试试才能知道哪一种培养过程比较适用于不断增多的学生人数吧，有尝试和反馈才会不断改进吧。在级级更新中可以保留适应度较大的方式，舍弃掉那些被认为是没有意义部分，不断改良，最终应该是会得到最优解的吧。。。？
• 我自己觉得作业的评价方式“互评”可能没有太多价值，甚至常常会让自己感觉所完成的作品没有得到应有的认可，而且有时候一个小组内分为好几个人去评分，最后一个组能出好几种评分标准，也让被评分的人看得糊涂。而且，不同组互评的主观性太大，相互间的评分也会有各种说不清的影响因素。虽说一开始互评是为了公开透明，有问题可以立马提出，但是最后公开透明可能也使得每一组的真实想法受到了一些限制，也会有些手下留情？
• 对于后面的团队项目，一开始可能很多人懵懵懂懂啥都不会，就被赶鸭子上架，和相熟的一些人就匆匆凑成了一队，其实也不太了解各自的长处，可能组出来的团队是有多处短板，在一些无人曾踏足的方面，就只能靠步步试错总结得出开发经验，然后在不断改进。或许下次可以延后组队时间，在一两次编程作业结束后，能够看到每个人的发光点的时候，再进行团队选人，每个人都了解各自的真正的长短处，而不是仅是嘴上说说，才能组成一个较为合适的团队。
• 可能是因为从选修到了必修，软工课的人数增多，为了保证组数在固定的数量就增加了每组的人数，可能做到最后完成，每组都会发现在设计开发过程中，太多人数并不一定是优点，人数的冗余可能反倒成为一个负担，每个人都要做点事情，这样把工作细分成太多碎片最后的效果并不是很好。个人觉得每组5个人以内会使团队协作更加高效也便于管理。
• 还有就是开学初大家都是热情高涨，喊着大大的口号，说着我很乐于熬夜，想多学学新东西，可是最后在每一组内真正肯花时间持续用心的也就是一部分人，自然有所收获的也仅限于这部分人，其他人可能仅仅掌握了怎么和团队沟通、如何合理划划水之类的一些技能。虽说是一个团队，可以相互加油鼓劲，可真正动手的也是部分人，这些人到最后可能也不断抱怨，叫苦连天。我想兴趣是一部分原因，可能大部分组的选题都只是临时起意或是短时间内讨论出来的？并不是那种期待已久的梦想或者能勾起自己兴趣的项目。最后看来，也许只有做游戏的第四组真正get到了他们的兴趣？可惜他们的开发过程也并不顺利，最终交出的作品也不是令人满意。一部分原因可能是真的有学习周期在里面，另一部分则是没有真正专注于这项工作。毕竟，兼有数门课程课程和接连的考试，也会影响大多数人的开发热情和状态。若不能全身心的投入，可能团队开发的过程就像是被迫创作，结果就只是被甲方不断敲打出一个一个没有亮点的增量交付。
• 希望软工实践能坚持改革，更好地帮助更多的学生达到他们的立下的目标！