Как вы поддерживаете технические контракты между командами разработчиков?

Question

Например, команда A и команда B работают над различными приложениями, которые должны реализовать аналогичную функцию. Эта функция зависит от базы данных, а база данных находится под контролем команды B. Хотя пользовательские интерфейсы двух приложений основаны на разных технологиях, функциональность должна быть примерно одинаковой. Обе команды имеют собственные требования и проектные документы. Функциональность может быть изменена на основе обратной связи от любой команды, но тогда обе команды должны обновить свои требования и проектные документы.

Команды распределены географически, а члены каждой команды также географически распределены. Обе команды работают с одним и тем же клиентом, но с разными людьми. У каждой команды есть собственный бизнес-аналитик (специалист по требованиям). Я пытаюсь сделать техническую связь между командами более формальной, чем электронная почта, чтобы мы могли избежать недоразумений.

Как вы убедитесь, что если команда B изменяет базу данных и функциональные возможности, другая команда получает уведомление об этом должным образом? Используете ли вы некоторые формальные текстовые документы, такие как контракты на интерфейс? Можете ли вы поделиться с ними шаблонами? Или вы используете какой-то другой механизм?

Answer 1

Несколько вещей из моего собственного опыта (который звучит очень похоже на вас)

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

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

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

Из проекта, над которым я работал, вы все равно можете иметь случайные разногласия и разбивку, в итоге мы объединили обе команды. Это было лучшее решение для всех!

Надеюсь, это поможет немного

Answer 2

Как насчет того, чтобы иметь сайт Team (как в одной команде), так и Wiki, чтобы обе команды знали об этом изменении.

Answer 3

Регулярные постоянные встречи. Через конференц-связь. Stand-up == краткая, высоко ориентированная, ориентированная на информацию. Делегаты обсуждают отдельные обсуждения за пределами заседания, сообщая о них в следующий раз.

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

Я согласен с Wiki или другим сайтом совместной работы для публикации текущей реальности.