【个人阅读】软件工程M1/M2阶段总结

这是老师很久之前布置的一个作业，由于学业匆忙以致差点忘记了这个作业。因此在数据库考试的前夜忙里偷闲，抽出一点时间来完成这个作业，也藉此希望我明天的数据库考试顺利……

==========================UPDATE==========================

我猜想明年可能会有学弟学妹来翻看我的博客，为了给他们一些【指导】，我特地将我在火车上写的、并在微博上@了邹欣老师的话贴过来。肺腑之语，唯望细观！

我在回家之前看到了我们软工M2阶段的得分，现在我坐在火车上，我都没有一个好心情。有些话，真是不说不快。

这门软工课从团队项目开始到现在，除去中间大家为大作业忙碌的时间，我们团队可以说剩下的时间基本都用在了软工上。我还记得我们多少个凌晨5点还在群里讨 论的日子，多少个夜晚组员都没有睡觉，甚至跨年夜我们还在做软工的那些过往。。。即使是经历了这么多艰辛，我也从来没有后悔选了移植学霸网站这个坑爹项 目。我只是感谢整个hots团队，感谢剩下的3组学霸团队。因为有了大家的共同努力，这个项目才能做成。因此即使是任务艰辛，我们也能苦中作乐。甚至到现 在，我们组员还打算假期回去为学弟学妹写一个完整的接口文档。可以说，软工这门课，我们对自己是问心无愧，对学弟学妹是仁至义尽。

由于我们的项目是指定的移植项目，因此留给我们自己发挥的空间其实很少。当初交给我们项目之时，说是要实现用户管理，问答，上传/下载，搜索，但其实这些 功能有些（上传下载，搜索）连学霸网站都没有实现，我们又何谈移植？更别说已经实现的功能里的假功能等等。因此Alpha阶段我们做的很艰辛，Alpha 阶段结束后，我们学霸app比学霸网站实现的功能还要多，这些我想老师们都已经了解了，因此在M2阶段的展示上并没有再次解释，但事实上似乎只有罗杰老师 了解这个情况，其他评审并不知情。因此老师给我们提出没有针对移动端的特色做一些比如语音提问或者图片提问的建议，我认为其实很牵强。我们做的是移植工 作，可以说需要最大限度上保持和学霸网站的一致，学霸网站都没有实现的内容，我们如何实现？一个插入图片并不是说说那么简单，需要进行数据库的修改，这需 要我们两组甚至三组协商一致（我们是共用一个数据库的），又怎么能我们一组决定？况且问题本来就需要详细的语言描述，我们还认为现有的接口的传输长度有限 制是一个需要修改的问题呢，老师们竟然认为移动端应该描述的简洁一些？！试问现在的主流提问app「知乎」，「百度知道」等，哪一个支持语音提问？其实移 动端更大的功用是给用户提供浏览和查找功能，就像知乎上要想详细地回答一个问题，基本都需要在网页端做二次编辑。我们本来需求分析时也没指望用户能在 app上详尽地回答一个问题，因此在M2阶段给用户增加了修改提问，修改回答，删除回答和采纳答案的功能，再配合点赞，可以更好的完善这个问答系统。而这 些，都是原有的学霸网站没有实现的，也是我们在M2阶段才加入的。但尽管如此，我在当场还是接受了老师的建议，并愿意把这个功能留给下一级接手我们项目的 人去实现。我们的项目本来就是一个需要多轮迭代的敏捷开发项目，学霸网站历经三届多组人多次迭代，也只做成现在这样，老师又为什么对我们要求颇高呢？本来 我们已经将遗留bug，beta阶段的修复bug，beta阶段扩充的功能，期望下次迭代实现的功能都写在博客里，但是老师并没有让我们展示。

至于下载量小，是因为我们并没有像其他组一样去刷下载量，下载了多少就是多少。我们在豌豆荚，微博，校内网站上都做了推广，甚至两次发布邹欣老师都转了我 们的微博。这是不是可以说明邹欣老师的影响力就是如此，或者学霸的吸引力并不如期望的那么大，那么学霸还有继续迭代下去的必要吗？

老师给出的所有建议中，我最不能接受的就是老师所谓的态度问题。我衷心的希望这并不是我们组扣分的理由。我不知道老师怎么看出我的心理防御，其实我对老师毫无抵触，只是认为在和老师平等地讨论学术问题而已，就像现在我写了这篇微博并敢@邹欣老师。 面对老师有些质疑点时，我态度坚决地反对。一方面是因为我对我们团队工作情况的了解和自信，试问一个开发人员如果对自己开发的项目都不自信，那他凭借什么 去鼓舞自己继续开发？我的自信并不是对自己的自信，我也不觉得自己开发能力最强，我也不是团队中工作量最大的那个人，我的自信是出于对我们的团队的了解和 对团队的自信。而敢于反驳的另一方面，是出于对老师的容人之量的信任，我相信老师并不会因为学生和自己意见不同就扣分。但是事实却让我大跌眼镜，且不说吴 际老师有没有故意刁难，既然老师都觉得自己没有刻意针对学生，那又为什么觉得我是刻意针对老师呢？事实上，对于我们的不足，我都坦诚的承认了，比如我们没 有嵌入统计活动用户的模块，压力测试的报告分析不详尽，移动端还有待优化等等。但是，对于我们做的好的地方，我为什么要容忍质疑不能反驳呢？老师为什么忽 略这一点？我在大学三年，经历过无数次答辩，面对过若干次质疑，也都反驳了回去，还从未见过老师因此而对我有偏见。事实上，答辩归来我都承受着很大的压 力，组员怪我对老师态度不够友好。我一直告诉他们这不会有什么影响，所以今天看到成绩我真的很难过。即使到现在，我还是愿意相信这不是我们扣分的理由，我 不希望是我的个人原因而影响了大家。

说了这么多，其实就是因为我不能接受我们组的得分并不是最高。我也并不是针对sixsix，但是我们的课程是软件工程，不是软件编程。据我所知，他们的项 目基本由一个人完成，那团队项目体现在何处？我可以自信的说，我们团队是8个小队之中分工最好，对敏捷开发执行的最好的小组。我们没有冗余人员，并且人尽 其用，针对每个人的能力分配了不同的工作。并通过责任划分，包命名，降低功能耦合的方式提高团队整合效率，这和一个人的工作完全不同。这些我们都在 Alpha阶段做了解释，不知道Beta的汇报上老师们是否知情。而对于我们组的每个考核点：能否利用前两组的数据，有什么卓越的UI设计，用户数量和活 跃用户数量，搜索的准确性和压力测试，我们也都给老师做了说明或展示，尤其是软件工程颇为看重的测试，我们也用了大量篇幅介绍。我不知道我们是有什么地方 做的不完备？其他问题我在上文已经说了，如果学霸项目潜力确实如此，那我们也无能为力。我完全可以接受sixsix中能力突出者个人得分非常高，但是我不 能接受他们团队胜于我们团队。其实我感到更不值的是ourteam团队，他们负责学霸网站的迭代，我们和他们一起共事，非常清楚他们的贡献，可是他们竟然 是学霸4组里得分最低的。他们修复了很多学霸网站原来的假功能，并实现了很多新功能。当然这不是他们最大的贡献，他们最大的贡献是对数据库进行了修改（我 们组也有少量参与），为数据库增加了外码约束并添加了很多触发器和存储过程，使得数据库逻辑上非常完备，大大降低程序复杂度。并且他们提供了所有的 webservice接口留给下一届使用，本来我们组想在M2阶段全部更换他们的接口的，但考虑到代价太大并且我们有一些自己的新增功能，因此放弃了这个 打算，我们亦在博客中提出了这个期望。可以说，他们组对后人的贡献是卓越性的，这些都是历经了两年的迭代的前人都没有做到的。我们两组之所以这么做，都是 因为我们被学长的烂尾项目坑的不浅。因此，我们对学弟学妹真是仁至义尽。然而，做的这么多却没有得到老师的肯定，真是可悲又可笑！还记得当初我们去向学长 取经，学长对我们爱搭不理、一问三不知，并且「传授」我们只要最后说的好就行。后来看了学长的代码并看到了今天的成绩，我才彻底相信学长所言不虚，诚不欺 我。我还记得答辩的最后，有一个老师问我我是不是pm，因为我对代码的技术细节知道的十分详细。他便问我为什么我比pm知道的还清楚。我回答说，因为我是 开发人员，我当然知道这些。我还记得邹欣老师《构建之法》里对pm的描述：团队里唯一不接触代码的人。因此这不由地使我对老师的专业性产生了怀疑。不能接 受观点差异，似乎对软件工程不那么专业，现在我也不奇怪学长的那种项目是怎么从老师那里通过并得到高分的了！

——写于Z43火车上

==========================UPDATE OVER==========================

1.链接到以前提问题的博客

http://www.cnblogs.com/yi1994324/p/4020490.html
http://www.cnblogs.com/yi1994324/p/4090680.html

2.请说明哪些问题现在自己已经清楚了，请阐明一下，是如何通过看书，实践，或者讨论弄清楚的

已经清楚的问题：

1.PM不熟悉现阶段项目用到的技术，无法准确控制开发的时间和进度，Dev Leader懂技术懂代码但是队员的水平参差不齐，有些事情只有Leader能解决，这时候该怎么办？

我当时的答案：

我认为这时候解决问题的最好方法是Leader在对项目工程进行一些问题修复的时候让全队旁观，相当于每次的工作都是一次教学，毕竟大家的磨合才能使团队进步。如果水平的不足是既定的事实了，那么只好寻找方法去弥补。

现在的思考：

这个问题是我们在开发阶段中切实遇到的一个问题。我们开始企图让PM为我们安排进度，后来发现别说是PM，就算是DEV自己有时候都可能对自己的开发进度出现估计失误。在实践的过程中，我们采用这样的方法：首先由一个对Android开发较了解的DEV搭建整个系统的框架，然后我们对任务进行大的分割，在这个分割过程中充分发挥敏捷开发的特点，使得每个人负责的功能间的耦合性很低。在分割的过程中也充分考虑到队员间的能力差距和个人意愿，使得每个人承担的任务基本和其能力及兴趣相符。在接下来的开发过程中，PM不对详细的开发过程时间设限，只给出一个大体的规划时间，例如周一前完成大功能1，周五前完成大功能2，而对于详细子模块的时间安排，则由DEV在每日例会中交流讨论，得到一个大体的时间规划并上报PM。在讨论的过程中，有经验的DEV可以给出指导，依据经验调整时间安排。而PM则在这个过程中收集整合队员们上报的时间安排，并按照这个Deadline去监督DEV们的工作。

2.如果团队里遇到了技术很牛但是合作精神逐渐才发现很糟糕的人该怎么办。如果此时找不到任何能接替他的技术人员了，是放弃他还是放弃项目？

现在的思考：

我们队伍中确实有这样一个类似的人，但是他并不是合作精神很糟糕，只是很乐于全部由自己完成自己的部分(可能这样做更放心吧！)。他所完成的部分我们确实都不了解，于是问题来了：在BETA阶段这个同学好像突然从项目里消失了一样= =当然放弃项目肯定是不可能的，我们也只好先放弃他的这部分了……

3.哪些问题还不明白，请分析

还是上面的那个问题，如果团队里遇到了技术很牛但是合作精神逐渐才发现很糟糕的人该怎么办。如果此时找不到任何能接替他的技术人员了，是放弃他还是放弃项目？

我们现在能做的就是对这个人给予充分的信任（他也确实很靠谱），希望他可以完成自己的任务。但是如果现实中真的遇到这样的情况，那一般会怎么选择？

4.产生了哪些新的问题，请提出

1.PM这个职位是本来就固有的还是从程序员转上去的？

2.敏捷开发和瀑布模型到底哪一个更实用？

3.老师究竟是怎么能让学长那样的项目通过的？？

5.同时我们还读了8篇软件工程相关的论文或博客，你回头再看看这些文章，有没有新的体会

按照软件工程方法操作的团队，反而不及一个人单打独斗的团队，我还有什么说的呢？

6.请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么 “知识点”， 每个阶段只要说明一个知识点就可以。

需求：如何使用NABCD模型进行需求分析

设计：对估计的练习和分而治之

实现：基本实践了MSF基本准则（尤其是为共同的远景而工作、充分授权和信任、各司其职，对项目共同负责、保持敏捷，预期和适应变化）

测试：黑盒测试和白盒测试

发布：如何进行用户推广以及事后诸葛亮会议

维护：还未进入维护阶段