ApeCoder

Есть например, https://www.scaledagileframework.com/
https://www.scrum.org/resources/online-nexus-guide

Можно ещё и поискать по словам project interdependencies найдется много статей про управление зависимостями между проектами. В каком-нибудь PMBOk наверняка что-то такое есть

Невозможно сказать без уточнения:
Какие последствия если зафакапить дедлайн?
Какие последствия если выбор будет неправильный?
Какая цена изменения решения на другое потом?

Если кто-то умеет от пропуска дедлайна лучше решить как-то потом переделать. Если кто-то умрёт от неправильного решения лучше профакапить дедлайн.

Можно ли как-то подготовиться к замене решения на верное?

Можно посмотреть, например openUP фазу inception и шаблон для vision. Например, тут www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/co...

Про это написаны книжки и статьи. Например, вот.

Оценка это не обязательство, а предположение. Она имеет вероятностный характер ("скорее всего это займет неделю, не меньше 3 дней но не больше года").

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

Я бы советовал написать план выполнения задачи и тестирования, подумать о том что ещё может сломаться и тестирования этого (регрессионное тестирование) и узнать мнение коллег (они могут подсказать что упущено). В SCRUM, например в планировании участвует вся команда.

Ещё я бы советовал гуглить на английском перед заданием таких общих вопросов - скорее всего вы найдете более качественный контент чем сам ответят тут. Например поищите approaches for software estimation.

Программисты не имеет доступа к данным пользователя. Администраторы имеют ограниченный доступ. Разработка ведётся на тестовых обезличенных данных. Если случается проблема требующая доступа к продакшн работа производится совместно программистом и администратором под контролем последнего.

Если правом в том как вводить людей в курс дела, то новому программисту даются сначала более лёгкие задачи типа исправления простых ошибок потом более сложные пока он не понимает принятый способ работы и на. Code review не убеждаются что он все перенял.

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

Минусы - теряется фокус команды на цели спринта.

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

Учитывать на метко ошибались в прошлом. См например тут https://habr.com/post/186410/ можно просто учитывать текущий коэффициент ошибки.

Многие рекомендуют постоянные команды. Т.е. фича тим не собирается под фичу, а на команду назначается фича. После разработки фичи команда остается той же просто ей дается другая фича.

Можно делать "внутренний опернсурс" - допустим у вас компонентные команды, но при этом одной команде понадобилась фича в компоненте другой команды. Она может предложить патч для этого компонента, а другая команда рассмотрит его, накатит на компонент либо отвергнет.

см также
https://www.thoughtworks.com/mingle/scaled-agile/2...
www.discussagile.com/blog/dependency-management-in...
https://www.scaledagileframework.com/value-stream-...

Чем не подходит trello именно для этой задачи - вроде на доске должно быть видно кто что делает?

В-общем, есть продукты специально для программистов, которые объединяют управление задачами, code review, планирование и прочее (github, jira, vsts, youtrack и так далее).

Для планирования там реализован автоматический подсчет разных характеристик и всякие графики. Кстати, по запросу "trello lead time" находится некоторое количество дополнений, который подсчитывают такие характеристики для trello.

С моей точки зрения, надо добиваться уменьшения малтитаскинга, потому, что в итоге он неэффективен. Например реализовать канбан с ограничением work in progress - тогда просто свободный разработчик забирает первую неназначенную задачу и работает по ней до конца. Тогда будет видно, сколько в среднем задача проходит через команду и можно будет сказать сколько задач в принципе можно реализовать за какое-то время.

Почитайте про скрам и канбан. Большинство инструментов их поддерживает.

Agile - это набор принципов и ценностей, а не конкретный процесс. Вам надо сначала выяснить какая конкретно инкарнация agile у вас внедряется (Scrum, Kanban, SAFe, XP).

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

Вот, например, описание что такое команды в SAFe.