Очень часто поднимается вопрос о применении Agile в больших командах размером более 30 человек. Как известно, Agile методологии рекомендуют работать небольшой командой, желательно расположенной в одном месте. Это очень сильно упрощает коммуникации и позволяет успешно применять большую часть Agile практик. Но при разработке действительно большой системы не всегда можно справиться маленькой командой. Есть проекты с командами более 100 человек. Можно провести аналогию с программированием больших систем. Если у нас есть небольшая по функциональности система, к которой нет жестких требований по расширяемости и отказоустойчивости, то логично реализовать ее единым модулем. При этом возможно разделение на слои для облегчения тестирования и разделения логики. Архитектуры подобных систем очень простые и похожи друг на друга. Это очень напоминает работу небольшой команды. Когда же нам нужно разработать систему с серьезной бизнес логикой, работающую с внешними сервисами, имеющую высокие требования к расширяемости и отказоустойчивости, интегрирующуюся с различными устройствами и обрабатывающую огромные потоки информации, то все значительно усложняется. Тут на помощь приходит компонентная архитектура, асинхронное общение между компонентами, сервисно-ориентированный подход и т.д. Архитектура такого рода систем достаточно непроста и требует тщательного анализа, чтобы не только удовлетворять текущим требованиям, но быть достаточно гибкой и расширяемой. Именно из такого рода архитектур можно позаимствовать приемы организации работы больших команд.

Первый прием для построения компонентной архитектуры – это выделение полноценных компонентов. В случае большой команды такими компонентами являются маленькие подкоманды. Каждая подкоманда имеет все необходимое для независимого существования. У нее есть все нужные ресурсы, как человеческие, так и технические. В такой подкоманде можно сравнительно легко использовать любой понравившийся Agile процесс разработки. Для того, чтобы компонентная архитектура работала, у каждой компоненты должна быть четко очерченная зона ответственности. В случае подкоманды речь идет о части разрабатываемой системы. Для правильного выделения подкоманде ее зоны ответственности необходимо учесть, что компоненты должны быть максимально независимыми.

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

Второй прием – это обеспечение коммуникации между компонентами. Компоненты в архитектуре должны общаться только со своими ближайшими соседями, причем протокол может быть синхронный или асинхронный. В случае с синхронным протоколом (когда компоненты достаточно сильно зависят друг от друга) может применяться совместное планирование итерации, ежедневная синхронизация посредством проведения собрания представителей команд (Scrum of Scrum в методологии Scrum). В случае асинхронного протокола можно использовать Kanban подход. Если одной подкоманде необходимо, чтобы определенный функционал был реализован другой подкомандой, она помещает запрос на эту функциональность в очередь ожидания. Эта очередь может позволять управление приоритетами. Статус заявки можно отслеживать на Kanban доске по мере прохождения всех стадий разработки. Замеряя время цикла от постановки задачи в очередь до ее выполнения, можно добиться более точного планирования для зависимых задач.

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

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

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