一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
最早的博客初入软工实践中我提到，我对于软工课程的期待就是做一款自己的软件，可以运行可以使用的软件，先把结果放到一边，我觉得软工给我带来的收获已经基本达到了我的期待。说实话虽然怀抱的理想很美好，但我其实并没有很自信真的可以在一学期的实践课里就掌握做出一个软件的能力，尤其是半路出道的我在编码能力上相比其他许多同学都薄弱许多，所以我对自己期望没有很高，然而这个过程：被选为PM、组织团队开发、撰写文档、参与答辩，却让我觉得渐渐开始有信心去做更多事，去做得更好。就在刚开始当PM时，我都仍然怀疑自己是否真的可以胜任一个技术团队的领导者，在自己技术都不怎么样的情况下，而现在我已经可以比较自信的站在讲台上给同学们讲述我的团队是怎么做怎么做的，虽然我们这个地方还做的不够好，但我们仍在努力攻克。事实证明计算机的学习真的需要“Learning by doing”，如果只是看书、自己偶尔写些简单的代码，进步是很困难的，而我恰好好运的得到了栋哥给的契机，逼迫自己去做了这件一直都比较畏惧的事，如今才克服了这种自卑。
当然，正如前面所说，一学期的一门实践课不能改变太多的事，我仍是存在很多的不足，但我觉得这些不足只是在经验与技术上的了，需要我个人去完成更多实践，学习更多东西，积累更多经验，而思想上已经成功战胜了自己，有了一个明晰的目标。
这里再悄悄说个秘密，其实刚开始上课听栋哥介绍的时候，我是想退选的，但后来发现实验班是必修课，只能硬着头皮上了。然而今天想起来庆幸我进了实验班，碰上了必修的软工实践，才真正开启了我的计算机人生，否则不知道我还要抱着一个空洞的理想迷茫多久。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
零散的统计比较困难，粗略估计了一下大约1811行（看似很多，其实主要是多级按钮占了1000多行）
2、软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业 | 所用时间(小时) |
|---|---|
| 第一次个人作业：对计算机的思考 | 3 |
| 第二次个人作业：数独 | 23 |
| 第一次结对作业：匹配系统需求分析 | 7 |
| 团队第一次作业：团队展示 | 4 |
| 结对第二次作业：匹配系统 | 15 |
| 团队作业：选题报告 | 6 |
| 个人作业：技术博客 | 1 |
| 团队作业：需求规格说明书 | 12 |
| 团队作业：预则立——他山之石 | 6 |
| 团队作业：系统设计 | 7 |
| 团队作业：UML设计 | 2 |
| 团队作业：随堂小测 | 5 |
| 个人作业：软件产品案例分析 | 5 |
| Alpha阶段及课堂展示 | 28 |
| Alpha阶段团队项目测试报告与用户反馈 | 3 |
| Alpha阶段事后诸葛亮 | 4 |
| Beta阶段及课堂展示 | 26 |
| 团队作业：项目验收与总结博客 | 2 |
| 个人作业：软件工程实践总结 | 3 |
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
大约162个小时，按十周，即半个学期做软工来算，平均一周有16.2个小时。
5、学习和使用的新软件；
编程类：
①Android Studio 3.0（强烈建议使用2.3）
②Visual Studio
办公类：
①MarkdownPad
②AdobeAcrobat
6、学习和使用的新工具；
视频类
①Fraps
制图类
①Visio的UML绘制
②Axure rp原型绘制工具
③Ulead GIF Animator
7、学习和掌握的新语言、新平台；
语言：
①JAVA
②XML
③HTML+JAVA SCRIPT
平台：
①Github
②华为软件开发云
8、学习和掌握的新方法；
①需求分析
②软件开发模型：瀑布模型、增量模型等（我们团队使用的是增量模型）
③Scrum
④极限编程
⑤敏捷开发
9、其他方面的提升。
①答辩能力：承担了几乎一个学期的所有答辩，明显上台后的自信程度、口齿清晰程度都有很大提升，相信对于以后步入社会会有很大帮助。
②团队管理能力：虽然此前经常担任班干部之类的管理者角色，但领导一个技术团队，而且团队中大部分人都比我实力要强还是第一次，将这个团队凝结在一起，和谐高效的完成项目给了我很多对于管理经验上的启发。
③交际能力：作为PM需要经常去与队员、试用产品的用户沟通，以及Beta阶段后的换人，去向其他的PM推销组员，与想要入组的同学交流等等，让我的交际沟通能力有很大提升。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
经验总结我在团队博客的总结中写了非常多，这里直接将那部分搬过来
这里谈谈我对团队以及担任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记录）
……
……
……
2、附上我们开发的燃尽图
可以看到每个阶段做的工作都有个阶段性的完成趋势，可以证明我们在时间内尽我们所能的已经完成了一个“足够好”的软件
3）通过数据展现软件是可以维护和继续发展的。
1、源码可查看，APK安装包可使用
阿里八八好记Github产品分支
Haoji文件夹内是我们的所有源码，可在Android Studio3.0下编译，内含的APK安装包可适配4.0以上的系统