在上次的《构建之法》中，我们已经学习到了关于团队模式的很多种类。一群人合作，在一起做软件开发，总是需要一些既定的规则和方式方法的。也就是开发流程。
有写了再改模式，但是解决实际需求的软件时，这个方法的缺点就太大了；还有瀑布模型，但是温斯顿却正确地指出了在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题，他还指出用户的及早介入、讨论、复审是很重要的，虽然瀑布模型有很多的局限性，但它还是一个反应人类解决问题思路的常用模型。在众多模型中集大成者要算Rational统一流程。RUP把软件开发的各个阶段整合在一个统一的框架里。完成一个复杂的软件项目，团队的各种成员要在不同的阶段做不同的事情。例如，业务建模，需求，分析和设计，实现，测试，部署，配置和变更管理，项目管理，环境。
拿到一个项目工程，首先需要做的就是了解客户的要求，和用户的需求，这是我们以后做一个软件的基础和标准。项目经理不需要懂专业知识，但是一定要可以和客户交流，可以很好的分配团队成员的任务及时间，了解团队成员的特长，可以更好的发挥团队优点。
2001年开始，一些软件界的专家开始倡导“敏捷”的价值观和流程，在软件工程里，“敏捷流程”是一系列价值观和方法论的集合。敏捷流程的步骤：1.找出完成产品需要做的事情；2.决定当前需要解决的事情；3.冲刺，这时候，外部人士不能打扰团队成员。每个人每天都要向同伴报告进度，这样问题就可以摆到明面上，并且启动每日构建，让大家每天都能看到一个逐渐完善的版本。
敏捷流程带来的价值虽然更高，但是传统的模式也是不可抛弃的，它也有自己的优点。