Удобный способ интегрировать два отдельных приложения / команды
У нас есть две разные гибкие команды, каждая из которых работает над отдельными, но связанными приложениями.
До сих пор каждая команда работала независимо (отдельные базы кода, хранилища постоянных данных, спринты, резервные копии и т. Д.). Недавно руководство продукта решило, что эти приложения станут еще более тесно интегрированными. В дополнение к этому, размер каждой команды (состоящей из QAs, Devs, BA) будет увеличиваться в течение следующих 6-12 месяцев.
Руководство решило сохранить гибкий процесс в значительной степени без изменений, поскольку он работал хорошо (две команды работают максимально независимо друг от друга), но выдвинул идею основанного на контракте уровня обслуживания в качестве средства интеграции приложений.
В каждом спринте будет указана любая история, требующая интеграции с другим приложением. В этот момент дополнительная история "интеграции" будет добавлена в отставание других команд. Затем этой команде будет поручено выполнить контракт. В то же время другая команда может продолжить свою оригинальную работу над историей, заменив имитационную / фальшивую услугу, пока другая команда не создаст работающую услугу.
Поскольку Agile проповедует философию KISS, несколько человек в командах оспаривают "сложность" этого подхода. Они выступают за продолжение использования хранимых процедур совместного использования в качестве более простой / более простой методологии интеграции, которая "хорошо работала в прошлом".
Я предпочитаю контрактное программирование по разным причинам, но главная причина в том, что он способен обеспечить время компиляции, чтобы увидеть поведение, которое ожидается от вашего приложения. Вы также получаете четкие границы между тем, кому принадлежит какой код, и чей код вы, вероятно, нарушите, если нарушите свой контракт. Хранимые процедуры не делают ничего из этого.
Поскольку мы уже получили много преимуществ от Agile, я хотел бы думать, что уже существует "удобный для Agile" способ справиться с такого рода интеграцией / синхронизацией приложений. Соответствует ли создание SOA-слоя на основе контракта тесту на проворный запах? Есть ли третий вариант, который я не рассматривал?
2 ответа
Отличный вопрос Ходить по канату всегда сложно. Я думаю, что поддержание приложений как можно слабее связанных - это определенно правильный путь.
Самая простая вещь, которая могла бы сработать, - это отличный подход, но следование этому догматически, без учета принципов SOLID и общего хорошего дизайна, даст вам два приложения, которые тесно связаны и, вероятно, полны технического долга, что принесет команда останавливается в какой-то момент в будущем.
Разъединение и добавление абстракции в настоящее время кажется наиболее разумной вещью, если вы не добавляете много дополнительных "каркасов", которые пока не нужны. Хитрость заключается в том, чтобы убедиться, что у вас есть достаточно хороший дизайн, который позволил бы расширять эту инфраструктуру при необходимости, не создавая при этом много ненужных вещей - вам нужно сделать ровно столько, чтобы отделить приложения.
Я не думаю, что сохранение текущего процесса без изменений - хорошая идея. Сотрудничество и общение между командами должно возрасти, иначе это окажет негативное влияние на обе команды. Вы должны следовать практике, подобной Scrum of Scrum.
Редактировать Scrum of Scrum: У меня нет опыта работы с проектом, выполняемым более чем одной командой Scrum, но из-за очень хорошего опыта работы с Daily Scrum я считаю, что Scurm of Scrum работает и повышает производительность во всех командах.