团队是有一致集体目标的团体，成员各有分工，互相依赖合作，共同完成任务。
软件团队模式分为很多种，如主治医师模式、社区模式、爵士乐模式，官僚模式等等，它们各有优缺，应用于不同环境，不同类型的团队成员，比如主治医师模型适用于首席程序员极其优秀的情况等等。
我觉得对于我们学生现如今而言，比较好的还是交响乐团模式以及功能团队模式。交响乐团门类齐全，各司其职，演奏都靠谱，同时看指挥；而功能团队模式是指具备不同能力的同事们平等协作，共同完成一个功能，在这个功能完成以后，这些人又重新组织，和别的角色一起去完成下一个功能。
我希望我们的团队模式可以是二者的结合形式，通过磨合，能够协同作战。团队可以公开的讨论流程和工作的方式，协商制定计划；PM可以得到广泛尊重，有能力的成员也分担一定的领导职责；大家各司其职，平等协作，最后汇总各部分，完成任务。
对软件开发流程的理解
软件开发流程即软件设计思路和方法的一般过程，是联系了软件开发、运营、维护过程中的技术、做法、思想和过程的一个体系，包括需求分析，设计软件的功能和实现的算法，软件的总体结构设计，编码和调试，编写和提交程序等满足客户需求的一系列操作。软件开发流程的目的是为了提高软件开发、运营和维护的效率，以及提升用户满意度，软件的可靠性和可维护性。
随着不断地发展，软件开发流程也呈现百花齐放格局，不同流程适用于不同情境。
瀑布模型描述了单向的、不可逆的生产过程，这种生产显然是有很大弊端，比如到最后阶段才发现初始阶段就有问题，那么由于不可逆只能推翻重来，浪费了大量时间精力与金钱，显然不是很可取。但是Winston Royce对此模型提出了一些改进的办法，比如相邻步骤的回溯，即做下一步之前要先解决上一阶段未能解决的问题；又比如将模型走两遍，即先有一个模拟版本，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本。尽管有了如此的改进，“瀑布模型”有了适用范围，但其还是有着一定的局限性，比如有些软件生产过程不能严格分离各步骤，回溯修改困难甚至不可能，不能尽早知晓原型并使用等等。为了解决这些问题，人们在实践中提出了“瀑布模型”的各种变形，如“生鱼片模型”“子瀑布模型”，但是这些变形虽然可以解决某一问题，但是不能解决全部问题。
从“瀑布模型”开始的模型都有一个共同点：重计划，重事先设计，重文档表达，而Rational统一流程（RUP）就是该方法实践的翘楚。RUP要求团队的各种成员在不同阶段做不同事情，将一个周期的开发过程分为四个阶段：初始阶段（为项目建立一个业务案例）、细化阶段（建立工程计划和合理的体系）、构造阶段（建造系统）、交付阶段（把系统提供给用户）。在开发过程中用到了迭代，可以降低风险，得到用户早期的反馈，基于用户反馈，团队可以对系统进行修改，对功能进行调整，交付阶段的终点便是产品发布。
除此之外，还有渐进交互的流程，当系统的主要需求和构架明确之后，团队进入“开发-发布-听取反馈-改进”的不断循环之中，直至时间金钱用完，用户很满意或很不满意方才停止。为了让用户尽早地给团队提供反馈，提出了一种新的方法：MVP，即把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见，既避免了浪费也降低了成本。当然如果对用户需求了然于心，或者产品团队比用户更了解用户的需求，也可以直接把产品最美、最全的形态呈现出来，即MBP。
软件开发流程必不可少也极其众多，但是它们各有其适用的范围，比如“瀑布模型”适用于产品定义非常稳定，技术非常成熟等条件下，而RUP适用于大型软件团队开发大型项目。虽然有些流程存在很多问题，但是只要清楚定位，在不同环境下使用不同的开发流程，就可以降低成本，节省时间，节约人力物力，以最小的成本达到各户的期望。