USTC现代软件工程--summary

起笔：我希望先简单总结一下我在这门课程中经历的一些工作以及学习到的一些东西，再对自己、队友、老师做一个评价。然后我想提出一些对这门课程的一些看法和建议，与自己的心得体会。

第一部分：

我在这门课上经历了个人开发、结对开发、团队开发三个项目。分别用三个词来形容它们我认为是：高效、愉悦、拖沓。

个人开发真的让人很烦躁，基于种种原因（文件太大、内存不足、系统更新、时间紧张），但毋庸置疑的是问题解决的层次逻辑非常清晰，psp表格也填的很明朗，即使在某些问题解决上卡壳了很久，总体的过程还是十分高效没有浪费时间。

结对开发时我们在单个问题的解决上显然快了许多，所以没有遇到非常棘手让人头疼的麻烦（得益于hzp大佬队友的帮助），但由于我们日常工作时间地点上的一些冲突导致我们沟通存在少许障碍，有时候打电话或者线上聊对于问题的描述会出现一些偏差，无形之中浪费了一些时间。总的来说还是两人在一起同时工作的效率最高。

重点想谈一谈团队开发的过程：我们小组的项目我认为在我心目中是完成的是不合格的，要甩锅的话，我肯定首先甩给组长。诚然，组长完成的工作量是组内最多的之一，但是我认为组长作为团队的核心，他有着更重要的责任，在如何解决个别队员积极性不高、团队时间与进度安排、项目管理与会议博客更新等问题上都做的不够。或许有人认为我站着说话不腰疼或者是个甩锅队友的坏孩子，但是我还是会理直气壮的说，几乎每次开会、博客更新、任务都是我在群里主动询问或者提出的，乃至于到了7月份我问这些问题的时候常常得不到所期望的回答（若有质疑我可以随时截图为证），我觉得最可怕的就是空闲的队员们得不到自己的任务，等到有其他事情了结果又开始被逼迫，而不想做的队员们却没有任何压力，在这一点上我认为首要责任在于组长。

关于我自己的工作，我给自己评分为A，至少7月中旬组长告诉过我，我只需要完成所有数据接口，接下来的工作交给他们，这部分我认为我全部完成并在测试文件中成功实现了，对接中据说遇到了一些奇怪的问题是队友解决的，所以我不敢给自己打A+。

关于这门课，助教和老师都很认真，我提出两点建议

1. 这门课比较适合在小学期自由选修，这样真的方便于更好的模拟公司制度的管理环境

2. 效绩考核、跳槽辞职、辞退裁员等等这种制度太有必要了，对于一个团队来说，热情与积极性我认为比稳定更重要

3. deadline的设置希望能够确定一些，可以一开始给一个弹性的时间范围，但是不希望改动太大，因为毕竟同学不是全心全意一门课

（时间紧迫，叙述潦草，暂时记录一下，8月12日回到家更新）

8.14到家更新：

引用队友一句话：任何一个功能的实现，需要数据库、前端后端良好的配合。

1.菜鸟的开发过程中哪一步最容易被忽视？

我记得上次俞昊然校友来做分享时给我们强调的最关键的一点就是“技术选型”，但是懵懂的我们并不理解要在这上面花费多大的心血。前期对技术一无所知之时花了太多时间在造轮子上，技术调研上队员没有做好，导致只能让组长一个人单方面决定，没有足够深入的调研选择。

导致的结果就是“乱”，走一步看一步，多小的一点事儿都只能看“队长”，给团队的leader增添了许多压力。除了队内的强调之外，我的建议：

a. 选题报告之后应该空出更多时间来做调研，之前老师定的一周（减去其他课程时间实则只有两三天）时间太短，实现不了“从无到有”

b. 各组之间的调研可以进行更多分享，不仅仅局限于一次简单的报告，可以针对项目技术类似的一些组进行多组会议

2.团队开发的队长怎么与队员相处？

或者说队长与队员应该保持怎样的关系？我从summer workshop回来也算是当过一次project的组长，虽然只有5人四天的工作，但维持良好的关系的确是不可或缺的。（队员会争吵、会不服气、会因为自己的想法被diss而沮丧，如果按照着别人的想法来做，人类是真的很容易就不上心，尤其是当我们做着毫无金钱收益的工作时。这一点我觉得需要队长和队员的social来解决）主要还是队员会不积极，会用一些理由来推辞安排的工作甚至不回复。关于这一点我的建议是：

a. 任务安排或者重要问题交流时必须面谈，至少是语音，不带任何感情色彩的几行字的安排和交流效果很多时候都更差

b. 组长在做任务安排时的ddl需要适当提前，保持一定弹性，无论是对项目进展还是与队友妥协的时候都会留有一定空间

c. 针对大家用的最多的借口“赶其他的项目”，必须要求本人做出一定字数的解释，其他ddl为什么存在？究竟是不可避免还是之前拖欠。关于这种请假方式，如果次数超过一定上限可以直接影响他的绩效。

建议都是建立在同学关系之上的，或许在企业内，某一些问题根本不会存在，某一些内容根本无法容忍早就被炒鱿鱼了，但我想说学校还是学校，这些问题只能改善，无法根除。