гибкий способ интеграции двух отдельных приложений / команд [закрыт]

Question

У нас есть две отдельные гибкие команды, каждая из которых работает над отдельными, но взаимосвязанными приложениями.
До сих пор каждая команда могла работать независимо (отдельные базы кода, хранилища сохраняемости, спринты, невыполненные работы и т.д.).Недавно руководство продукта решило, что эти приложения станут еще более тесно интегрированными.Кстати, размер каждой команды (состоящей из QA, разработчиков, BAS) будет увеличиваться в течение следующих 6-12 месяцев.

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

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

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

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

Поскольку мы уже получили много преимуществ от agile, я хотел бы думать, что уже существует "удобный для agile" способ справиться с такого рода интеграцией / синхронизацией приложений.Соответствует ли создание SOA-слоя на основе контракта тесту agile на запах?Есть ли третий вариант, который я еще не рассматривал?

Answer 1

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

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

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

Answer 2

Я не думаю, что сохранение текущего процесса в неизменном виде - хорошая идея.Сотрудничество и коммуникация между командами должны усиливаться, иначе это окажет негативное влияние на обе команды.Вы должны следовать практике, аналогичной практике Scrum of Scrum.

Редактировать Схватка за схваткой:У меня нет опыта работы с проектами, которыми занимается более одной scrum-команды, но из-за очень хорошего опыта ежедневного Scrum я верю, что Scurm of Scrum работает и повышает производительность во всех командах.