Vitsliputsli

Confluence, обычно в нем ведут базу знаний, также там есть теги - labels.

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

Многие фронтендеры относятся к беку, как к некой обертке для работы с базой данной. Когда такие становится лидом команды и начинают диктовать свои требования беку, начинается ад, проект даже с простым беком превращается в нечто монструозное, разваливающиеся на ходу. Но, так как снаружи бек не виден, руководство считает, что дело в отдельных тупых бек-разработчиках, которые артачатся, не хотят работать и увольняются.
Судя по вашим фразам, вы скорее всего один из них. Так как уверены, что приложение - это то, что на фронте, что api - это хрень, которая завязана на отображении информации на фронте, что разработчики бека не нужны при разработке архитектуры и вообще пофиг, что они там делают, главное чтобы давали то, что хочет фронт.
Но, раз вопрос задан, значит сомнения вас посещают. Поэтому: приложение это не только фронт, а зачастую фронт это не самая сложная его часть. Бек - это не обертка над базой данных, и если вы поменяете значение в базе, это не значит, что к примеру, в потоковом вещании сменится кодек (вот, кому-то может и смешно, а мне в такой ситуации ни фига не было весело). С помощью API получают данные, поэтому не важно, что там у вас напроектировали дизайнеры, или как эти данные выводит фронт, API должен быть универсальным и не зависить от того как вы отображаете данные, поэтому, к примеру, бек может вам дать для получения данных несколько универсальных запросов, а не один специальный. В общем, все гораздо сложнее, и ваш вопрос как состыковать фронт и бек перерастает в вопрос как формировать архитектуру проекта, и как управлять командой.

Если у вас "четкое" разделение на фронт и бэк, значит, по сути у вас 2 технических проекта, взаимодействующих между собой. И у них не может быть одной и той же задачи, т.к. делают они разное.
Судя по остальному тексту, вы не декомпозируете задачи, отсюда и такие вопросы. Тогда, у вас 2 варианта, начать декомпозировать задачи на отдельные подзадачи, где будет отдельный исполнитель, можно прикинуть трудозатраты, указывать зависимости и т.п. К тому же, в redmine из коробки можно строить древовидную структуру задач. Тогда у вас появится хоть какой-то контроль и вы сможете планировать. Либо не заморачиваться, т.к. 1 или 2 задачи на ситуацию не повлияют, и пусть разработчики сами делят задачи и планируют.

Есть разные варианты даже в git-flow. В вашем случае, с учётом того, что вы делаете фичи, а затем выбираете, что пойдет в релиз (не очень понятно как вы формируете спринт при этом), ветка develop вам по-сути не нужна. Ветка develop предназначена для интеграции разных фич и проверки их совместной работы, в вашем случае это откладывается до финального тестирования релиза. Такой путь даёт гибкости, но может увеличить время финального тестирования, оправдан для несложных проектов и/или проектов с действительно слабым зацеплением, но даже в этом случае требуется постоянный контроль со стороны тимлида.