Способность реализовать фичу в проекте

Там, где я работаю сейчас, официально считается, что "один разработчик - одна фича". Что из этого следует:

С точки зрения руководства:

Полная взаимозаменяемость разработчиков. Раз любой разработчик способен реализовать данную фичу сверху донизу, значит и относиться к ним можно как к одинаковым инструментам. Если один разработчик говорит, что реализация потребует много времени, то можно найти другого, который согласится сделать побыстрее. Как следствие, у многих отпадает желание в чём-либо разбираться - ведь завтра могут перебросить на совсем другой проект.

С точки зрения разработчика:

Разработчик должен не просто одинаково, а одинаково хорошо разбираться во всех технологиях используемого стека (СУБД, .NET/Java, JavaScript, HTML, CSS). На практике такое невозможно достичь (правило 80/20 работает в обе стороны, то есть оно позволяет некоторые познания в разных областях, но оно же говорит о специализации только в одной области). Можно найти много причин и объяснений этому явлению, как технических, так и чисто психологических. Следствием являются посредственные, неоптимальные реализации, с большим объёмом дублирующегося кода/разметки/CSS (то, что при "послойной" разработке было бы собрано в одном месте), или, что ещё хуже, с кодом, который делает примерно одно и то же, но у каждого разработчика по-разному.

Для меня наиболее приемлемо выглядит промежуточный вариант разработки:

• есть специалисты, разрабатывающие основу UI и бэк-енда; UI должен быть максимально unobtrusive, как говорят англоязычные разработчики; именно они начинают работу над проектом, готовят инфраструктуру (фреймворк)
• есть универсалы, которые подключаются к работе чуть позже, именно они реализуют функционал ("фичи", бизнес-логику, или как вам больше нравится это называть), используя готовый интерфейс и бэк-енд; они должны работать вместе со специалистами: получать информацию о том, как правильно реализовывать задуманное и давать информацию о том, чего во фреймворке им не хватает или что реализовано не так (развитие фреймворка), то есть работать не по правилу "один человек - одна фича"
• далее, при продолжении разработки, когда фреймворк стабилизировался, и вся команда знает "правила игры" (то есть как правильно работать с UI и бэк-ендом), специалисты тоже подключаются к разработке функционала (правило 80/20 позволяет это), а универсалы - к развитию фреймворка (они уже знают, что где реализовано, и примерно представляют, как им самостоятельно внести необходимые изменения, а хороший фреймворк должен позволять это делать легко и безболезненно)

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