建立和維護一個高性能的軟件開發團隊是一個持續努力的過程。挑戰范圍包括從競爭激烈的市場中吸引優秀人才到提供有趣和富有挑戰性的工作，以及組建團隊結構和促進人員成長。

我們很幸運地工作在一些致力于提升交付質量和頻率的軟件開發團隊，并且我們發現了一些非常的常見阻礙團隊快速地推出優質軟件的結構和做法：

[[165613]]

1：“DevOps”孤島

特別是隨著一個團隊的成長，或者可能是為了填補當前團隊技能集中存在的差距，我們會被誘惑著在團隊中或團隊周圍建立單獨的功能以執行特定的工作崗位。

我們看到的最常見的表現是操作（通常成為DevOps或基礎設施），而且在操作中任何基礎設施相關的任務需要這個單元中的某個人執行。我們認為這在軟件交付的重要組成部分——部署和運行的周圍增加了沒有必要的邊界。

我們寧愿看到真正的DevOps技能植入到軟件交付團隊中，讓這些團隊能夠端到端地交付他們的應用程序，并負責地運行他們的應用程序。

2：缺少權力

我們經常能看到權力缺乏和表現不佳之間呈現了高度的相關性。一個團隊需要能夠管理自己每一天的工作負荷，能夠做出技術決定以及，如有必要的話，還能改變他們的工作方式。

一個團隊被給予小單位的高規格的工作的地方，并且自上而下做出決定的地方，很可能就是那里你會覺得冷漠的地方。

我們發現如果給予團隊一個明確的、注重商業效益的理念，并且授權去弄清楚交付的***方式，那么團隊執行***。

3：隔離利益相關者

在一些組織中可能存在不鼓勵或不允許交付團隊與利益相關者接觸的結構或做法。一個高性能的團隊需要與那些軟件發布的利益相關者進行定期和開放的交流溝通。

除了慣常的論壇，例如kick-off會話和案例展示，可用來促進對話，我們鼓勵使用通信工具，例如Slack，促使利益相關者和開發人員之間能夠進行持續的討論。

4：單槍匹馬和團隊人員過多

我們發現***的團隊規模是2至4人。對于大多數人來說，在只有1個人的團隊中工作比起和其他人一起工作更缺乏問責和社會互動。

當團隊規模開始超過大約4人的時候，溝通會變得困難起來，并且會降低團隊的責任感。

5：質量是所有人的工作

關于質量挑戰一個太過于常見的回應是，試圖通過引入專門的工作崗位，或者甚至更糟的是，引入測試來解決這個問題。在那些團隊和生產運行的軟件之間感知到安全網的地方，責任水平會下降，然后質量緊跟其后。

通過鼓勵質量成為團隊的責任，接受例如同行審查的做法，以及自動化測試技術地不斷采用，我們看到了更好的成功。

6：功能優先于技術債務

在商業交付截止期限和跟上技術債務之間有一個平衡。如果不保持平衡，技術債務會迅速阻礙團隊的交付能力。

團隊樂意累積技術債務，或***樂意對此視而不見，是一些在我們開始和一個軟件開發團隊工作時可以立馬識別和需要改善的行為模式。

一個團隊需要被授權并被鼓勵去向他們的Product Owner推銷償還技術債務的好處，這樣技術債務就可以隨著功能開發一起解決掉。

7：在團隊建設上投資不足

在建設一個有凝聚力的團隊時謹記一些基本知識非常重要。促進大量的社會活動來為團隊提供論壇，讓團隊能夠享受彼此工作之外的企業氛圍，同時為個人提供學習和更好地保持自己進步的機會。

提高任何團隊的幸福感、生產力和凝聚力仍然需要持續的努力，而并且需要定期修正方向。如果你想要構建一個高性能的軟件交付團隊，那么我們會建議你強硬地雇用人才，并投資于可以提供定期反饋循環的實踐行為，以幫助你植入一種經常反省和不斷改進的文化。

譯文鏈接：http://www.codeceo.com/article/7-problems-to-avoid-build-team.html
英文原文：7 Problems to Avoid When Building a Software Team