团队项目个人感想：
在这个学期的软工课上，我们Chronos团队精诚团结，在两个阶段中始终各个成员全力以赴，不离不弃，虽然期间也会有矛盾也会有争吵但是大家都能做到一切为了团队，以团队利益为先。
在我们的团队中，可能我的基础相对薄弱一点，无论是从学习成绩上还是从编码能力上，我还记得在第一次的团队会议中，大家对于项目的安排进行集思广益，而我却大脑一片空白，看着大家侃侃而谈只能在一旁默不作声，尽力找出有没有什么能够插话的地方。记得那个时候我心里想的也很简单，我一定不能给这个团队拖后腿，一定要尽量为团队做出贡献。
之后的M1阶段，在前期大家对于项目还很不了解的时候，前期我主动地去做了一些工作，记得那个时候我的出发点也很简单，一方面我感觉这些工作我力所能及，我就主动地去完成一些了，另外就是因为头一次学习安卓开发，之前觉得写一个APP是一件很高大上的事，当自己实际去操作，即使是一些很小的效果如果能够在自己的手机上调试通过，也会觉得很有成就感，就是这份成就感让自己很想要再做一些别的事情。所以在整个M1阶段，我的工作热情还挺高涨的，期间我们的团队经历过一次项目的整体变更，之后就开始了用AS开发，最大的一个麻烦就是漫长的编译时间，记得最艰难的那段时间，五个人挤在宿舍里从一睁眼开始就写代码，然后叫个外卖开始吃，吃完了就继续写代码，当时感觉生活简直是一团乱麻，给我妈妈打电话说当初真的不该来学这个专业，活的就像是在黑网吧里生活的那种网瘾少年每天对着电脑傻坐着。
在M1阶段的展示环节，我感觉我们的效果不是很好，很多花了大气力去实现效果都没有展示出来，成员们有些灰心丧气，因为那天我承担着给别的团队打分的任务而他们有课走得比较早，所以我是唯一一个听过了所有团队的展示的人，我当时就觉得我们团队的人员配置比较均衡稳定，大家也都肯干活但是对于项目的整体规划上欠缺一些全局的考虑，我在展示结束后向罗杰老师咨询了很多意见，我们团队在M2阶段充分结合了这些宝贵意见，可以说是更加科学更加合理地进行了任务分配等方面的调整，面貌焕然一新。
然而我们也遇到了很严峻的考验——临近期末，各种大作业，各种测试，各种论文，编译每周两次的测试让我们心力交瘁。尤其是我个人而言，我因为前期对编译测试做得不够，导致因为一个点上存在疏漏使得前两次编译的测试以及补测都没有通过，人生中头一次面临着要挂科的风险，当时一度对生活一点希望都没有，坐在楼梯间里面掩面痛哭，觉得活着真难。
与此同时团队项目那边，IM迟迟取得不了进展，自己几个晚上调到凌晨四点，我觉得我已经很努力了，但是它就是会出现这样那样的问题，而我因为不懂原理，只是参考了别的一些框架，没办法去探索背后的问题所在，再改或者完全自己去实现也根本不现实。有一段时间真的是不想干了，但是看到团队中的所有人都没有因为别的一些事情推三阻四玩消失。看着林狗感冒发烧咳嗽不停，也还在写代码，看着康家华每天对着电脑调调补补，拿着笔在纸上把设计稿改了又改，实在是觉得不能那么不负责任。记得那是跨年的夜晚，我调Bug调到了两三点，但是还是存在一个很严重的问题，当时给PM发qq说自己真的觉得即时通讯这部分搞不定，然后接下来的一天，PM就帮我和狗东一起调了一整天IM，解决了好多问题，但是很蛋疼的是又出了新的问题，因为当时真的是要发布了，没办法我们就只能砍掉这部分的功能。
所以这么看来，在M2阶段其实我什么贡献也没做，因为努力了半天的模块最后也没能搞定，在这一点上我觉得特别对不起团队的其他成员，所以在展示前夕，我对整个展示博客的内容进行了认真的思考与设计，把展示的流程进行了精心规划， 把每部分的内容都进行了设计。因为前一天晚上写编译的课程文档熬了通宵七点才睡，所以内天晚上熬到一点多实在是困得不行，就叫他们两点叫醒我，之后就开始搞这部分的内容，把之前列好的提纲里面填充上实际要进行的展示的内容，翻阅之前的各篇博客摘取信息，不断充实完善，等到全部搞定已经又到了七点多，把一些需要别的成员填写的内容qq发送给了他们，叫醒了睡得叫早的一位同学以后安心睡去。
最后的展示很成功，我们的PM演示的很成功，讲解也非常自信，在最后的总结中，他深情而真挚地感谢了我们的每位成员为这个团队做出的贡献，感觉眼里都有些晶莹的泪光，我们在台下听着也是感觉内心非常地有感触，在这个学期中，我们一起克服了一个又一个的困难， 虽然最后做出的APP离我们真正要达到的效果还存在距离，但是我们都非常感谢彼此的陪伴与扶持，让这个团队一步一个脚印地走到了最后！
再看阅读作业
之前提问的链接如下：http://www.cnblogs.com/xixibaba/p/4828805.html
之前的问题也不敢说完全解决，只能结合这个学期的开发经历谈谈体会：
1.团队模式是否应该与具体项目相适应调整
在构建执法原书中提到了包括有明星模式、社区模式、业余剧团模式等几种软件团队的模式。其实就我们团队而言，在初期我个人认为比较类似主治医师模式，但是因为团队内部的成员都没有过类似工作的开发经验，我们的PM学习能力较强，但是得工作形势基本上就是他对下一步要做的几个工作先进行尝试，提供一定的参照，然后我们的其他人员在这个基础上进行不断丰富，当然也是要结合一些具体的特异的文档资料。而在之后的阶段我们就开始转向“交响乐模式”。由于队员们都有了之前的知识储备与一定的基础，所以在布置好工作之后我们自由发挥即可。
其实从这种模式中可以看出，因为人都是利己主义的，所以一个明智的团队一定会结合具体情况进行调整，这种调整不只是基于具体项目，也与团队成员的个人情况有关。
2.结对编程中，二人所长不同，单纯采取交替执行“驾驶/领航”的工作方式是否影响效率
其实这个学期里面真正的结对编程是在团队项目中才头一次体验到，因为结对项目基本上可以说是我自己写的，所以那个过程中对这个任务没有什么领悟。而在团队项目中，我和另一位同学有一段时间一起在一起调即时通讯的功能，内段时间里我们也没有说一个具体的模式，基本上就是轮着来，一个人累了就休息会帮另一个人看着、想想逻辑上有没有什么错误，另一个人在那写代码。坦率地讲，我感觉这种模式比较适合与一个人教另一个人，比如说熟悉一项技术，最直接的方法就是A给B先演示，B在旁边学习，而之后由B进行操作A进行指导与监督。好处主要是在于效率的提升上，能够从很大程度上避免拖延症。也就是说，效率的高低往往建立在二者的水平差距上，而非所长上面。
不过某种意义上也可以这样理解，如果A在要做的事情上有所擅长，在花费一定时间对B进行技术指导之后，B可以分担A的压力，降低A的工作负荷，这样也称得上是提升了效率。所谓驾驶/领航模式在实际执行过程中很快就能平衡两个人的能力差距，提高效率，也会将所长所短这个概念进行弱化，还是具备很高的可执行性的。
3.敏捷流程各阶段的耗时比重是怎样的
敏捷流程实际包括的阶段主要有三步，第一步是找出积压的工作、第二步是决定当前需要完成那些、第三步是冲刺。显然，三者中，冲刺是会耗时最多的，但是在开发过程中我们能够深刻感受到前两部分内容的重要性同样不可忽视。起码在冲刺之前，我们需要在团队内部认真地对前两项内容进行讨论确定，这个过程绝对不能使马马虎虎地说说而已，大家不能有所隐瞒，一定要毫无保留地把真实情况反馈给进行决策的PM。
4.MSF的基本原则若无法同时满足，如何取舍
其实现在回过头来看，我觉得在团队内部，最为重要的是“各司其职，对项目共同负责”。可以说，在任何团队内部，人员的习惯、能力、风格都有所差异，这些其实都可以接受，真正不能接受的是他对这个团队毫无热情，不愿意付出辛苦努力。这一点相信从很多团队的精力上也能够体现出来，有些团队某些成员真的是什么事都不做，美其名曰说他们做做测试，但是相信大家也都明白所谓测试背后的意思是什么。这样的人在我看来真的不应该留在团队中，可能因为大家是同学需要顾忌情分，但是这无疑是与敏捷开发的原则相违背的。而其他的原则在实践过程中需要进行多方面的权衡进行取舍，那些基本的团队内部的事情其实在项目初期都可以有一个初步的预估，而其他的就与项目进程密切相关，难以一概而论。
5.PM只能有一个人吗？如果多人会有什么影响。
我们PM码力也很强，也很认真负责，所以只要是人靠谱，一个就够了。
6.如何依据实际情况修改spec
其实我相信老师之所以要刻意地将团队项目划分成为阿尔法阶段、贝塔阶段两个阶段，就是为了给我们留出充分的时间结合第一阶段的开发经历与具体情况，对于SPEC进行重新的修正定义，而进行修改的依据要考虑到项目的总体规划，现行的开发状态，包括像团队成员的个人情况（一些别的事务）。
7.如何在面临多个bug时进行先后抉择
助教老师之前也在评论中向我介绍过，为bug定义优先级这样的策略，这无疑是一种很好的方法，万事万物都存在轻重缓急，不能眉毛胡子一把抓。
一个新的问题：
我比较想要了解到，在实际的工作过程中，对于一些现有的开源项目，尤其是某些自己不太了解但是又不可或缺的部分，如果没有时间去完全学习这部分内容，那么在使用时需要有哪些规定，另外要与现有的项目进行耦合时，有没有什么方便快捷并且比较科学的审核及操作方式。
各个阶段学到的知识点：
需求/设计/实现/测试/发布/维护
需求：在前几次的开发项目中，对于需求应该说都有了比较明确的定义，真正完全自由发挥的就是后来的团队项目，在前期中我们采用了多种手段来确保项目需求的科学性，包括有问卷调查，场景模拟等，可以说前期的需求设计决定了整个项目的合理与否十分重要。自己深刻认识到了这一点。
设计：因为我们的团队项目中我是写后台的，所以设计工作跟我的关联并不大， 如果说直接相关的就是一些API的设计构思以及包括数据表的设计了。在这部分中，我们把数据库中学到的一些知识可以说是实际应用了一把，虽然之后又进行了数据库的课程设计，但是这部分的内容却是在软工课内首次实践的。
实现：
这部分就是开发过程中学习到的东西了，在结对项目中，我头一次学习使用了c#这门编程语言，因为听好多同学说这门语音简便易学好上手。之后就参照着微软官方的文档边学边写，不得不说，官方的文档就是学起来就是好，那次的结对项目在搭档国庆出去浪了六天的情况下能够独立完成，我还是很满意的。
另外就是团队项目了，这部分的内容因为是安卓开发，所以基本的一些安卓的机制都有了一定的了解，不敢说是深刻明白背后的原理，起码一些基本的用法还是掌握了的，有一点遗憾就是因为是在开发中学习，所以知识其实很零碎不系统，希望有时间了能够好好读一下安卓开发的书籍，完整了解一下背后的原理。
测试：测试的话，团队项目中头一次试着进行了单元测试，不过说心里话，我真的不知道为什么要写这些东西，完全可以在写好一个模块之后，在main函数里面实际调用运行一下，能够起到一样的效果，这样不是方便的多吗，给每一个测试再写一串代码不是很浪费时间吗，可能我的认识太肤浅了。
发布：之前对于发布一款APP的流程完全不熟悉，通过实际的发布了解到了整体的流程，可以说发布一款APP在审核上还是比较认真负责的，也很感谢这些平台所做的审核。
维护：其实这里也是，之前我还以为如果要对自己APP进行维护更新会是一件很麻烦的事情没想到其实只要重新上传一个APK然后重新审核一下就可以了，正是这样便捷而又能够对于发布的APP的质量有所筛选的制度使得大家开发更加无后顾之忧。
回头看文章新的体会：
之前我们看到过的那几篇文章，其实我们都能在我们的团队项目中找到影子，现在想来一个就是代码规范确实非常地重要，文章中提到的那些奇奇怪怪的论点真的是不足为信，总体上看都是一种自私不负责任的态度。
另一个印象比较深刻的就是大泥球了，我们团队项目中就有一段关于图片加载的“大泥球”，在好多地方都是原封不动地进行复制粘贴，而对于不同应用场景，其实加载的图片对于画质的要求大小等等都有所差别，这样不加调整的复制粘贴一方面使得代码很荣誉，另一方面代码的质量也很受影响。