Рисунок 12. Распределенная команда разработки программного обеспечения
Решение представленной проблемы лежит не в плоскости управления, а в плоскости архитектуры. Конечно, возможно построить дорожную карту реализации всех компонентов, осуществлять контроль всех сроков исполнения, учитывая результаты итераций разработки, а также получаемую обратную связь от пользователей. Но указанный подход в последние годы получил негативную смысловую окраску, заслужив присвоение ему термина «микроменеджмент». Кроме того, подобный подход исключает возможность работы самоорганизующихся команд, противореча манифесту Agile. Каким же образом в данном случае может помочь архитектура, что требуется от архитектора?
По ходу настоящего изложения рассматривались революционные подходы к архитектуре, переход к микросервисной архитектуре с применением продуктового подхода и практик EDA, а также проблемы mindset. Использование лучших современных практик и должно быть применено в полной мере, mindset же должен служить соответствующим базисом. При функциональной декомпозиции создаваемого программного обеспечения работа распределенной команды разработки будет продолжать соответствовать Рисунку 12, исключая эффективность и независимость общей работы, а также увеличивая риски любого проекта. Иначе обстоит дело с применением продуктового подхода. Иллюстративно продуктовый подход, микросервисная архитектура и EDA в применении распределенной командой разработки показаны на Рисунке 13. Отметим, что серьезное упрощение, привносимое данными подходами, позволяет показывать на рисунке иллюстративные примеры и предметной области (как и ранее в книге, финансовой).
Рисунок 13. Применение микросервисной архитектуры,
продуктового подхода и EDA распределенной командой
разработки
На Рисунке 13 представлены 2 продукта, создаваемых различными командами разработки в составе общей распределенной команды. Общее решение создается в рамках обслуживания клиентов – юридических лиц, которым доступны два продукта: кредитование и электронные банковские гарантии. Одна команда разрабатывает продукт кредитование, вторая – электронные банковские гарантии. Каждое продуктовое решение создается в соответствии с парадигмой микросервисной архитектуры, при этом каждый микросервис является самостоятельной единицей развертывания. Взаимодействие микросервисов осуществляется посредством платформы событийного обмена и подчиняется принципам EDA. В чем же преимущество представленного подхода?
Каждый продукт представляет самодостаточную ценность для клиента, поэтому команды, создающие соответствующие продуктовые решения, могут независимо взаимодействовать с клиентами, представителями