建立軟體開發團隊時要避免的7個問題

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

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

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

1：“DevOps”孤島

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

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

我們寧願看到真正的DevOps技能植入到軟體交付團隊中，讓這些團隊能夠端到端地交付他們的應用程式，並負責地執行他們的應用程式。

2：缺少權力

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

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

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

3：隔離利益相關者

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

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

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

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

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

5：質量是所有人的工作

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

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

6：功能優先於技術債務

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

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

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

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

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

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