• 对于软件工程M1/M2的总结：

• 假象-MO

在团队开发的前期，我感觉自己其实给了自己很多的期待，因为一直希望着自己可以在团队中担任一个角色，用自己的力量为团队多做事情，也给了其他人一些假象，那就是看起来我是一个做好充分准备有足够能力去挑战自己编程能力的一个人。虽然自己现在看当时的自己感觉很好笑，但是也在这样子的掩护下，我遇到了一群同行人，一群帮助我实现了我想要的假象的人，也找到了很久没有得到的那种团队合作经历。

• 荒芜-M1

在第一阶段中，我与队员一起开发了“北航MOOC“的客户端，在这个客户端的开发过程中，我深感自己的不足，并且在开发的过程中尽量学习，让自己得到足够的能力去开发队友需要的部分，我们使用的开发环境是Android Studio，开发的是安卓用户的软件，Android Studio确实有着很强大的功能，但是对于一个毫无经验的新手来说，这更像是一本天书，我努力地翻阅这本天书，也在里面学到很多东西，比如在解决课程列表图片异步加载失败的问题上，有解决方法： inputstream只能够读一次，存为文件之后不能再次读取为bitmap，所以先存成bitmap，然后将bitmap导出为文件。并且在这基础上进入了进一步修改，因为大量的bitmap会导致堆内存溢出，所以会选择压缩图片大小的方式来解决最终的一系列问题。

在M1的开发过程中，我是真的挺感谢我的队友的，因为自己的编程能力确实有些欠缺，但是队友都有给予一些耐心的辅导，自己负责了测试还有产品需求分析的工作，也尽可能为团队带来贡献，我的队友都非常努力的投入在软件工程开发中就比如唐彬会告诉我怎么去配置开发环境，并且在我生病的那个阶段也有慰问我，虽然不是一个班的同学，但是我觉得在一个队伍中一起工作的时候让我感觉到很开心；比如闫昊和史神，他们两个在任务分配的时候都主动挑起了负责主要开发的这杆旗帜，并且史神那段时间自己其实也是很繁忙，闫昊也是在前期的开发过程中解决了很多很多的瓶颈，让开发在中后期有很好的开发条件；金哉仁和余帆，在开发过程中也是做了很多的事情，哉仁负责了界面和测试，余帆也在闫昊同学的指导下，努力帮助闫昊和史神挑起开发软件主要代码编写的这杆旗帜！歪果仁带你灰这个名字也是显示了我们队伍的精气神吧！大家都很努力的工作，都有在开发的过程中拿出自己最大的努力，都力所能及为团队分担任务。

在这个团队中我感受最多的就是融洽的合作，并且合理的分工，因为团队中有两个人之前有过很多的开发经验，并且也在实验室进行过工作，在软件工程这方面有很强的基础，在我们开第一次meeting的时候，这两位同学就跟我们说了他们当时开发的经历和遇到的问题，第一次meeting大多数时间我们都是在吐槽闫昊和唐彬之前的开发经历，也看的出来，团队中每个人的角色至关重要，尤其是PM这个角色，在他们的描述中，PM应该是那种手持教鞭，站在你身旁催你写代码的人，并且鞭打你也在某种意义上是应该的。在闫昊他们的总结下，我觉得我们在努力地朝着更好的方向发展，制定的合理的分工，安排准确的时间线，每天都会在群里面更新我们目前的状态，让每一个同学在结束工作的时候都可以看到我们的任务进度还有接下来将要做的事情。

在M1的过程中收获大概就是得到了一群努力的队友，并且学会了开发环境的许多知识，也充分感受到了软工的乐趣。虽然我在团队中不能作为领头羊，也不能够做一个标杆，但是在这个过程中，通过与队友的交流让我懂得，其实人都是在新的环境中，努力去适应并且拼尽全力去找寻一个存活的方式，如果你不能够适应这个强大的环境，那么大概面临的就是死亡和灭绝了吧。

• 消亡-M2

在M1中我用自己的生活方式存活了下来，但是在进入M2之前的那时候，我大病了一场，每天都在跑医院，然后也被编译数据库其他科目作业弄得焦头烂额，在自己的精力上没有办法给出更多的帮助给我的队友，最后在突如其来的交换队友中，我被不出意料的交换走了，当然我也没有说我很难过啦，因为我能明白这个制度是一个互利互益的过程，为一个团队注入新的血液，融入更多的元素，说不定会让一个队伍产生新的动力继续向前，不过我的M1的队伍貌似热情高涨，来什么烧什么的感觉，我拖着我的残躯来到M2的新队伍，然后就倒下养病了，给M2队友带来了不小的麻烦。

由于身体的缘故，在M1进M2这个阶段，我整个人是虚脱没用的，尤其是在M2时，队友来找我照相，我都没能够下床去配合（那个时候其实正在发高烧），给我的新队友们一种态度很差的错觉，不怎么做事连照相都不来的人，要是我，我可能直接fire掉了！不过在M2的团队中，我努力地去融入新的环境，开meeting，在github上加入团队项目，也在不停的学习知识去弥补大病一场的那个空缺，也在后来步入正轨，回到一个团队队员的工作中去。努力的去学习需要运用的知识，但是由于空缺太大，导致我一直没能跟上队员们的脚步，一直处于后面的位置，并且也没能跟队员变得熟悉起来，大概之前在M1的感受消亡了，不是因为别人，而是因为自己的原因，现在感受起来真的是一种无可奈何的感受，因为我没忘记我的初心，也没忘记我想要做的事情，可是一场大病之后就是什么力气都没有，想要往前赶的时候，提不起劲来了。可能是因为，我对于这个新的团队的归属感不足吧，也可能真的是因为那个gap确实有些大，让我觉得我已经有些没有力气去追赶了一样。

但是在M2这个阶段中，我不停的反思，为什么我不能够把更多的时间贡献给软件工程，为什么我生病了之后，起床想要做的第一件事是编译数据库，而没有去选择估计软工，或许真的是因为我太忙了？或许是真的因为我生病了，精气神不足，只能够选择做一两件事，但是不能够有足够的时间给软工？还是说我本身的态度中，就没有把软工放在一个特别高的位置呢？我想这些因素都出现过，但是都不是唯一的借口，我想还是我对自己的约束力不足，其实对于我来说软件工程最后的分数不是我评判的我自己好坏的标准，而是我这个过程中的心态吧，我真的觉得我两个队伍的队长和队员都很棒，都给了我很多的帮助，让我在软件工程这门课中有很大的学习空间，但是作为团队的一员，我认为应该完成己任，团队的领导者有义务去安排事情的每个细节，而团队的成员有义务去完成被分配的任务细节，这才能够被称作团队责任感，我的队友都是令人喜爱的队友，我们的领导者都是尽心尽着没有压迫队员的PM，比起很多人，我觉得我是很幸运的那个，尽管这次软件工程我留下了不少遗憾，也因为身体的情况耽误很多事情，但是对我来说，我真的学到了东西，受益良多，至于分数我相信不如收获重要，我也要在这里谢谢M1M2陪伴我的队友，还有给过我指导和帮助的同学。

• 之前的问题，如今的理解：

• 团队中最重要的角色是什么，他的工作是什么？

在一个团队中，最重要的毋庸置疑是领导者，在软件工程这种结构的分配下,PM当然是最重要的人，但是在团队中，PM其实并不是一个绝对的领导者，因为PM是团队的粘合剂催化剂，疏通整个团队的工作和任务，PM将会对每项任务进行很细致的分析，并且都要跟队员沟通到最好，做到拥有很强的把控能力，并且我跟大多数人的想法可能一样，在一个团队中，大家的关系应当都是平行的，在这个团队中不会存在上下级。

• 为什么要一直写daily scrum，daily scrum有什么作用？

其实期初对这个这个产生疑问是因为我觉得这些开会的内容都需要要以博客的形式记录下来，这是不是代表着我们的工作是透明化的，不知道意义在哪里。不过后来在我阅读别人的博客时，我发现，其实我们做什么都是从零做起，然后去学习新的东西运用到原先的知识上，以博客的形式记录下来会让我们互相促进学习进度，而且如果博客的阅读数量多，那么自己团队中的人也会多多少少觉得这是一个小成就，也能促进心态的发展。

• 为什么产品的任务要分成前后端？

因为在大学三年多来，已经习惯了大作业的形式，仅仅是需要一个程序，能够给出正确的输出结果就算是大功告成，那仅仅是一个小的代码程序，面对庞大的任务量，在有限的时间码出无限的代码这种事情肯定让多个人一起分工要比一个人来的痛快的多，设计到分工那我觉得肯定需要从产品的设计上进行分工，前后端的设计，是程序开发的最优解，也能让团队在合作的过程中体现出重要的个人责任感，也让每个人都能够专精的进行工作。

• 敏捷开发模式适合我们学院的学生嘛？

我觉得这种优先开发的模式，应该是属于那些个人能力比较突出的团队，因为如果一个团队中，很多人的程度都较低或者能力不足，那么这种敏捷开发模式只会徒增开发难度和压力。

在敏捷开发的过程中，每个工程师都会有自己独立的开发空间，但是这会不会因为每个工程师的思想不一致，导致一些细节问题很难处理呢？

我对于敏捷开发的理解不是很深入，但是我能明白理想的团队开发就是指团队聚在一起，集中工作，总是会优先解决出现的问题。敏捷开发更像是把我们从流水线的开发解救出来，让所有人都能够摆脱一个人工作之后另一个人才可以行动的枷锁。

• 在“需求/设计/实现/测试/发布/维护”阶段中的学习与收获：

• 需求：我认为需求这个应该算是一个团队的工作本身的需求，要平衡团队成员的能力和熟悉语言进行开发软件的选取。
• 设计：这个阶段尤为重要，因为这个阶段主要解决的就是用户需求的问题，设计出符合产品定位和市场客户需求的功能，对此需要团队在市场对产品进行定位，做出符合预想的产品进行推广。
• 实现：设计之后需要实现设计好的功能，并且在实现的过程中还要考虑实现难度的问题，也要考虑实现软件的整个流程和所需要的时间。
• 测试：测试应当是用户体验最重要的第一步，我们的测试人员就是我们的第一个种子用户，给予软件重要的意见，以方便我们做出改变和调整。
• 发布：我们要发布自己的软件，并且进行一定的推广，做好活跃设备的统计，因为市场上真正使用我们的用户，一定是活跃设备的那些人，也是我们所面对的主要用户。
• 维护：维护阶段我觉得是软件最需要用心的地方，因为在用户量的增大情况下，我们需要对系统进行维护，对服务器进行维护，达到我们的软件可以安心使用的地步，并且也要及时从用户那边得到反馈，更好的去实现维护阶段。