Рекомендую руководителям проектов, использующим Agile практики и методологии, и архитекторам приложений посмотреть на выступление Ребеки Парсонс (CTO at ThougthWorks) и Мартина Фаулера.

Обсуждаемая проблема заключается в том, что Agile - это эффективно, полезно, да и просто модно :) Но Agile базируется на некоторых обязательных приципах, ориентированных на сильные и самоорганизованные команды: "Individuals and interactions over processes and tools". С другой стороны в организационной структуре крупных и даже средних компаний всегда присутствует роль архитектора (иногда подменяемая позицией технического директора), обязанностями которого являются:

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

Зачастую получается так, что есть несколько выделенных архитекторов (уровня предприятия, процессов, данных, интеграционных и т.п.), на которые приходится десяток команд по 10 - 20 человек в каждой. Вопрос состоит в том, как архитекторам стать вовлеченными во все эти проекты, в условиях ограниченного рабочего дня, как заставлять команду следовать правилам в организации кода, если сразу же возникает масса конфликтов с командами, работающими в рамках Agile. Как учесть нефункциональные требования, о которых заказчик может и не задумываться?

Спикеры дают следующие ответы на эти вопросы:

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

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile