ну если есть желание

просто писать код

то не должно быть грусти по поводу отсутствия новой лычки, а судя по темам на доучим потолок успешно двигается вверх.

ну это не так, я вам уже ответил выше. кто-то дорос сам, кто-то с помощью компании, эпам, и судя по статье софт сервис тоже, много вкладывает в развитие людей

ну компания с которой мы с вами сотрудничаем отлично с этим справляется, есть школа архитекторов которая по моему мнению является отличным курсом — рекомендую.

А по факту що таке «замовник»? Це ж не одна людина, не одна роль, і навіть не десять. І може виявитись, що говорити з рандомним клерком з боку замовника про останні матчі по бейсболу — це не робота архітекта, раптово.

Ну работа по выявлению стейкхолдеров и их важности это конечно не главная задача архитектора, но он должен понимать чьи требования важны, а чье не очень.

А збір і приорітизація quality attributes це дуже конкретна річ, яку не можна описати як «говорити із замовником» — бо буде як мінімум не зрозуміло з ким саме з боку замовника, про що і з якою метою.

тем не менее в статье так общими словами и описали

Всі говорять із «замовником»! ВСІ!

ну все ж зависит от типа проекта, но в общем случае не вижу в этом ничего плохого. Конечно если на продет есть архитектор и бизнес аналитик, то конечно они как правило должны закрывать бОльшую часть разговоров с заказчиком

ну я это ж и сказал.

надо отдельную статью писать короче, я понял уже :)
попробую дополнить, обязанности архитектора начинаются с выяснения какие архитектурные атрибуты больше всего важны для будущего решения. Проблема в том, что ПМ и БА не всегда фокусируются на сборе тех требования, которые могут быть важны для будущей архитектуры

«архитектором» в моих круга называется чел, который может спроектировать систему основываясь в первую очередь на технических знаниях, а не на том, как эффективно он сидит в коллах с заказчиком

сферическую в вакууме :) и не понятно то ли это, что хотел заказчик

Так думают в основном разработчики :) Может в статье не совсем раскрыта суть ПОЧЕМУ же умение разговаривать с клиентами так важно? Потому что в разговоре с клиентами вы понимаете не функциональные требования и ограничения, так называемые качественные атрибуты. Плюс умеете их приоритизировать. И это как раз то, что больше всего влияет на архитектуру приложения. Тех вид конечно тоже принимает архитектурные решения, да и в архитекторы идут в основном бывшие тех Лиды, но мало кто понимают насколько разная это работа

забавно читать этот камент от человека с тремя тайтлами

ну я про себя могу сказать, что в 2003 году, когда я поступал в универ «на программиста» о больших ЗП в ИТ я не слышал, и за ЗП шли тогда в юристов вроде как. Так что тогда шли в программисты в основном кто любил покодить ли просто ковырять компьютеры

это называется человек без детей зашел в тему :)

действительно, отправить ребенка школьника в чужую страну это всегда отличная идея! с какого класса предлагаете избавляться от них? с первого или до пятого подождать?

ну я бы не был так категоричен, на те же бюджетные авто тоже бывают скидки. Есть еще пакетные комплектации у немцев, которые выходят значительно дешевле наборных. На тот же Туарег было уже несколько акция на моей памяти. Процент-два вам могут сбросить почти везде (не знаю про тойоту).
В целом я бы рекомендовал не покупать совсем новую модель и дождаться хоть какой-то акции, потому что новые продают прям с максимальной маржей

ну можно рискнуть и взять в феврале-марте тачку прошлого года по последним скидкам, я так свою брал. К сожалению не со всеми моделями и марками это работает. Если хотите тойоту то надо ити на поклон дилеру, падать в ноги и молить продать вам авто без скидки, а за новые крузак по слухам еще и доплатить надо :)
В целом совет взять прошлое поколение или дорастайл это тоже отличный вариант, как правило детские болячки уже устранили и машины в конце жизненного цикла в целом будут надежнее чем в начале поколения. Но надо следить за рынком, потому как новое поколение выходит раз в 7 лет, а рестайлинг делают через 3-4 года.

есть скрам, который знает и понимает каждый джун, а есть какие-то методы проектного управления понятные только лишь опытному ПМу. Со скрамом как и с паттернами, ценность в общем словаре

Так и хочется написать, и чО?
Да, про скрам без инженерных практик (ХР) писал дедушка Фаулер еще в 2009ом году! martinfowler.com/bliki/FlaccidScrum.html
побуду капитаном очевидность и напомню почему все так любят скрам. Это самый простой фреимворк для построения итеративной разработки продукта, маленькие итерации скоуп который нельзя менять дают уверенность команды. Планирование и приоритизация дает ПО возможность управлять приоритетом выполнения задач, ретроспектива дает возможность улучшать процессы и самое главное — все в индустрии понимают как он работает, ты берешь человека с улицы и он сразу же вливается в процесс.
Есть ли смысл работы по скраму когда весь беклог проекта заэстимирован и скоуп и дедлаин зафиксированы? Есть. как сказано в статье это будет не скрам, но я готов поспорить что это может дать определенные преимущества связанные с итеративной работой и фидбеком, связанным с скрам церемониями

Когда

это ключевой вопрос. когда закончится тогда и можно будет вспомнить про классический ХП с командой равных опытных разработчиков вместе шагающих к общей цели

чтобы оно работало как планировалось, нужно строгое выполнение набора условий, труднодостижимое в реальном мире

собственно это проблема не только аджаила :) что бы что-то работало как планировалось надо следовать плану и знать что и как делать в различных ситуациях

Или войдут в штопор холиваров «Почему библиотека X а не Y, или фреймворк B а не С»

умение вести конструктивный диалог и приходить к консенсусу один из признаков настоящего синьора, но именно по этой причине я и написал что скорее всего два синьора будут работать медленнее чем один, потому что надо будет согласовать все вопросы по тому, какая библиотека и фреимворк круче

это не эффективно для заурядных задач которые уже поставлены «на рельсы» и надо «лабать»

Собственно это так и есть, его надо использовать для других задач

Потом не понятно как в двоем вести фикс багов, например?

а в чем проблема? для того, что-бы баг пофиксить надо сначала понять где зарыта проблема, тут как раз две головы могут помочь. Потом надо понять как его пофиксить ничего не поломав при этом, и опять же — вторая голова может и тут пригодиться

За XP и хакатоны

на всякий случай уточню что они никак между собой не связаны :)

Oleksandr вже гарно відповів про обмін контекстом та різні спецефічні знання у кожного сеньора. Якщо проект вже у відносно спокійному стані (саппорт та додавання нових насклядних фічей) та вся команда вже довго працюе и добре розумія архітектуру і технічні особливості то використовувати ПП постійно буде не зовсім доречно. Від себе я можу додати що ПП працюе найкраще якщо два розробнікі мають пріблізно однаковий рівень. Для роботи над складними завданнями два Senior Developer зазвичай створять рішення краще ніж поодинці, але це може зайняти ще більще часу