软件团队模式和开发流程
软件团队的模式
主治医师模式（Chief Programmer Team，Surgical Team）
就像在手术台上那样，有一个主刀医师，其他人（麻醉，护士，器械）各司其职，为主刀医师服务。
这样的软件团队中，有首席程序员（Chief Programmer），他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。
在一些学校里，软件工程的团队模式往往从这一模式退化为『一个学生干活，其余学生跟着打酱油』。
明星模式（Super-star Model）
主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化？如何让团队的价值在明星陨落之后任然能够保持？是这个模式要解决的问题。
社区模式（Community Model）
社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是『众人拾柴火焰高』，但是如果大家都只来烤火，不去拾柴；或者捡到的柴火质量太差，最后火也就熄灭了。『社区』并不意味着『随意』，一些成功社区项目（例如开发和维护Linux操作系统的社区），都有很严格的代码复审和签入的质量控制。
业余剧团模式（Amateur Theater Team）
这样的团队在每一个项目中，不同的人会挑选不同的角色。在下一个项目中，这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。
秘密团队（Skunk Work Team）
一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。这种模式的好处是：团队内部有极大的自由，没有外界的干扰（不用每周给别人介绍项目进展，听领导的最新指示，等等），团队成员有极大的投入。
特工团队（SWAT）
软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。
交响乐团模式（Orchestra）
想象一下交响乐团的演奏，有下面的特点。
- 家伙多，门类齐全。
- 各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。
- 演奏都靠谱，同时看指挥的。
- 演奏的都是练习过多次的曲目，重在执行。
当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会才去这种模式。
爵士乐模式（Jazz Band）
和交响乐团相比，这种模式有以下特点。
- 不靠谱。他们演奏时都没有谱子。
- 没有现场指挥，平时有编曲起到协调和指导作用。
- 也有模式，架构师先吹出主题，然后他走到一旁抽烟去了，其余人员根据这个主题各自即兴发挥，最后迈尔斯加入，回应主题，像是对曲子的总结。
- 人数较少。
功能团队模式（Feature Team）
很多软件公式的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。
在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系。大型软件公司里的不少团队都是采用这种模式。这些功能小组也称为Feature Crew，小组内的交流比较频繁。
每个小组都由一到三个人组成，每个小组都是一个有自主权的单元，可以自由选用最有利于他们完成工作的任何技术。但是，每个小组必须与其他小组就编码规范达成一致。
官僚模式（Bureaucratic Model）
这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。
这种模式如果应用不好，最后会变成『老板驱动』的开发流程。
