一窝蜂模式 (chaos team):
不能否认，这样的团队也有, 只不过他们在这样的模式下存活的时间一般都不长, 没有机会让别人很好地观察。
主治医师模式: (Chief-Programmer Team, surgical team)
就像在手术台上那样, 有一个主刀医师, 其他人(麻醉, 护士, 器械) 各司其职, 为主刀医师服务。
也有首席程序员 (Chief-programmer)，他/她处理主要模块的设计和编码, 其他成员从各种角度支持他的工作 (backup programmer, admin, tool-smith, language lawyer, specialist)。Frederic Brooks Jr. 在设计IBM System 360 的时候就是采用这种模式。
主治医师模式的退化: 在一些学校里, 软件工程的团队模式往往退化为“一个学生干活, 其余学生跟着打酱油”
明星模式(Super-star model):
主治医师模式运用到极点, 可以蜕化为明星模式, 在这里明星的光芒盖过了团队其他人, 前一阵子喧嚣一时的“翔之队”就是一个例子。明星也是人, 也会受伤, 犯错误, 如何让团队的利益最大化, 而不是明星的利益最大化? 如何让团队的价值在明星陨落之后仍然保持? 这是这个模式要解决的问题。
社区模式(Community Model):
社区由很多志愿者参与, 每个人参与自己感兴趣的项目, 贡献力量, 大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火, 不去拾柴；或者捡到的柴火质量太差, 最后火也熄灭了。 “社区” 并不意味着“随意”, 一些成功的社区项目（例如开发和维护Linux 操作系统的社区）都有很严格的代码复审和签入的质量控制。
业余剧团模式(Amateur Theater Team):
这样的团队在每一个项目（剧目）中, 不同的人会挑选不同的角色。在下一个剧目中, 这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中, 这样的事情经常发生。
秘密团队(skunk work team):
一些软件项目在秘密状态下进行, 别人不知道他们具体在做什么。Apple 公司在研发Macintosh 之后的系统时, 就有两三个团队在不同时期进入秘密状态开发。现在一些创业团队也是处于类似状态。 这种模式的好处是: 团队内部有极大的自由, 没有外界的干扰(不用每周给别人介绍进展, 听领导的最新指示)，团队成员有极大的投入。
特工(SWAT) 团队:
就像电影电视中的特工组《加里森敢死队》等等影片一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000 年之前很多公司都需要专业人士去解决Y2K 问题。这些团队成员必须了解传统语言和老式系统, 才能胜任这样的任务。现在还有一些团队专门做网站安全性服务。
交响乐团模式(Orchestra):
大家看过交响乐团的演奏。我觉得有下面一些特点:
· 家伙多, 门类齐全。
· 各司其职, 各自有专门场地，演奏期间无聊天走动随意交流等现象。
· 演奏都靠谱, 同时看指挥的。
· 演奏的都是练习过多次的曲目, 重在执行。
爵士乐模式(Jazz Band):
强调个性化的表达，强有力的互动, 对变化的内容有创意的回应
这听起来和“敏捷的开发模式” 有点类似。
这样的团队模式和上面的“交响乐团模式”有很有意思的对立, 但是两种模式都产生了很受欢迎的音乐作品，因此不能简单地说哪个一定好，哪个一定不好。
功能团队模式(feature team):
很多软件公司的团队最后都演变成功能团队, 简而言之, 就是具备不同能力的同事平等协作, 共同完成一个功能:
在这个功能完成之后, 这些人又重新组织, 和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系.
大型软件公司里的不少团队都是采用这种模式。
还有一个团队模式可以叫-
官僚模式(bureaucratic model)
下面的模式用来表示一个机构的组织架构是没问题的, 但是把这种架构搬到软件开发中, 则会出问题。因为成员之间不光有技术方面的合作和领导, 同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为有各自老板在各自头顶上。
这种模式如果应用不好, 最后会变成“老板驱动” 的开发流程.