关于软件工程的思考04：团队和流程

团队和流程

软件团队的模式

一窝蜂模式Chaos Team

一个欢乐而随意的团队模式，员工没有明确的分工，大家一起追逐和解决一个突然出现的问题。

主治医师模式Chief Programmer Team

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

明星模式（Super-star Model）

这种模式就是主治医师模式运用到极致的模式，在这里明星的光芒盖过了团队其他人的总和。

社区模式（Community Model）

社区一般都有很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量。社区不意味着随意，成功的社区项目有很严格的代码复审和质量控制。

业余剧团模式（Amateur Theater Team）

在这样的团队中，每个人会挑选不同的角色，下一个项目中这些人也许会换一个完全不同的角色类型。每个人在团队中听从一个中央指挥的安排。一般这种模式会出现在培训等业余的环境中，但是在竞争性比较强的团队中不会存在完美的民主氛围。

秘密团队（Skunk Work Team）

这种秘密状态开发的好处是团队内部有极大的自由，没有外界的干扰（介绍项目、听从指示等），一般这样的团队拥有独特的使命，往往能够发挥超高的效率完成看似不可能的任务。

特工团队（SWAT）

这样的团队由一些有特殊技能的专业人士组成，负责解决一些棘手又紧迫的问题，如安全性服务团队。

交响乐团模式（Orchestra）

当某个软件处于稳定成长阶段时，很多的开发团队就会采用这种模式，该模式下的各成员各司其职，负责的部分各不相同，而且每个成员专门处理类似的问题，大家都很专业，由指挥统领全局。

爵士乐模式（Jazz Band）

与交响乐团相比，该模式的成员职责不固定，不专门处理类似的问题，没有统一的指挥，各自即兴发挥。这种模式强调个性化的表达，强有力的互动。

功能团队模式（Feature Team）

很多开发团队采用这种模式，每个小组内具备不同能力，负责不同部分的同事们平等协作，共同完成一个功能。

官僚模式（Bureaucratic Model）

这种模式出现于大机构的组织架构，几个人报告给一个小头目，几个小头目再汇报给上一级。这种模式成员之间不仅有技术方面的合作，还有组织上的领导关系，因为团队不同难以绩效评估，导致很多无谓的算计。

开发流程

写了再改模式（Code-and-Fix）

通常出现在一窝蜂团队模式，不需要准备太多，大家上来就写代码，写不出来就改，也许能改好，当面临只用一次的程序或某些演示程序时，这个方法是有用的。

瀑布模型（Waterfall Model）

这个模型是从其他成熟行业，如建筑工程，借用来的，这些“硬”行业的产品一旦大规模生产，要再返回去修改就非常困难，这个模型就描述了这种单向的、不可逆的生产过程。

这种单向的模型局限性很大，温斯顿指出在设计大型系统时，应该同时完成相邻步骤的回溯，解决上一阶段未能解决的问题：

温斯顿还指出要让产品成功，最好把这个模型走两遍，先有一个模拟版本，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本：

他也提到在该模型中文档的重要性，如下列几种文档：

这种模型在软件工程实践中的局限性在于：

1、软件生产过程中各步骤之间是分离的

2、回溯修改很难甚至不可能，但是实际开发中回溯需要时时回溯

3、最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用

当出现下列情况时，也可以采用瀑布模型：

1、产品的定义非常稳定，产品的正确性非常重要，需要每一步的验证

2、产品模块之间的输入输出定义稳定

3、团队成员很熟悉使用的技术

4、负责各步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁交流

瀑布模型的各种变形

生鱼片模型，这种模型的各相邻模块像生鱼片那样部分重叠，解决了各步骤之间分离的缺点：

子瀑布模型，它解决了各子系统之间进度不一，技术要求不同，需要区别对待的问题：

该模型的缺点时最终测试难度大，且没有解决最终产品最后出现的问题。

统一流程RUP

统一流程Rational Unified Process把软件开发的各个阶段整合在一个统一的框架中。要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在RUP中叫做规程（Discipline）或者工作流（Workflow），各阶段工作如下：

1、业务建模Business Modeling：它用精确的语言（通常是UML）把用户的活动描述出来，这个工作流的结果通常是用例（Use Case）

2、需求：分析软件系统要提供的功能，功能有什么约束条件，如何验证功能满足了用户需求

3、分析和设计：设计系统，包括有什么子系统、模块以及它们之间的关系

4、实现：按照计划开发出组件，然后搭建可执行的系统

5、测试

6、部署：生成最终版本并将软件分发给用户

7、配置和变更管理：负责管理各阶段产生的各种工作结果，要记录修改人员、修改原因、修改时间等属性

8、项目管理：负责平衡各种可能产生冲突的目标，管理风险，克服各种约束

9、环境：向软件开发组织提供软件开发环境，包括各种工具

RUP把软件开发分为几个阶段，一个阶段的结束称为一个里程碑（Milestone）每个阶段内可能有几次迭代，这样就能比较灵活的完成任务，这样的阶段有4个：

1、初始阶段：分析软件系统大致的构成，大致的成本和预算、系统风险、系统与外部系统的边界。该阶段完成后项目会达到生命周期目标（Lifecycle Objective）里程碑。

2、细化阶段：建立健全体系结构、编制项目计划，为项目建立支持环境、创建开发案例、创建模板并准备工具。该阶段完成后项目会达到生命周期（Lifecycle Architecture）里程碑

3、构造阶段：团队开发出所有的功能集，并经过各种测试验证，构造阶段结束后项目会到达初始功能（Initial Operational）里程碑，此时的产品版本也被称为beta版

4、交付阶段：此时团队工作的重点是确保软件能满足最终用户的实际需求，交付阶段可以有迭代（beta1、beta2），根据用户的反馈不断的完善调整。该阶段结束后项目到达产品发布（Product Release）里程碑。

RUP驼峰图：

老板驱动的流程（Boss-Driven Process）

这种模式下开发流程实际上是由行政领导主导，或直接由公司的老板推动的。这种模式可能会出现在软件团队未成熟的时期，也有可能是因为软件订单的获得不是靠技术，而是靠人脉。这种模式下，领导对许多技术细节都是外行，领导的权威影响了自由的交流和创造。

渐进交付的流程（Evolution Delivery）、MVP和MBP

渐进交付这种模式比较接近于迭代式开发流程，当需求和架构基本明确后，软件团队进入了一个不断演进的循环中：

MVP（Minimum Viable Product）流程的核心是把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见，这样就不至于拖了很久弄好第一版，结果用户没有购买意愿的尴尬局面。MVP的思想和渐进交付类似，但是它更强调用户的反馈。

MBP（Maximal Beautiful Product）是与MVP相对的一种模式，它把产品最全、最美的形态都展现出来，一举征服用户。

TSP的原则

优秀的模式和流程都有一些共同点，这些共同点抽象总结为TSP（Team Software Process）原则：

1、使用妥善定义的流程，流程中的每一步都是可重复、可衡量结果的

2、团队中的各个成员对团队的目标、角色、产品都有统一的理解

3、尽量使用成熟的技术和做法

4、尽量收集数据，并利用这些数据来帮助团队做出理性的决定

5、制定切合实际的计划和承诺，团队计划要由负责具体执行的角色来定（而不是从上级而来）

6、增加团队的自我管理能力

7、专注于提高质量，争取在软件生命周期的早期发现问题，做全面而细致的设计工作