여러 팀의 통일성은 어느 정도입니까?

Question

우리 회사는 웹 서비스, 원격 EJB 및 때로는 DB의 공유 데이터를 통해 서로 느슨하게 통신하는 여러 가지 (Java) 응용 프로그램을 빌드합니다.

각 응용 프로그램은 해당 팀에서 만들고 유지 관리합니다. 작은 앱의 경우 1 ~ 2 명이고 가장 큰 앱의 경우 약 10 명입니다. 총 개발자 수는 약 25 명의 FTE입니다.

우리가 직면하는 한 가지 문제는 팀 중에 큰 자존심이 있다는 것입니다. 역사적으로 가장 큰 앱 팀은 코드 규칙 및 일반 가이드 라인을 설정했습니다. 예를 들어 우리 IDE는 Netbeans입니다. 우리는 Hg를 SCM으로 사용하고, Ant로 빌드하고, 가능한 한 Java EE에서 최대한 많이 사용하도록 강조합니다. 외부 라이브러리를 사용하는 것으로 충분하지 않고 최후의 수단으로 무언가를 작성하는 데만 의존한다면 . 아직 다른 로깅 프레임 워크, orm, cms 또는 웹 프레임 워크를 작성하는 것은이 가이드 라인을 따르는 것이 허용되지 않습니다.

이제는 소규모 팀 중 일부가 Eclipse와 Git 및 Maven을 사용하고 가능한 한 많이 작성하고 시간이 부족하거나 기분이 좋지 않을 때만 기존 작업을 살펴볼 수 있습니다 그것을 쓰고 싶다. ' 주요 팀이 log4j를 사용하는 곳에서는 소규모 팀 중 하나가 자체 로깅 프레임 워크를 작성하기 시작했습니다.

동일한 표준을 고수하는 모든 팀에 대해 논의가 있었지만 기껏해야 '번거로운 작업'이었습니다.

이제 내가 묻고 싶은 큰 질문 : 다른 팀이 상황을 다르게하는 것이 실제로 중요합니까? 각각의 별개의 앱이 요구 사항을 구현하고 합의 된 인터페이스를 제공하는 한, 모든 사람들에게 Hg, Ant, 동일한 코드 규칙 등을 사용하도록 강요해야합니까?

Answer 1

각 팀이 자신에게 가장 잘 맞는 기술을 사용하게하는 데 큰 해가되지 않습니다. 실제로 팀을 "표준"방식으로 제한하면 혁신을 저지하고 사기를 꺾습니다.

하지만 당신은 일이 너무 많이 갈라 지길 원치 않습니다. 라이브러리와 도구가 손에 닿지 않도록하기 위해 할 수있는 몇 가지 방법이 있습니다. 첫 번째로 아이디어를 서로 나누기 위해 팀을 통해 각 회원의 정기적 인 회전을 갖는 것입니다. 이 방법으로 최고의 아이디어가 팀을 통해 확산됩니다.

"규칙 3"은 두 번째 라이브러리, 도구, 로깅 접근 방식을 도입하는 것이 좋다고 말합니다. 그러나 세 번째를 소개하자마자 첫 번째 두 개 중 하나를 제거해야합니다. 즉, 2 개의 경쟁 로깅 프레임 워크가 있으면 좋지만 3 가지 로깅 프레임 워크가있는 경우 하나를 선택하여 제거하십시오.

3 번째 아이디어는 개발자가 전체 개발자 그룹에게 정기적 인 프레젠테이션을 실행하여 각 아이디어 나 접근 방법의 장단점을 보여주는 것입니다. 많은 토론과 건설적인 비판을 장려하십시오. 목적은 여러 가지를 시도하고 모두가 그룹으로서 최선의 방법을 찾도록합니다.

마지막으로 Management 3.0은 팀이 어떻게 의사 결정을 내리는 지 자세히 설명합니다. 읽어 볼만한 가치가 있습니다.