建立和维护一个高性能的软件开发团队是一个持续努力的过程。挑战范围包括从竞争激烈的市场中吸引优秀人才到提供有趣和富有挑战性的工作，以及组建团队结构和促进人员成长。
我们很幸运地工作在一些致力于提升交付质量和频率的软件开发团队，并且我们发现了一些非常的常见阻碍团队快速地推出优质软件的结构和做法：
“DevOps”孤岛
特别是随着一个团队的成长，或者可能是为了填补当前团队技能集中存在的差距，我们会被诱惑着在团队中或团队周围建立单独的功能以执行特定的工作岗位。
我们看到的最常见的表现是操作(通常成为DevOps或基础设施)，而且在操作中任何基础设施相关的任务需要这个单元中的某个人执行。我们认为这在软件交付的重要组成部分——部署和运行的周围增加了没有必要的边界。
我们宁愿看到真正的DevOps技能植入到软件交付团队中，让这些团队能够端到端地交付他们的应用程序，并负责地运行他们的应用程序。
缺少权力
我们经常能看到权力缺乏和表现不佳之间呈现了高度的相关性。一个团队需要能够管理自己每一天的工作负荷，能够做出技术决定以及，如有必要的话，还能改变他们的工作方式。
一个团队被给予小单位的高规格的工作的地方，并且自上而下做出决定的地方，很可能就是那里你会觉得冷漠的地方。
我们发现如果给予团队一个明确的、注重商业效益的理念，并且授权去弄清楚交付的最佳方式，那么团队执行最佳。
隔离利益相关者
在一些组织中可能存在不鼓励或不允许交付团队与利益相关者接触的结构或做法。一个高性能的团队需要与那些软件发布的利益相关者进行定期和开放的交流沟通。
除了惯常的论坛，例如kick-off会话和案例展示，可用来促进对话，我们鼓励使用通信工具，例如Slack，促使利益相关者和开发人员之间能够进行持续的讨论。
单枪匹马和团队人员过多
我们发现最佳的团队规模是2至4人。对于大多数人来说，在只有1个人的团队中工作比起和其他人一起工作更缺乏问责和社会互动。
当团队规模开始超过大约4人的时候，沟通会变得困难起来，并且会降低团队的责任感。
质量是所有人的工作
关于质量挑战一个太过于常见的回应是，试图通过引入专门的工作岗位，或者甚至更糟的是，引入测试来解决这个问题。在那些团队和生产运行的软件之间感知到安全网的地方，责任水平会下降，然后质量紧跟其后。
通过鼓励质量成为团队的责任，接受例如同行审查的做法，以及自动化测试技术地不断采用，我们看到了更好的成功。
功能优先于技术债务
在商业交付截止期限和跟上技术债务之间有一个平衡。如果不保持平衡，技术债务会迅速阻碍团队的交付能力。
团队乐意累积技术债务，或领导者乐意对此视而不见，是一些在我们开始和一个软件开发团队工作时可以立马识别和需要改善的行为模式。
一个团队需要被授权并被鼓励去向他们的Product Owner推销偿还技术债务的好处，这样技术债务就可以随着功能开发一起解决掉。
在团队建设上投资不足
在建设一个有凝聚力的团队时谨记一些基本知识非常重要。促进大量的社会活动来为团队提供论坛，让团队能够享受彼此工作之外的企业氛围，同时为个人提供学习和更好地保持自己进步的机会。
提高任何团队的幸福感、生产力和凝聚力仍然需要持续的努力，而并且需要定期修正方向。如果你想要构建一个高性能的软件交付团队，那么我们会建议你强硬地雇用人才，并投资于可以提供定期反馈循环的实践行为，以帮助你植入一种经常反省和不断改进的文化。
