团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。

团队成员有各自的分工，互相依赖合作，共同完成任务。

软件团队有各种形式，适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。软件团队的模式，最初是混沌的一窝蜂形式：一群人开始写代码，希望能写出好软件。随着团队的成熟和环境的变化。

团队模式会演变成下面几种模式之一。

1.主治医师模式：有首席程序员，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。

2.明星模式：让团队的利益达到最大化

3.社区模式：每个人参与自己感兴趣的项目，贡献力量，

4.业余剧团模式：这样的团队在每一个项目中，不同的人会挑选不同的角色。但都听从一个指挥的指导和安排。

5.秘密团队： 团队内部有极大的自由，没有外界的干扰，不用每周给别人介绍项目进展，听领导的最新指示，团队成员有极大的投入。

6.特工团队：软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。

7.交响乐团模式：家伙多，门类齐全。 各司其职，各自有专门场地，做项目期间没有聊天、走动等现象，同时看指挥的，重在执行。

8.爵士乐模式：和上面的“交响乐团模式”在很多方面都对立，但不能简单地说孰优孰劣。

9.功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。

10.官僚模式:脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。

 

瀑布模型：（单向、不可逆）

        硬件行业中：产品一般遵循：【分析->设计->实现（制造）->销售->维护】的流程。

                         且一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。

        在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题。

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

        用户的及早介入、讨论、复审是很重要的。要让顾客正式的、深入的、持续的参与到项目中来。

        软件行业中的局限性：

        ①各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来。

        ②回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯。

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

        适用范围：

        ①产品的正确性非常重要，需要每一步的验证。

        ②产品模块之间的接口、输入和输出能很好的用形式化的方法定义和验证。

        ③使用的技术非常成熟，团队成员都很熟悉这些技术。

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