项目开发是一个团队合作的工作，只有建立起高效的团队，程序员才能有效率的工作，并且开心的工作。

1：质量是所有人的工作

关于质量挑战一个太过于常见的回应是，试图通过引入专门的工作岗位，或者甚至更糟的是，引入测试来解决这个问题。在那些团队和生产运行的软件之间感知到安全网的地方，责任水平会下降，然后质量紧跟其后。

通过鼓励质量成为团队的责任，接受例如同行审查的做法，以及自动化测试技术地不断采用，我们看到了更好的成功。

2：缺少权力

我们经常能看到权力缺乏和表现不佳之间呈现了高度的相关性。一个团队需要能够管理自己每一天的工作负荷，能够做出技术决定以及，如有必要的话，还能改变他们的工作方式。

一个团队被给予小单位的高规格的工作的地方，并且自上而下做出决定的地方，很可能就是那里你会觉得冷漠的地方。

我们发现如果给予团队一个明确的、注重商业效益的理念，并且授权去弄清楚交付的最佳方式，那么团队执行最佳。

3：隔离利益相关者

在一些组织中可能存在不鼓励或不允许交付团队与利益相关者接触的结构或做法。一个高性能的团队需要与那些软件发布的利益相关者进行定期和开放的交流沟通。

除了惯常的论坛，例如kick-off会话和案例展示，可用来促进对话，我们鼓励使用通信工具，例如Slack，促使利益相关者和开发人员之间能够进行持续的讨论。

4：单枪匹马和团队人员过多

我们发现最佳的团队规模是2至4人。对于大多数人来说，在只有1个人的团队中工作比起和其他人一起工作更缺乏问责和社会互动。

当团队规模开始超过大约4人的时候，沟通会变得困难起来，并且会降低团队的责任感。

5：“DevOps”孤岛

特别是随着一个团队的成长，或者可能是为了填补当前团队技能集中存在的差距，我们会被诱惑着在团队中或团队周围建立单独的功能以执行特定的工作岗位。

我们看到的最常见的表现是操作(通常成为DevOps或基础设施)，而且在操作中任何基础设施相关的任务需要这个单元中的某个人执行。我们认为这在软件交付的重要组成部分——部署和运行的周围增加了没有必要的边界。

我们宁愿看到真正的DevOps技能植入到软件交付团队中，让这些团队能够端到端地交付他们的应用程序，并负责地运行他们的应用程序。

6：在团队建设上投资不足

在建设一个有凝聚力的团队时谨记一些基本知识非常重要。促进大量的社会活动来为团队提供论坛，让团队能够享受彼此工作之外的企业氛围，同时为个人提供学习和更好地保持自己进步的机会。

7：功能优先于技术债务

在商业交付截止期限和跟上技术债务之间有一个平衡。如果不保持平衡，技术债务会迅速阻碍团队的交付能力。

团队乐意累积技术债务，或领导者乐意对此视而不见，是一些在我们开始和一个软件开发团队工作时可以立马识别和需要改善的行为模式。

一个团队需要被授权并被鼓励去向他们的Product Owner推销偿还技术债务的好处，这样技术债务就可以随着功能开发一起解决掉。

程序员的团队建设是一个热议的话题，团队建的好不好，关乎着这个团队所有人的工作状况。