之前学习了两人合作的要点，现在到团队合作了，到底团队合作和两人合作之间存在着怎样的密切关联，就让我们来看看吧。

一个团队，包含的人数至少是多余两个人的，不然就不会叫做团队了，但是团队也并不是只需要几个人就可以了，人数并不是决定是否是一个团队的重要因素。书中举的有关非团队的例子就很有趣且直观。很明显，并不是需要精通于各种技术的“人才”放在一起就行了，还要把这几个人的目标明确下来，这样才有了团队目标。一个团队的成员并不一定要同时工作。团队成员各有各的分工，互相依赖合作，共同完成任务。软件团队的模式书中举了挺多的。至于实际是怎样的我就不知道了，毕竟我没有经历过真正团队合作的事，作者是做过不少大项目的人，自然是逼我要懂的，相信他写的也有很高的可信度，接下来我们就来看看有哪些吧!

软件团队的模式，最初开始就是几个人互相集结在一起的，是混沌的一窝蜂模式，一群人开始写代码，希望写出好软件。随着团队的成熟和环境的变化，团队中的每个人互相磨合，慢慢地演变成了以下几种模式。首先是主治医生模式，看名字我们不难联想到这时候的团队并不是每个人都在工作的。主治医生模式运用到极点，可以蜕变为明星模式。明星的光芒盖过了其他人，那么其他人的原有水平就会发挥不出来，这就导致了团队的很大的损失甚至失败。而真正有巨大成就的明星都能意识到团队的作用。社区模式由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬，这种模式有利有弊，做得好的应该是包含有很严格的代码复审和签入的质量控制。业余剧团模式中每个团队成员的角色不是固定的。秘密团队内部有极大的自由，在没有了外界的干扰的情况下团队成员有极大的投入。特工团队里有一些成员是有特殊技能的专业人士，他们负责解决一些棘手而有紧迫性的问题。交响乐团模式是在某个软件领域处于稳定成长阶段的时候采用的。这时候的团队每个成员的分工是很明确的且成员的水平不低，代码质量也不低。爵士乐模式人数较少，主题是现场直接决定后由团队成员自由发挥，最后再由架构师总结。很多软件公司的团队最后都演变成功能团队。这个团队的成员能力不同而共同来完成同一个项目。官僚模式脱胎于大机构的组织架构，感觉很想上级与下级的组织。

接下来就是开发流程了，写了再改模式，瀑布模型，瀑布模型的各种变形，Rational Unified Process 统一流程（RUP），老板驱动的流程（Boss-Driven Process）渐进交付的流程（Evolutionary Delivery），MVP和MBP。这里我主要讲一下瀑布模型和RUP。瀑布模型中包括系统需求，软件需求，前期程序设计，分析，程序设计，编码，测试，运行这几个步骤，而这几个步骤里面还包含着六种文档，文档1--软件需求，文档2--前期设计，文档3--界面设计，文档4--最终设计，文档5--测试计划，文档6--运行说明。书中还描述了不少瀑布模型的相关内容，我就不多说了，。RUP中有规程（工作流），这是团队的各种成员要在不同阶段做不同的事情。业务建模，需求，分析和设计，实现，测试，部署，配置和变更管理，项目管理，环境。RUP包括四个阶段，初始阶段，细化阶段，构造阶段，交付阶段。这些名词的解释我觉得没必要说明了。

以上就是本周的学习内容了，下一章的内容是关于一系列价值观和方法论的集合---敏捷流程。

《构建之法》---团队合作