一、总结体会
团队项目已经进行了很多周，我们团队从刚开始的基础薄弱到现在的大家都可以运用Android来编写程序，共同完成一个app的开发使用。
刚开始做团队项目之时，我们团队就开了一个会，确定了以后的分工和任务。有的同学负责安卓的学习，有的同学负责界面的设计，有的同学负责撰写博客。因为刚开始的时候只有薄霖同学一个人有安卓开发的基础，所以其他同学会在前期进行安卓的学习等。在团队项目的中后期，同学们开始进行整个app的开发，从前端的设计到后端的开发再到前后端的接合，一个app顺利的呈现在大家眼前。
通过这一段时间的团队合作，大家都有了收获和提高，团队合作也有一些有优势的地方：
1.大家都在做同一个项目，可以互相监督进度，共同努力，共同提高，不会的同学也可以向团队中比较擅长的同学请教，一旦有同学出现拖延情况就有其他同学提醒，让这位拖延的同学赶上进度
2.效率高，每个人每天都有需要完成的任务，每天都会发布Scurm Meeting博客，表明每个同学今天的任务和明天的计划，也说明今天任务所用的时间，这形象的表明了任务的进度和整个任务的进程。
二、阅读
银弹：Brooks在他最著名的《没有银弹-软件工程中本质性和偶然性》文章里指出，在软件开发过程里是没有万能的终杀性武器（即银弹）的，只有各种方法综合运用，才是解决之道。但任何神奇的理论和方法，都不能解决“软件危机”。
我觉得“没有银弹"的看法比较正确，因为软件的内在设计本身就有一定的复杂性，而风险和危机是必须且不能避免的。成熟的软件需要综合各个方面的考虑，在软件的应用过程中危机也是会发生的，实际过程中的复杂度就不是能仅仅依靠技术解决的了。
大泥球：指的是设计结构糟糕，到处补丁，缝缝补补的软件。这种情况常常出现在时间和预算限制的情况下，软件开发者无暇将设计做到完美就匆忙开始发行第一个版本。我认为，在这种情况下应该加强对代码的控制，调节团队的节奏，将任务细化至每一个人，加强对成员代码质量的管理，提高代码的正确率和代码可读性。
大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。
市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。
瀑布模型：是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段。
瀑布模型的优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
敏捷开发：以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。