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

Вообще этот подход можно принять за аксиому разработчика в компании и пиарить как внутри компании так и наружу. Но не всем оно надо.  И не всем хочется торчать в одной предметной области долго. Если переходить к самому скраму, то там команда начинает участвовать в проекте с момента постановки задачи. И включают мозги с самого начала, пытаясь придумать архитектуру и запланировать работы. Такой подход кажется много дороже, т.к. в одно время можно держать только 1 проект + мелкие баги и что-то с беклога, а сотрудники должны заменять друг друга на ролях.

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

+1, нужно явное выделение времени на изучение предметки

Все-таки архитектор решения не должен спускаться на уровень абстракций в коде, прописывать буквально набор классов, полей, набор состояний.
Проблема в этом месте.

Конечно, пусть кодом разработчики занимаются. Солюшен должен аргументированно рассказывать чем один API лучше другого

В ЯД есть программисты, которые в той или иной мере изучают предметку. Но для этого их надо уметь в неё погружать. Если им правильно преподнести блюдо, то в 80% случаев они начинают работать головой. Исключая Hardy, он предметку из тебя выпытывает пояльником и утюгом. =D
Делятся они явно по уровню потенциала. Ребята с потенциалам пытаются разобраться в проблеме (зачастую даже просто для себя), а те, кто потенциал имеют невысокий (те самые 20%), просто пишут код и смотрят, что получится.
Также я вспомнил ещё один момент. Большой проблемой было отсутствие фидбека после выкладки проектов на прод. В командах всегда знали о багах, но понятия не имели о том, как продукт вышел в свет, сколько заработал какие отзывы оставил.

У людей нет метрики, к которой им надо стремиться. Нет понимания успешно они выложили продукт или нет. Они не видят, как растёт их детище и начинает становится продуктом, которым можно гордиться. Тут кстати стоит вспомнить принципы Эдвардса Демпинга.

Но всё это - проблемы управления, а не разработки.

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

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

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

Вот это очень дельный совет, спасибо.

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

Если предментная область специфичная, нишевая, и разработчик видит, что время, которое он конвертирует в знание в этой предметной области никак не окупится в будущем, а завтра снова в бой и новый проект и про вчерашний он никогда больше не услышит, то здесь мало что поможет. Возьмите тех же 1с-ников или сапёров. Разработчики? Разработчики. Специфичная область? Специфичная. И без понимания предметной области там мало что сделаешь, и ничего, учат, вникают, потому что знают, что и завтра и после завтра заниматься тем же самым, и будут применять полученные знания, конвертируя их в деньги. А пытаться заставить абстрактного разработчика прочитать и вникнуть предметную область для выполнения разовой задачи, не продуктивно, тут только если подсаживать к ним человека, который "в теме", даже если разработчик из этого человека так себе.

+

А как они без понимания предметки тестируют? Или QA вне команды?

Я даже встречал такое (qa оторванный от предметной области и бизнеса).
Лид qa подаёт руководителю отчет - багов нет. Потом проходит процедура приемо-сдаточных испытаний. Процент прохождения функциональных тестов - 20%.

В духе: кнопка жмется, файл создаётся, внутри - мусор о начала до конца с точки зрения предметки.

Ну тут можно с чистой совестью дрючить QA-лида

Наверно у вас был не скрам, а «скрам, но» (scrum, but), судя по проблеме. В скраме программистам дают бизнес задачу, они сами погружаются на этапе оценки в проблему и обсуждают все (в том числе с аналитиками) от уровня бизнес постановки до реализации чуть ли не в классах. [и только после этого оценивают]. А проблема, похожая на вашу, на моем опыте часто возникала, когда на словах декларируется скрам, а по сути программистам без объяснений спускается 500-страничное ТЗ и пилится по задачам. Ну да, нормальный программист он ленивый и будет читать не весь документ а только нужную часть.

Лечится возвращением к основам — адекватный backlog груминг, планирование и обзоры спринта всей командой с заказчиком и обратной связью.

Либо сажайте аналитиков вместе с программистом писать код за одним монитором.  Хотя бы 50% времени. То есть увеличиваем время работы аналитиков.