一、软件团队的模式
书中介绍了各种团队模式：一窝蜂模式、主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。
这些模式名字看起来就各有特征，算是对各个模式的总结。
一窝蜂模式：最无章法，效率最低，是比较娱乐的方式。
主治医师模式、明星模式：两种方法类似，都是偏向以一个人为主，其他人为辅的开发模式，当然后者更甚。这就有些偏于个人的利益了，而非团队的利益最大化了。（软件工程就应该是团队活动，偏于团队）
社区模式：这一类，在网上多见，不只是软件工程项目，其他偏向民间网络社区的活动，多以这种方式运行。是一种兴趣的聚集地。
业余剧团模式：学生实践项目或培训项目中多见。
秘密团队：秘密状态开发，内部有极大的自由。
特工团队：专门处理棘手且紧迫性的问题。
交响乐团模式、爵士乐模式：两种模式有点对立了。前者功能齐全，众多大型软件公司就采用的这种方式，后者灵活富有创意。各有优势，也各有劣势。
功能团队模式：有点像业余剧团模式，有着不同能力的人，扮演着不同的角色，来共同实现功能。小组内交流频繁，效率高。
官僚模式：带有领导和被领导的关系，过于形式主义。
模式的运用，无非就是提高效率。不同的模式在不同的情况下有着不一样的效果。灵活运用始终是最好的。
二、开发流程
第一部分讲到了 写了再改模式，我就觉得自己就是这个样子。“只用一次”、“看过了就扔”，要用的时候，再去看看整体架构，改改内容。
下面的瀑布模型，就像UML那样复杂。大体流程能够理解，就是感觉过于遵循这个流程，似乎有些死板。后期的瀑布模型的变形，为的就是解决各种不同的问题。
流程的运用，规范工程的运作，至少能免除上面那种 写了再改模式，对于提高效率，灵活改进程序有很大的帮助。
所以，自己的那种 写了再改模式，还是不必提倡了，考虑久远些，是对自己的帮助。