团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。
团队成员有各自的分工，互相依赖合作，共同完成任务。
软件团队有各种形式，适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。软件团队的模式，最初是混沌的一窝蜂形式：一群人开始写代码，希望能写出好软件。随着团队的成熟和环境的变化。
团队模式会演变成下面几种模式之一。
1.主治医师模式：有首席程序员，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。
2.明星模式：让团队的利益达到最大化
3.社区模式：每个人参与自己感兴趣的项目，贡献力量，
4.业余剧团模式：这样的团队在每一个项目中，不同的人会挑选不同的角色。但都听从一个指挥的指导和安排。
5.秘密团队： 团队内部有极大的自由，没有外界的干扰，不用每周给别人介绍项目进展，听领导的最新指示，团队成员有极大的投入。
6.特工团队：软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。
7.交响乐团模式：家伙多，门类齐全。 各司其职，各自有专门场地，做项目期间没有聊天、走动等现象，同时看指挥的，重在执行。
8.爵士乐模式：和上面的“交响乐团模式”在很多方面都对立，但不能简单地说孰优孰劣。
9.功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。
10.官僚模式:脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。
瀑布模型：这个模型描述了单向的、不可逆的生产过程。
软件团队进入了一个不断演进的evolution循环中：[开发→发布→听取反馈→根据反馈做改进]
这个软件什么时候才最后完成呢？
1.时间到了。
2.钱花光了。
3.用户满意了。
我们能否让用户更早地给产品团队反馈？
MVP方法：Minimal Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。
具体的做法是：把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。
我觉得团队模式需要成员之间相互协作，成员间不一定要同时工作，但是是互相依赖着完成的，共同完成任务。我们做项目给用户使用，当用户看到第一个版本的时候，他们就对这个产品很不满意，完全没有任何购买或使用的意愿。在这种情况下，整个团队为第一版所做的各种投入都浪费了，是因为产品团队得到用户的反馈太晚了。所以我们就要用到MVP方法，用最小的成本实现最核心的功能，是我们所追求和向往的。