跨不同團隊有多少團結？

Question

我們公司構建了幾個（Java）應用程序，這些應用程序通過Web服務，遠程EJB和偶爾通過數據庫中的共享數據鬆散地與彼此進行通信。

這些應用程序的每一個都是由他們自己的團隊構建和維護的。 1或2人爲較小的應用程序，而最大的應用程序將近10人。開發人員總數約爲25 FTE。

我們面臨的一個問題是團隊中存在一些很大的自負。歷史上最大的應用程序團隊已經建立了代碼約定和一般指導方針。例如，我們的IDE是Netbeans，我們使用Hg作爲SCM，使用Ant構建並強調首先儘可能多地使用Java EE，如果這還不足以使用外部庫，並且只能使用自己寫的東西作爲最後的手段。按照這些指導原則，寫入諸如另一個日誌框架，orm，cms或web框架之類的東西幾乎是不被允許的。

現在一些較小的團隊違背了這一點，開始使用Eclipse，Git和Maven，並且儘可能地自己寫一個方法，只在時間很短或者他們感覺不到時纔看現有的東西喜歡自己寫「。主隊使用log4j的時候，其中一個較小的團隊開始編寫他們自己的日誌框架。

關於所有堅持相同標準的團隊都在進行談判，但這些一直是'麻煩'的。

現在我想問一個大問題：不同的團隊以不同的方式做事情有關係嗎？只要每個單獨的應用程序實現其要求並提供商定的接口，我們是否應該強制每個人使用Hg，Ant，相同的代碼約定等等？

Answer 1

讓每個團隊使用最適合他們的技術並沒有太大的危害。事實上，如果你將團隊限制在「標準」做事的方式，你會扼殺創新，並且士氣低落。

但是你不想讓事情分歧太多。有幾件事你可以做，以防止圖書館和工具失控。首先是通過團隊定期輪換每個成員以交叉授粉想法。這樣最好的想法將通過團隊傳播。

你也可以執行一個「3規則」，它只是簡單地說引入第二個庫，工具，日誌記錄方法是可以的。但是一旦你想介紹第三個，你必須刪除前兩個之一。換句話說，可以有2個競爭的日誌框架，但是如果有3個日誌框架，選擇一個來殺死。

第三個想法是讓開發人員定期向整個開發人員組演示，以展示每個想法或方法的優缺點。鼓勵大量的討論和建設性的批評。目的是嘗試許多事情，並讓每個人都能找到最好的方式。

最後，Management 3.0深入探討了團隊如何做出決定。值得一讀。