Вынесу ответ на один из вопросов, полученных перед вебинаром в отдельное сообщение. Собственно, вопрос традиционный, похожие были и раньше. Вопрос
о взаимодействии архитектора с командой разработки. Для архитектора продукта/платформы он особенно актуален.
Говоря о
взаимодействии с командой легко упустить из виду, что
команда – это некоторая абстракция. Мы разговариваем не с командой, а с конкретными людьми. Соглашаемся, спорим, договариваемся. Часто под фразой взаимодействие с командой скрывается общение всего с одним человеком, например, тимлидом или даже менеджером. И это именно он боится выпускать архитектурные решения из своих рук (или полностью передоверяет их какому-то одному разработчику). Другим участникам команды выработки архитектурных решений тоже не достается, а за фразой
The best architectures, requirements, and designs emerge from self-organizing teams скрываются предложения конкретного человека.
Проблема даже не в том, что архитектурные решения принимает кто-то один. Часто это квалифицированный и опытный разработчик. Проблема, если всегда происходит
только так! Без обсуждений, рассмотрения альтернатив, картезианского радикального сомнения со стороны кого-то еще. Рано или поздно полезут ошибки, сформируются предпочтения, от которых непросто отказаться, сменятся технологии. Разработчики, выключенные из процесса проектирования, потеряются мотивацию и просто уйдут. Тонущий корабль с единственным капитаном на борту – узнаваемая картина legacy системы.
Решение проще, чем кажется на первый взгляд. Agile помог разобраться с процессом.
В основе управления эмпирическими процессами заложены три главных принципа: прозрачность, инспекция и адаптация - Скрам Гайд™.
Это пойдет и для архитектуры: transparency, inspection, and adaptation. Инструмент: architecture decision record. В общем, в теме ADR еще далеко не всё сказано. И уж точно ИТ-архитектору есть чем заняться сейчас и будет чем позаниматься в будущем
