团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。
团队成员有各自的分工，互相依赖合作，共同完成任务。
软件团队有各种形式，适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。软件团队的模式，最初是混沌的一窝蜂形式：一群人开始写代码，希望能写出好软件。随着团队的成熟和环境的变化。
团队模式会演变成下面几种模式之一。
1.主治医师模式：有首席程序员，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。
2.明星模式：让团队的利益达到最大化
3.社区模式：每个人参与自己感兴趣的项目，贡献力量，
4.业余剧团模式：这样的团队在每一个项目中，不同的人会挑选不同的角色。但都听从一个指挥的指导和安排。
5.秘密团队： 团队内部有极大的自由，没有外界的干扰，不用每周给别人介绍项目进展，听领导的最新指示，团队成员有极大的投入。
6.特工团队：软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。
7.交响乐团模式：家伙多，门类齐全。 各司其职，各自有专门场地，做项目期间没有聊天、走动等现象，同时看指挥的，重在执行。
8.爵士乐模式：和上面的“交响乐团模式”在很多方面都对立，但不能简单地说孰优孰劣。
9.功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。
10.官僚模式:脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。
瀑布模型：（单向、不可逆）
硬件行业中：产品一般遵循：【分析->设计->实现（制造）->销售->维护】的流程。
且一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。
在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题。
要让产品成功，最好把这个模型走两边，先有一个模拟版本，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本。
用户的及早介入、讨论、复审是很重要的。要让顾客正式的、深入的、持续的参与到项目中来。
软件行业中的局限性：
①各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来。
②回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯。
③最终产品直到最后才出现。但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
适用范围：
①产品的正确性非常重要，需要每一步的验证。
②产品模块之间的接口、输入和输出能很好的用形式化的方法定义和验证。
③使用的技术非常成熟，团队成员都很熟悉这些技术。
④负责各个步骤的子团队分属不同的机构，或在不同的的地理位置，不可能做到频繁的交流。