个人作业——软件工程总结

软件工程总结

写在前面：

　　这篇文字，说是总结，其实更像是两个月来的心路历程。

 

M0阶段（团队开发开始之前）

　　在团队开发开始之前，我对它充满了期待。原因之一，是想拯救一下荒废了两年的自己，准备大干一场。其二，我发现上了大学之后，似乎每个人都失去了集体意识，身边的人都只是管好自己，世人皆路人，没有中学时代那种一群人向着一个方向使劲儿的感觉了。借此团队开发的机会，我想找到“同行者”。

        

M1阶段（暗黑篇）

　　说到这一个月，我简直是负能量爆棚。好在后面心境明朗了许多，就算是为M2的柳暗花明做铺垫吧。这四周的阴霾，也有它存在的意义。

　　团队做事，最需要的是齐心协力。没人上心的时候，更需要有一个人站出来带领其他人做。但我的团队，不存在领头羊，没有“大腿”。所以一直到最后10天，还是一点进展都没有，连IDE都没有确定要用什么。

　　下面的话，看起来可能是在标榜我自己，但我自知做的不够好，所以暂且当作是纪实。

　　我实在等不下去了，决定自己带着队员一起做。随后对android 开发进行了一些调研，确定了IDE，前后端分工，这就用去了2天，我们制订了剩余7天的粗略计划，便和两名队员着手“码”了。从未进行过android开发的我们，从零开始，到第九天，只做出了一个难看的界面，实现了本地闹钟、联网登录，注册功能。

　　本来就码力不足，期间还有一名主力因学院的事情缺席了，实际上只剩下我和另一名队员。那段时间我一直在心里抱怨队员都不干活，或者是答应了干活却一拖再拖，最后还是要我自己来完成。同时又恨自己不能让队员提起劲儿，不能用自己的热情感染队员，也不能强硬的要求队员完成任务。那时，我纠结的不能在纠结了。一直想着，都是同学，我给予充分的信任，会有人跟我一起奋斗的，即使结果不如意。

　　但最终，我还是失望了。我既没能做到带领队员共同完成任务，也没做到挑起“大腿”的重担，自己一人完成所有工作。

　　要说M1我学到了什么？除去android开发的一些基础知识，敏捷开发的工作模式和PM的重要性（通过我们队与其它队的对比看到的…），更重要的是，永远也别妄想叫醒那些装睡的人。

 

M2阶段（复活篇）

　　之前的自己一直在抱怨，跟自己抱怨，跟老师抱怨，跟同学抱怨。

　　直到另一个队的PM来找我谈了谈。他说，他们队也是没人干活，所有的事都要他一个人安排的特别妥当，队员才能照猫画虎，把任务抄一遍似的完成（当然，这有些夸张了）。但当看到他们100%的完成度和非常好的展示效果后，我才意识到，我们未完成的责任，不完全在队员。我本身的能力不足以带起整个队伍，而且心态也没有前面所提到的大神那样坦然，只是不停地抱怨，无奈的码着代码。所以我决定在M2调整心态，做全职PM，协调整个队伍做出点成就来吧。

　　让我看到希望的是，我们队交换来了一个能力不错的队员。所以在M2一开始，我就风风火火的组织开会制定计划，在github上建好团队项目，发布任务说明，与工程师协商短期内任务要求。于是第一部分的任务被我们的三名工程师认领了。我给予他们充分的信任，我们关系都非常好，我也相信他们的能力足以完成被细化后的任务。

　　到deadline那天，我单独去找每名队员，询问完成情况。得到的答案几乎一致，“没有做完，但是往后延两天，一定能做完。”我再次给予了信任。

　　两天后，两名工程师完成了自己的任务，另一名还是没做任何事情。但是考虑到我们的人手本身就不多，一人不完成就会拖慢整个队伍的进度。于是我尝试着催了一下进度。说实话，因为平时关系很好，“催命”这种事情，我还是很不想去做的。最好的状态，应该是队员保质保量完成任务，作为PM，我只需要看到开发平稳进行，最终能圆满结束就满足了。

　　而事实上却并不能如愿。我每次催进度，队员就会表现出很烦闷，表现出自己最近的忙碌或者劳累。

　　我知道队员不是故意拖进度，不是想偷懒打酱油，而是他们的心态出了问题。我认为，作为PM，不能只关心工作上的事情，更要考虑队员的心理状态。毕竟我们不是企业，我们是一个学生团体。在团队中应该有温情存在。

　　所以对于工作上的空白，我选择将其转交给其他队员并为他的额外付出记录一笔贡献分。当没有人愿意领任务的时候，我选择在完成自己的任务之余做一些力所能及的协助。但是我毕竟不是大神，想要解决一些问题，我也需要很高的学习成本。这导致我们没能在M2结束时完成任务，反而差了很多。

　　现在回想M1，那时我极端的认为软工课的开设存在极大的弊端。因为我们不能像企业约束员工那样约束自己的队员。但到了M2的中期，我才意识到，自己的关注点不应该在如何让队员感受到无穷的压力去工作，而应该尽可能让参与开发的队员都感受到团队的感染力。

　　所谓“团队感染力”，我是这样认为的。

　　往大了说，那叫企业文化。往小了说，可以是团队作风。我认为，在校园里组起来的团队，应该是不为名、不为利（不为分数），而是为了一个目标——做好我们的产品。想要做好产品，单纯靠利益诱惑，单纯靠分数的压迫力，是不行的。那样做出来的产品是不单纯的，是不包含感情的。

　　想要让团队有这样的感染力，必须是每个人都要付出真心，不仅要关心产品，更要关心队员之间的联系。只有队员之间彼此信任、彼此关心，这样才能产生所谓“走心”的化学反应，这样才有团队感染力。

　　我们做个人项目时，可以是为了自己。但团队项目，不仅仅是为了自己，更是为了队里的队员们，为了让他们放心，让他们看到自己在踏踏实实，一步一步的跟着团队的脚步前行。

　　这样的团队，才能做出单纯的、优秀的产品。

　　所以，我不希望让自己变成强势的“催命鬼”。而是要做团队的“催化剂”。付出真心去理解并帮助自己的队员，一定会换来队员们的万众一心。

　　虽然这次的团队项目我们没有做完，但是想到自己没有变成一个令人讨厌的，给人无穷压力的恶霸PM，而是尽了自己最大的努力，去理解队员的PM，便足矣了。

　　至此，分数于我，可能真的不重要了。

   

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

1、  PM究竟是做什么的？

　　关于PM是什么，以下是我的理解。其实与上面所述有重复内容。

　　首先要明确的是，PM不是领导。确切的说，我认为队内的所有职位都是平行的关系，不存在上下级。

　　PM应该作为团队的粘合剂，疏通队员之间的关系，了解每位队员的状态，每做一个决定，都需要与队员协商并将最终的协商结果告知每位队员。这样就需要PM对团队的现状有极强的把控力。

 

2、  更新daily scrum 有什么用？

　　我们自己会议记录，真的有必要发布出去让所有人都看到吗？在自己手上保留着，难道不可以吗？起初我有这样的疑惑。后来在经历了这两轮迭代后，我发现，不仅仅是老师在关注着我们，似乎还有很多专业人士都在注视着我们这些团队。每次更新博客，尤其是那些综合能力很强的队伍，他们的博客会被引用，会被很多人评论。

　　所以说，让那些关注我们的人，了解到我们的进展，是有意义的。

 

3、  开发软件难道不是只需要在deadline之前给出完整可用的产品就可以了吗，为何还需要定期开会，分前后端？

　　由于之前没有接触过真正的软件开发，一直是以大作业的形式进行编程。所以认为只要程序最后能跑出正确的结果就可以了，过程不重要。但当真正的将大作业提升到团队项目、工程的水准时，我才发现，之前的工作量与工程比起来完全不是一个数量级的。如果不合理分工，合理细化任务，合理划分功能模块，一旦出了BUG，想要调试简直就是天方夜谭。而且开发出来的软件，发布后，是需要定期更新和维护的。合理的划分功能区，有助于针对性的对软件进行维护和更新。不仅仅是前后端要分开，最好能按功能将项目分成若干个区域。

 

4、  敏捷开发需要工程师有各自的独立、完整的开发时间区域，但难免在开发过程中会出现与讨论不一致的细节问题。如果自行解决，有可能会与其他工程师不一致，这样在对接的时候就会出现难以预料的困难。敏捷开发虽然将理想的开发时间复杂度降低，却有将实际开发时间增长若干倍的风险。如此大风险的开发模式真的有必要吗？

 　　我依然没能找到在敏捷开发过程中，与预定目标不一致时该如何解决的方法。但我对敏捷开发有了一些粗浅的理解。在我看来，最理想的团队开发状态，是团队聚在一起，集中工作，有问题了就立刻解决。但之所以将其称为“理想状态”，就是因为实际上很难有集中工作的机会。敏捷开发，是一种折中的办法，不至于像流水线似的，只有一个人完成其余人才能接着工作，又不要求所有人同时开发。也算是一种无奈中的最优解吧。

 

5、  在学校这种以学术交流为主的背景下，将企业中软件工程的团队开发模式移植过来，真的可以吗？

　　起初我认为简单的移植是存在极大问题的，因为学生对学生是没有约束力的。只有队员自觉工作，或者本身对软件开发充满热情，工作才可以顺利进行。一旦出现团队整体消极怠工的状态，最终的结果很可能是完不成任务。

　　但以上所说的状况毕竟是极少数。如果10支团队中，9支团队都顺利完成，只有一支队伍出现上述情况，并不能说明这门课程不合理。就像大学里其它课程要求及格率、优秀率一样。有优秀的，就一定有相对来说差一些的。

　　只是我建议以后的软工分组，可以考虑一下团队的平均水平，最好不要出现整队人的水平都较低的情况。

 

在“需求/设计/实现/测试/发布/维护”阶段，我学到了什么：

1、 需求：要考虑开发团队本身的需求，比如开发工具的选取，要平衡开发复杂度和队员对工具的熟悉程度。

2、 设计：此阶段实际上是要解决用户的需求问题。在了解用户需求后，设计出能满足相应需求的功能。此时，需要考虑优先级的问题。比如在一个android平台的计算器软件的设计上，基本运算的设计要优于复杂运算的设计。因为要完成复杂运算，用户可能更愿意使用专业的计算器，而不是一个简单的手机应用。

3、 实现：设计完成后，要实现设计好的功能。要考虑实现难度的问题。在发布任务时，要评估任务的难度，并且给出要求完成的期限。

4、 测试：之前很不重视测试，因为感觉软件拿到手上用一用就知道有没有问题了。但对于一个开发团队来说，这样既不专业，也非常不负责任。对用户不负责，更是对自己所做的产品不负责。

5、 发布：在这一阶段，我发现国内一些发布平台会有虚假的下载量统计。这可能是为了吸引开发团队到其发布平台发布产品而做的自动刷下载量的脚本。所以千万不能因为看到自己的软件被下载了很多就沾沾自喜，因为那很可能是虚假统计数据。想要看真实的用户量，必须看活跃设备统计。如果活跃设备统计一直是零，那么恭喜，我们软件根本没人愿意用。

6、 维护：没有进入维护阶段…所以也不知道应该怎么做。但我感觉，维护阶段是需要用户量基础的，有用户反馈问题，才能做好维护。