【构建之法】第5章-团队和流程

本章重点：

• 典型的软件团队模式和开发流程都有哪些/li>
• 各有什么优缺点/li>
• TSP
• MVP
• MBP
• RUP

1 非团队和团队

团队有一些共同的特点：

• 团队有一致的集体目标，团队要一起完成这个目标；
• 团队成员有各自的分工，互相依赖合作，共同完成任务。

2 软件团队的模式

2.1 主治医师模式（Chief Programmer Team，Surgical Team）

就像在手术台上，有一个主刀医师，其他人（麻醉，护士，器械）各司其职，为主刀医师服务。

这样的团队中，有首席程序员（Chief Programmer）来负责处理主要模块的设计和编码，其他团队成员从各种角度支持他。

这一模式往往退化为：一个人干活，其他人跟着打酱油。（作者以学校的软工课为例）

2.2 明星模式（Super-star Model）

主治医师模式运用到极点，可以退化为明星模式。

明星的光芒盖过了团队其他人的总和。

往往对于团队的成长不利，如何让团队的利益最大化、如何让团队的价值在明星陨落之后仍然能够保持，是这个模式要解决的问题。

2.3 社区模式（Community Model）

社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。

优势在于：众人拾柴火焰高。

缺陷在于：“社区”并不意味着“随意”，一些成功的社区项目，都有很严格的代码复审和签入的质量控制。

2.4 业余剧团模式（Amateur Theater Team）

每个人可以在不同的项目中尝试不同的角色。

但是在竞争性强烈、创造性要求高的团队，不会存在完美的民主气氛。

2.5 秘密团队（Skunk Work Team）

一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。

这种模式的好处是：团队内部有极大的自由，较高的热情，没有外界的干扰（不用每周给别人介绍项目进展，听领导的最新指示，等等）。这样的团队往往能发挥超高的效率完成看似不可能的任务。

2.6 特工团队（SWAT）

一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而又紧迫性的问题。

2.7 交响乐团模式（Orchestra）

门类齐全，各司其职，演奏的都是练习过多次的曲目，重在执行。

2.8 爵士乐模式（Jazz Band）

强调个性化的表达，强有力的互动，对变化的内容给予有创意的回应。

这看上去跟“敏捷的开发模式”有点类似。

2.9 功能团队模式（Feature Team）

具备不同能力的同事们平等协作，共同完成一个功能。

在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能。小组内的交流比较频繁。

2.10 官僚模式（Bureaucratic Model）

这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。

3 开发流程

• 写了再改模式（Code-and-Fix）
• 瀑布模型（Waterfall Model）
• 瀑布模型的各种变形
• Rational Unified Process 统一流程（RUP）
• 老板驱动的流程（Boss-Driven Process）
• 渐进交付的流程（Evolutionary Delivery），MVP和MBP
• TSP的原则

来源：CA727