Роль архитектора в Agile командах

05.02.2010 12:18

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

 

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

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

 

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

 

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

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

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