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

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

经验总结我在团队博客的总结中写了非常多，这里直接将那部分搬过来

这里谈谈我对团队以及担任PM的一些内容。虽然说在老师对PM描述里，PM做的代码工作是比较少的，更多工作是管理类，但就我们团队以及我观察到其他的团队来看，其实PM的技术工作量与其他同学都是差不多的，另外还要去通常承担许多写博客、答辩之类的文书工作，所以花的时间实际上是团队里最多的。当然可能其他的团队结构不是这样，比如博客由另外的同学写，答辩由另外的同学负责，这样看似会更合理，但我并不是这么认为的。其实我并没有想抱怨PM做的工作会比其他同学更多，恰恰相反我觉得PM理应会做更多的工作，首先编码是必要的，也许在功能上PM做的是一个小的功能，但很多时候还需要去处理组员提交的代码因合并产生的BUG、去和组员沟通询问，再自己学一些东西，配合组员一起解决这个BUG。所以这方面的编码占的比PM自己负责的部分要多。这样我们也可以看出一个事实，那就是实际上PM是整个组里最了解项目的人，哪个模块做的如何都心里有数，所以由PM来做报告、答辩其实是最好的，对于整个项目的介绍会更全面细致，面对答辩也更易于回答质疑，所以这就产生了更多的工作量。所以我在想，探寻团队的分工合理性上是不是应该再降低PM的编码工作，因为即使将PM的工作再分配一部分到某个或某几个组员身上，最终PM仍会需要去了解这个地方的代码，这个工作的调配不是简单的加减关系，也许减掉PM50%的代码任务本意是减掉PM身上50%的代码工作，但最终可能会只减掉15%。所以分工问题对于一个团队提高效率工作来说是可以再深入研究的点。

然后再说说关于Beta阶段换人的想法。在Beta的答辩时老师问到我，换人觉得怎么样。那时候我不假思索的答：应该换。但事后我认真考虑了一下其实不对，不应该换，或者说应该凭自愿的原则来换，尽管可能最终是没有团队换人的。那个时候我答应该换主要是换来我们组的陈裕鹏同学确实是很优秀，他在一个晚上的时间里搭建好了安卓的编译环境，并且通过基础的安卓教材快速上手了我们的项目，差不多第二天就基本完成了我分配给他的一个简单任务，而且在之后协助我们解决了许多疑难杂症。而此前他所做的完全与安卓无关，他本人在之前也没有任何开发JAVA的经验。所以能有比较不错的换人效果其实主要得益于他本人的编程功底扎实，能快速融入团队。但是想一想，并不是所有的同学都能像裕鹏这样厉害，可以在一个晚上就马上上手新项目，适应完全不同的编译环境与团队。对于一个水平一般的同学，如果被换了，假如是安卓换安卓或者IOS换IOS还好说，要是安卓换WEB之类的，而又仅有一周多的时间来完成任务，这里面恐怕六七天都要花在学习新的语言、看前人的代码上，我不否认工作中会有这样的情形，但对于课堂而言，这种情况可能导致这位同学在原本的团队有稳定的贡献量，换了以后贡献量大幅度降低，对新的团队造成大问题，对他本人而言最现实的就是分数下降，而没有被换的同学就不用担心这个问题，带来的最直接的影响就是不公平，被换的同学要花更多时间，却很难拿到合适的分数，与走上社会的情况不同的是，社会存在不公平可以理解，但课堂不应存在，对于有评分数的课堂更是如此，如果要换，那就应该全部团队打散，保证每个人换到自己不适应或适应的环境下继续开发，这样也许反而能体现哪些同学更优秀，可以更快融入环境，而不是仅仅换一个同学，我觉得不合适。就像临近考试，老师突然跟几个同学说，你们几个的知识点改一下，卷子和其他同学的不一样，会更难一点，但是统一评分一样。以上是我经过认真考虑后的一些想法。

最后谈谈我们的项目，虽然到现在结束，项目个人觉得还是差强人意，一些日常软件必要的东西仍然未完成，主要还是技术问题，我们还不够强，学习的速度还不够快，这是一个遗憾，但我们会在接下来的时间里去继续完善我们的APP，阿里八八项目组也不会解散，我想我们也许会用接下来的寒假、周末、暑假去打造我们的第一个产品，不留遗憾。

对于结对项目的补充

我对于结对第二次的突发布置一直是怨念极深的，因为很大程度打乱了我早已定好的安排，而且最后结对的任务也做的不好。但是我又挺认可老师的一个说法，未来的工作中很可能就有你假期已经排好了工作然后突然布置任务下来的事，所以如何应对确实是一个问题，所以我最后也是选择接受。

关于有什么经验能总结，我觉得可以从结对合作来谈。我的结对队友是杜宏庆同学，此前我们是完全不认识的，一点交流也没有过，因为结对在群上寻找队友就沟通了一下一起完成任务。这里可以结合之后团队项目的感受来对比一下，其实结对需要去照顾对方想法的地方是要比团队里八个人更多的。因为一个八人的团队，每个人面对七名之多的队友，在很多想法上会去更多的妥协团队的需求，而结对上一对一就不那么容易，比如说我原本想我们出来工作，都带电脑一起做，但是杜同学的笔记本键盘坏了需要再带外置键盘，不方便，于是我们就改成我带笔记本，由我主要来做原型设计，他和我交流来写部分文档等，回去后他再完成他的部分。但是这样最终的配合效果是很差的，他负责的部分发给我后发现很多需要添加关联的地方都不对，页面也不能对接，所以许多地方我再进行了重做，这样的配合不但没有减少时间，反而花了两人更多的时间，所以我觉得可以得到教训的一点是结对工作，核心的工作部分应该放在两人在一起工作的时候来做，而一些次要工作再放到单人工作时完成。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。特别地，特别地，下一届要不要中途换队员？

我发自真心的要对学弟学妹们说，如果你以后打算从事计算机方面的工作，请一定要认真对待软工实践（本来想说一定要选，但听说这门课将改成必修了），除非你毕业后不打算从事本专业工作或者想做硬件方面。

因为软工实践这门课它确实很棒，棒在它将你开发软件的每一阶段要做什么都规划好了，让你可以知道从何入手，但又没有限制你的自由程度，你的团队可以自由选择开发模型，选择做什么东西，选择安卓还是IOS还是WEB。如果你自己自学开发一门软件，很可能不知道从何入手，先做什么，然后做什么，就知道开发安卓要下个Andriod Studio，然后盲目的写代码，最后，一个完工的产品存在很多可能并不是BUG的问题而没人使用，比如需求分析没做好，没有解决用户痛点，又比软件的界面不友好，文档又没写清楚，用户用不下去，然后你又得重头去做需求分析，和用户沟通，一切返工重来。但经过软工实践的一套系统训练后，你对于怎么做一个软件一定会有一个很清晰的认识。你可能觉得软工实践这么点学分却浪费了你巨量的实践，但可以肯定的是你如果打算在未来的工作中去跟随团队学软工实践或者像上面说的自学，你将花费可能不止成倍的更多时间，并且其中大部分将浪费掉。因为你的同事、上司不会像老师、助教那样耐心的回答你的问题、指点你这个阶段做什么，甚至是被抱怨、指责仍会向你解释某个做法的原因是什么，这样做对你的经历有什么好处。

所以，请好好对待软工实践，这是为了你自己。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？

构建之法上将团队分为：萌芽阶段——磨合阶段——规范阶段——创造阶段，应该说我们组每个阶段都经历过了，最终也达到了创造阶段，尽管创造阶段的最终结果并不是很出众，但我们也在传统的概念上开发出了新的东西，并且提出的创意也仍在实施当中。我的团队要说有什么特点，应该就是没有特点，在萌芽阶段，大家都不太熟悉，而且确立选题时尽管选了安卓，但实际上每一个人有一点安卓的开发经验，甚至是JAVA的经验，于是一切都是真正意义上的从零开始。而我为大家所信任推选为了PM，可以说是压力十分大。因为我不仅是没有开发经验，也并不是在其他方面比较强的编程大佬，但我还是担起了这个责任，按部就班的将每一次任务分配下去，参考同学们的编程能力、性格特点等尽量去分配任务，这个过程让我也学到了很多东西。但正因为这样没有特色的一个团队，大家可以平等的讨论问题，一起去探索未知的知识，然后在集体编程时互相帮忙解决问题，共同进步。所以尽管我们没能创造出一个很优秀的产品，但我觉得我们已经突破了我们的能力去完成了一个足够好的产品，真的感谢我的团队每一位同学，让我有了一次这么棒的体验。

五、怎样证明你学会了软件工程？

1）研发出符合用户需求的软件

已在团队项目中公开发布团队项目“好记”APP，目前仍在寻找用户进行试用中。但目前这个软件并不能说做完，因为核心功能部分还有问题在解决中，所以不能代表“完成后”的用户量。

2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件

1、确实做到团队配合的分工合作

在Github的commit记录中可以清楚的看到我们每个人每天的的记录，我作为PM对每个同学都分配了适合他们能力、风格的工作，并且最终的成效来看，分配是合理的，没有出现某个人的工作实在无法完成、某个人做了过多的工作等情况（截图为每隔一段时间的节选，具体可到阿里八八好记Github开发分支的dev分支下查看commit记录）

……

……

……