Что я делаю, когда руководитель моей группы нарушает схему базы данных, готовясь к выпуску?

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

Обычно, я бы просто жил с этим, но у нас есть крайний срок через 2 недели, и это происходит с тех пор, как я начал полтора месяца назад. Меня привлекли, чтобы ускорить разработку проекта.

Из-за крайнего срока я уже откладываю более 60 часов в неделю, и у меня действительно не осталось энергии, чтобы справиться с этим (я уже пытался в некоторых отношениях). Мы всего лишь команда из 2 человек, и, помимо ежедневного изменения базы данных, он не внес большого вклада в смысле фактического развития (кодирования).

В настоящее время я чувствую, что делаю всю работу, плюс мне приходится «исправлять» то, что он ломает своими изменениями.

Как с этим справиться? Я уже говорил с нашим менеджером о том, что он не работает в отделе разработки. Он был там на 6 месяцев дольше, чем я, но я написал 95% кода, когда вы исключили 5-е чудовище базы данных нормальной формы, которое он «внес».

Какие-либо предложения?

Посмертное:

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

«Крайний срок составляет две недели; нам нужно заморозить схему, если мы собираемся ее использовать».

Разговор с менеджером и разработчиком на той же встрече:

«Изменения базы данных и кода должны появляться одновременно. Если вы изменяете базу данных, вы также должны изменить и протестировать базу кода. В противном случае вы отправляете нарушенные коммиты, что недопустимо, если мы хотим уложиться в срок. Я больше не буду исправлять код». нарушенный вашими коммитами, я просто откажусь от изменений и оставлю вам записку по электронной почте, потому что я не могу исследовать и устранять проблемы за пределами назначенной мне работы и все еще ожидаю соблюдения срока ».

Гораздо сложнее, если у вас нет плана тестирования ...

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

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

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

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

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

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

Вы провели ретроспективу с командой? Если нет, держите один. Когда вы это сделаете, определите незапланированные изменения в базе данных как проблему. Укажите стоимость для вас и других в отношении риска и качества трудовой жизни. Постоянно работать 60 часов в неделю невозможно. Если вы не способны поддерживать темп своего развития, вы не занимаетесь гибким движением.

Кроме того, вы проводите TDD (тестирование по разработке) или автоматизированный функциональный / регрессионный тест? Если это так, изменения в базе данных должны привести к неудачным тестам. Это должно помочь устранить последствия и определить код, который необходимо обновить.

В этом случае ваша команда не является « слишком проворной », ваша команда - « проворной ковбой ». Проведите ретроспективу, определите, что пошло не так. Приоритезируйте это высоко, затем обращайтесь к нему во время следующей итерации. Это должно быть верёвкой у твоего ловкого ковбоя !!!

Не было ли такой же проблемы с тобой около года назад? « Лидер моей команды говорит A.Property = A.Property; хорошо ». Похоже, что qasting был забанен, потому что я не вижу его в истории комментариев. Во всяком случае, дело в том:

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