Распределение функций между командой и Product Owner работает только тогда, когда достигается цель - поддержание постоянства скорости разработки по мере роста размеров системы. Иными словами, когда команда достаточно грамотна в Software Design. Именно об этом говорит принцип Agile Manifesto:

🔷 "Continuous attention to technical excellence and good design enhances agility."

Именно поэтому, на Snowbird Meeting присутствовал весь архитектурный бомонд того времени. Именно поэтому Agile был создан архитекторами.

Что произойдет, если команда недостаточно подготовлена по Software Design? Кодовая база будет загнивать, темпы разработки будут деградировать, команда утратит доверие со стороны Product Owner, и Product Owner начнет возводить защитные стены от команды, затягивая в свою зону ответственности все решения по системному инкременту. Иными словами, он начнет указывать команде не только то, "что" нужно сделать в User Story, но и "как" команда должна это реализовать. Т.е. возникнет ситуация, описанная в начале предыдущего поста.

Звучать это будет примерно так: "давайте пока поставим костыль, а потом исправим". Естественно, это "потом" никогда не наступит.

Команда тоже начнет возводить свою защитную стену, и начнет твердить, что все нужно сжечь и переписать. И возможно, команда даже уговорит Product Owner, и он выделит ресурсы, но через пару месяцев все снова сгниет. Потому что код или самоочищается, если команда знает Software Design, или загнивает.

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

В моем списке литературы приводятся 5 книг, без которых остается мало шансов организовать эффективную разработку и завоевать доверие Product Owner.

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