Demian Smith

При реконфигурировании команды программистов, полезно проводить аналогию со строителями. Это достаточно наглядно. Например, с кафельщиками. В вашем случае, есть проект - это квартира. И есть один кафельщик, который не справляется в срок. Ему нужна помощь. Можно дать ему еще одного кафельщика в помощь. Дальше, если они работают в одной комнате, им прийдётся договариваться между собой. Как минимум, первому кафельщику придётся потратить время на то, чтоб объяснить воторому план работ, который тот держал в голове. Часто это занимает крайне много времени. Идеальный вариант - поместить кафельщиков в разные комнаты, тогда им не прийдётся договариваться и, скорее всего, работа пойдёт быстрее.

Еще можно узнать у вашего кафельщика, может ему нужен чуть менее квалифицированный помощник? Может лучше нанять кого-то, кто будет мешать цемент? Например, заниматься администрированием или миграциями.

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

В общем, я бы поговорил с бэкендером и узнал, что его бесит на проекте.

Судя по тому что вам нет дела до того как идут дела у ваших коллег, ваша команда не преследует общую цель.

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

1. Поговорить со скрам мастером о том, что вас беспокоит качество стендапов. Кстати, раз уж ваша компания взяла курс на скрам, то скрам мастер - это тот человек, к которому следует обращаться со всеми организационными вопросами
2. Выразить своё недовольство стендапами во время ретроспективы. Возможно, вас поддержат коллеги и это будет началом перемен к лучшему. Кстати, ретроспектива, - это специальный ритуал скрама во время которого нытьё только приветствуется
3. Самый конструктивный путь, как по мне, - это прочесть Scrum Guide (https://www.scrumguides.org/docs/scrumguide/v2017/... - 26 несчастных страниц) и быть кравчиком, который понимает назначение артефактов скрама и может помочь компании в эффективном внедрении этого фреймворка

Успехов!

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

Но если в рамках рефакторинга программист коммитет больше 20 файлов за раз, то есть вариант что он не видит всей картины, поэтому пилит "супергибкую архитектуру". В этом случае, можно сесть вместе с разработчиком и составить майндмеп всех элементов будущей системы и связей между ними. Это будет полезно как для разработчика, так и для менеджера проекта.