Сколько единства между разными командами? - PullRequest
1 голос
/ 19 марта 2011

Наша компания создает несколько (Java) приложений, которые свободно взаимодействуют друг с другом через веб-сервисы, удаленный EJB и иногда через общие данные в БД.

Каждое из этих приложений создается и поддерживается их собственными командами. 1 или 2 человека для небольших приложений и почти 10 для самых крупных. Общее количество разработчиков составляет около 25 FTE.

Одна проблема, с которой мы сталкиваемся, заключается в том, что в командах есть большие эго. Исторически команда крупнейшего приложения создала соглашение о коде и общие руководящие принципы. Например, наша IDE - это Netbeans, мы используем Hg для SCM, собираем с помощью Ant и подчеркиваем, что сначала следует использовать как можно больше из Java EE, если этого недостаточно, использовать внешнюю библиотеку и прибегать к написанию чего-либо самостоятельно в качестве последнего средства , Написание таких вещей, как еще одна структура ведения журналов, orm, cms или веб-структура, в значительной степени не допускается в соответствии с этими инструкциями.

Теперь некоторые из небольших команд идут против этого и начинают использовать Eclipse, Git и Maven, и они сами стараются писать как можно больше и смотреть только на существующие вещи, если времени мало или они просто не хотят писать сами ». Там, где основная команда использует log4j, одна из небольших команд только начала писать свою собственную структуру ведения журналов.

Ведутся переговоры о том, что все команды придерживаются одинаковых стандартов, но в лучшем случае они были "хлопотными".

Теперь большой вопрос, который я хотел бы задать: действительно ли имеет значение, что разные команды делают вещи по-разному? Пока каждое отдельное приложение реализует свои требования и предоставляет согласованные интерфейсы, должны ли мы действительно заставлять всех использовать Hg, Ant, одни и те же соглашения о коде и т. Д. И т. Д.?

1 Ответ

0 голосов
/ 01 апреля 2011

Нет особого вреда в том, чтобы позволить каждой команде использовать технологии, которые работают для них лучше всего. На самом деле, если вы ограничите команды «стандартным» способом ведения дел, вы подавите инновации и будете иметь плохой моральный дух.

Но вы не хотите, чтобы вещи сильно расходились. Есть несколько вещей, которые вы можете сделать, чтобы библиотеки и инструменты не вышли из-под контроля. Во-первых, нужно регулярно менять членов в командах для перекрестного опыления идей. Таким образом, лучшие идеи будут распространяться в командах.

Вы также можете применить «правило 3», которое просто говорит, что можно ввести вторую библиотеку, инструмент, подход к ведению журнала, что угодно. Но как только вы захотите ввести третий, вы должны удалить один из первых двух. Другими словами, нормально иметь 2 конкурирующих каркаса логирования, но если есть 3 каркаса логирования, выберите один для уничтожения.

Третья идея - позволить разработчикам регулярно проводить презентации для всей группы разработчиков, чтобы продемонстрировать преимущества и недостатки каждой идеи или подхода. Поощряйте много дискуссий и конструктивной критики. Цель состоит в том, чтобы попробовать много вещей и позволить каждому найти лучший способ для группы.

Наконец, Management 3.0 гораздо глубже рассказывает о том, как команды принимают решения. Стоит прочитать.

...