Рик Казман: «Agile не отменяет потребности в сильных лидерах»

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Интервью с ведущим ученым Software Engineering Institute Риком Казманом о сегодняшнем состоянии архитектуры ПО как отдельной дисциплины, особенностях внедрения Cost-Benefit Analysis Method и практиках Agile в SDLC.

Доктор Рик Казман — профессор Гавайского Университета и ученый Института программной инженерии (SEI) Университета Карнеги Меллон. Рик известен как соавтор книги «Software Architecture in Practice» и методики архитектурного анализа ATAM (Architecture Tradeoff Analysis Method)).

Доктор Казман поделился своими взглядами на современное состояние архитектуры ПО, внедрение CBAM и практики Agile в SDLC.

Рик, как бы Вы описали текущее состояние архитектуры ПО как дисциплины — она прочно вошла в нашу жизнь и является зрелой или все еще находится на стадии развития и быстро эволюционирует?

Архитектура ПО, как дисциплина, все еще очень молода. Впервые я услышал этот термин в 90-х годах; то есть этой области — около 25 лет. Для сравнения, химическая инженерия начала развиваться, как профессия, в 1887 году. Профессиональное общество гражданского строительства было учреждено в 1771 году, а возраст профессии исчисляется тысячами лет.

Давайте проведем параллели: чтобы стать архитектором ПО, нужно достаточно долго проработать программистом, а в тоже время в строительной индустрии архитекторами становятся сразу после окончания учебного заведения. Как Вы считаете, ждет ли архитектуру ПО подобное будущее? Начнут ли учебные заведения выпускать архитекторов ПО, которые сразу готовы применять полученные знания на практике?

Даже в индустрии гражданского строительства никто не даст крупный проект вчерашнему студенту. Помимо 4-5 лет обучения и профессиональной подготовки, необходима строгая профессиональная сертификация, включающая определенную стажировку и дополнительные экзамены, принимать которые будут компетентные органы. Точно такая же эволюция, как мне кажется, ждет и инженерию ПО, но об этом еще рано говорить. Так что — нет, я не думаю, что когда-либо наступит тот момент, что — едва выпустившись, вчерашние студенты смогут сразу же приступить к проектированию больших систем, предназначенных для решения критически важных задач. Но я думаю, что пути развития для них станут более четкими, структурированными, подобно моделям, существующим в других инженерных дисциплинах.

Вы внесли огромный вклад в разработку Cost-Benefit Analysis Method (CBAM) -метод расчета экономической эффективности архитектурных решений при выборе подходящей архитектуры, реинжиниринговых путей или устранения технических долгов (technical debts). Другими словами, это подход, ориентированный на прибыль, что очень ценно с позиции бизнеса. Как бы Вы охарактеризовали текущий уровень внедрения CBAM? Какие новые тренды Вы заметили с момента его создания? Был ли метод улучшен после «тестирования» в реальной жизни?

Метод CBAM не внедрился так широко, как ATAM и QAW. Мне кажется, индустрия еще не была к нему готова, когда он появился впервые (лет десять назад). Сейчас же в нашей индустрии все больше внимания обращают на финансовые последствия архитектурных решений. Поэтому организации, где есть хорошее понимание архитектуры ПО, сейчас намного чаще внедряют и интегрируют СВАМ в свою практику. Метод не сильно изменился со времени своего появления, но пора подумать и об улучшенной версии. Например, мне кажется, если компании готовы собирать необходимые данные, реальной становиться возможность напрямую связать архитектурные решения с финансовыми последствиями.

На протяжении последних лет мы наблюдали существенный сдвиг в сторону практик Agile в SDLC. Как Вы думаете, насколько Agile влияет на методы архитектуры ПО? Существует стереотип, будто в командах, использующих Agile, не нужен архитектор ПО, потому что они самоорганизованы. В то же время, в реальности мы видим случаи, когда сложные проекты без выделенного технического руководителя проваливаются. Это потому, что команды «неправильно» использовали Agile? Или необходимо переосмыслить роль архитектуры в Agile?

Каждый метод архитектуры программного обеспечения — по крайней мере, как я их понимаю и преподаю, — соответствует философии Agile. Не стоит документировать ради документации. Документирование необходимо для заинтересованных сторон и должно решать хотя бы одну из следующих задач: анализ, разработка или обучение. Не проектируйте всю архитектуру сразу (так называемый BDUF — Big Design Up Front): сосредоточьтесь на самом неясном аспекте и работайте над этим сегментом. Не анализируйте всю архитектуру сразу: сосредоточьтесь на зонах наивысшего риска, добавьте их в свой список работ, и решайте их в предстоящих спринтах.

Мы уже много лет практикуем гибкие варианты своих архитектурных методов, и они прекрасно работают.

Только в одном я отхожу от Манифеста Agile: я искренне убежден, что хорошие архитектуры НЕ «возникают» из самоорганизованных команд. Ни одного подобного случая я еще не видел. Зато я видел, как маленькие, целенаправленные группы идейных лидеров (на ум приходят Ричард Столлман и Линус Торвальдс — они, к примеру, сильно повлияли на архитектуру Linux) сознательно и скрупулезно создавали архитектуры. Agile не отменяет потребности в сильных лидерах.