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

Интервью с ведущим ученым 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 не отменяет потребности в сильных лидерах.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

програмісти не мріють бути Software Architect?
проблема більшості проектів 2002-2014рр, з якими довелось працювати —
відсутність Software Architect у складі команди. Це призводило до відповідних результатів :(

Median pay: $119,000
Top pay: $162,000
10-year job growth: 24.6%
money.cnn.com/...napshots/3.html
український ІТ бізнес банально “не доріс” до використання таких спеціалістів.
Є програмісти та начальники відділів (team lead), які виконують цю функцію.
В декого досить добре виходить.
Are You a Software Architect?
Some of the key factors that are often used to differentiate software architecture from software design and development include an increase in scale, an increase in the level of abstraction and an increase in the significance of making the right design decisions. Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole. While this may help to differentiate software development and software architecture, it doesn’t necessarily help to understand how somebody moves from development into architecture. Furthermore, it also doesn’t help in identifying who will make a good software architect, how you go about finding them if you’re hiring and whether you are a software architect.
www.infoq.com/...tware-architect

а зачем это сюда запостали? Что предлагает обсудить топикстартер? Тут ни одного слово от себя нету, только перевод интервью. Такое проще находит на редите, чем в форумах

реклама сертифицированного балабольства.
имею евонный сертификат есличо.
Рик Кацман мастерски эксплуатирует жировые запасы контор.

Что предлагает обсудить топикстартер?
Какая разница, сейчас в комментах кто-нибудь сделает зачетный вброс на тему эммиграции и/или ватников и тема пойдет как по маслу.

Подписаться на комментарии