本章为团队和流程，主要介绍了典型的软件团队模式和开发流程以及它们的优缺点、TSP、MVP、MBP、RUP。

团队有以下共同特点：有一致的集体目标，团队要一起完成这目标；一个团队的成员不一定要同时工作，例如接力跑；团队成员有各自的分工，互相依赖合作，共同完成任务。

软件团队的模式：
1、主治医师模式：这样的软件团队中有首席程序员，他负责处理主要模块的设计和编码，其他成员从各种角度支持他的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。
2、明星模式：主治医师模式运用到极点，可以退化为明星模式。
3、社区模式：社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。
4、业余剧团模式：在每一个项目中，不同的人会挑选不同的角色，在下一个项目中，这些人也许会换一个完全不同的角色类型。个人在团队中听从一个中央指挥的指导和安排。
5、秘密团队:一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。这种模式的好处是：团队内部以后极大的自由，较高的热情，没有外界的干扰。
6、特工模式：软件行业的一些团队由一些有特殊技能的专业人员组成，负责解决一些棘手而有紧迫性的问题。
7、交响乐团模式：门类齐全、各司其职。当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会采取这种模式。
8、爵士乐模式：强调个性化的表达，强有力的互动，对变化的内容有创意的回应。
9、功能团队模式：很多软件公司的团队最后都演变成功能团队，具备不同能力的同事们平等合作，共同完成一个功能。
10、官僚模式：这种模式在软件开发中会出问题，因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。

开发流程
一群人在一起做软件开发，总是要有一些方式方法，就像第一章提到的：我们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中，叫做“软件开发流程”，软件开发流程的目的是为了提高软件开发、运营和维护的效率，以及提升用户满意度、软件的可靠性和可维护性。
1、写了再改模式：这种模式不需要太多其他准备或相关知识，上来就写代码，写不出来就改，但要写一个有实际用户、解决实际需求的软件，这个方法缺点就很大。
2、瀑布模型：他的适用范围如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步验证，产品模块之间的借口、输入和输出能很好的用形式化的方法定义和验证，使用的技术非常成熟，团队成员都很熟悉这些技术，负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
3、瀑布模式的各种变形：生鱼片模型、大瀑布带小瀑布
4、统一流程：业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境、初始阶段、细化阶段、构造阶段、交付阶段
5、老版驱动的流程：该模式的问题领导对许多技术细节是外行，未必懂得软件项目的管理，领导的权威影响了自由的交流和创造，领导最擅长的管理方式是行政命令，这未必能管好软件团队或任何需要创造力的团队，领导的精力有限，领导很忙时，团队怎么办？
6、渐进交付的流程：很接近迭代式开发流程，当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的evolution循环中：开发→发布→听取反馈→根据反馈做改进
7、TSP的原则：使用妥善定义的流程，流程中的每一步都是可以重复的、可以衡量结果的，团队的各个成员对团队的目标，角色，产品都有统一的理解，尽量使用成熟的技术和做法，尽量多地收集数据，并用数据来帮助团队做出理性的决定，制定切合实际的计划和承诺，团队计划要由负责具体执行的角色来制定，增加团队的自我管理能力，专注于提高质量，争取在软件生命周期的早期发现问题，最有效提高质量的办法是做全面而细致的设计工作。

总的来说，本章继上一章的两人合作，深入讲解，介绍了团队的定义，模式，开发流程等，虽然有多种模式，也有多种开发流程，但这些各有其优缺点，有其适合的情况，所以在进行选择时，应该的更多的分析项目的需求，以及需要达到的目标，对质量的要求，是否需要在短时间内完成，是否需要尽早的得到用户的反馈，是否需要后期严格要求的维护等等，根据所做项目的特点，针对目前团队的人员能力水平，资源情况来确定具体的模式以及开发流程；实现队员能力的发挥，资源的合理利用，最终达到开发团队和用户的一致目标。

构建之法 第五周