Женя, аджайл не разделяет на слои. Основное требование к юзерстори - вертикальность, то есть простроенность от бизнес-уровня до запросов к БД

@Stanta Просто сейчас складывается впечатление, что у вас ограниченный опыт и вы пытаетесь его навязать.

да, что-то я заигрался..  пойду писать свой унылый блокчейник

безусловно, Вы правы ).

@Stanta Я думаю он полезный и имеет много хороших сторон, но в некоторых ситуациях он неприменим, в других можно обойтись и без него. Где-то работает всё вообще по-другому и т.д.

“Архитектор” внутри команды суть просто старший разработчик. Потребность в роли архитектора возникает на стыке команд, когда их уже десяток или больше. Работа в координации команд и определении общего вектора системы как суммы решений на уровне команд.
Роль архитектора, который год составляет ТЗ уже устарела и рынку действительно часто не нужна (кроме случая больших fix price проектов)

Юзерстори - это agile appliance.
Давай поговорим про agile epic fail, который привёл к "In 2011, though, Kent Beck published his “beyond agile manifesto”"

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

https://www.slideshare.net/KentBeck/to-agility-and-beyond
Это слайды из презентации Кента Бека 2010 года

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

Угу, я и про твой опыт.

А меня Евгений ну прямо чуть сарказмом не покрошил на кучу жуниоров за аналогичное мнение ))

О, Фил, привет!
Да, но нет. Спецификация интерфейсов спасает.

"чё думать, делать надо" :)
Agile был создан как способ адаптации к среде команды из взрослых дядек.
Если мы берём "команду средним возрастом 25 лет"  - и говорим "гибкость и Agile" - то вместе с этим или мы им помогаем освоить (Validated learning) несколько десятков жизненных понятий, или согласны с фейк-результатом.

Популярные agile-практики - "дожить до годового бонуса" и "да чё, разберуться. Если нет - кинем к ним архитектора".

Не, спецификация интерфейсов не спасает. Так как кто-то должен принять решение - а по каким принципам вообще взаимодействуют сервисы и продукты отдельных команд. Благо паттернов очень много.
Я уж не говорю о том, что кто-то должен сделать DDD по всему большому проекту, например. С учетом развития бизнеса на ближайшие лет 10

ну сеньор  - он еще не архитектор. Нужен бизнес-опыт для этого. Координация - да, это больное место. Интерфейсы и Вики нас спасает.

Ну, что бы появилась общая  wiki на несколько команд - уже нужен архитектор.

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

Фасилитатора мало, обычно минимальная роль - зонтичный аналитик