注重实效的团队：一旦参与项目的人员超过一个，你就需要建立一些基本原则，并相应的派任务。我们将说明怎样在遵循注重实效哲学的同时做到这一点。

一个好的团队，应该会从如下几个方面来考察：

不留破窗户

质量是一个团队问题。最勤勉的开发者如果被派到不在乎质量的团队里，会发现自己很难保持修正琐碎问题所需的热情。如果团队主动鼓励开发者不要把时间花费在这样的修正上，问题就会进一步恶化。团队作为一个整体，不应该容忍破窗户——那些小小的、无人修正的不完美。团队必须为产品的质量负责，支持那些了解我们在“软件的熵”中描述的“不要留破窗户”哲学的开发者，并鼓励那些还不了解这种哲学的人。质量只可能源于全体团队成员都做出自己的贡献。

煮青蛙

煮青蛙的故事大家都了解过了，没有注意到周围环境的渐变，最终被煮熟了。同样的事情也会发生在不警醒的人身上。在项目开发高涨的热度里，很难用一只眼睛注意周围的环境。

作为整体的团队甚至更容易被煮熟。大家认为，另外有人在处理某个问题，或是团队领导一定已经批准了用户要求做出的某项改动。即使是目的最明确的团队对项目中的重大改动可能也是健忘的。

交流的团队

显然，团队中的开发者必须相互交谈。我们在“交流！”中给出了一些促进交流的建议。但是，人们很容易忘记，团队本身也存在于更大的组织中。团队作为实体需要同外界明晰地交流。

对外界而言，看上去沉闷寡言的项目团队是最糟糕的团队。他们举行无章次的会议，在回上没有人想说话。他们的文档混乱：没有两份文档有相同的外观，每一份都使用不同的术语。

不要重复你自己

大多数团队都应是分工明确的，举例来说，团队中有负责管理对接其他部门业务的，有管理数据的，有管理文档的，如若在需要的时候有针对性的联系某人，效率一定会提升不少。

正交性（围绕功能而不是工作职务进行组织）

自动化测试

为了确保事情得以自动化，指定一个或多个团队成员担任工具构建员，构造和部署使项目中的苦差事自动化的工具。让它们制作makefile、shell脚本、编辑器模板，使用程序等等。

可执行文档

注重实效的程序员 会把文档当作整个开发过程的完整部分加以接受。

代码中的注释、接口文档、环境配置清单等等。