Що робити, коли мій керівник розбиває мою схему бази даних при появі релізу?

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

Зазвичай я б просто жив з цим, але у нас термін закінчується через 2 тижні, і це відбувається з моменту, коли я почав півтора місяці тому. Мене залучили, щоб прискорити розвиток проекту.

Через термін я вже вкладаю 60 годин на тиждень, і у мене справді не залишається енергії, щоб впоратися з цим (я вже намагався деякими способами). Ми є лише командою на 2 людини, і окрім щоденної зміни бази даних, він не зробив великого внеску в сенс фактичного розвитку (кодування).

В даний час я відчуваю, що я виконую всю роботу, плюс мені потрібно «виправити» те, що він порушує зі своїми змінами.

Як з цим боротися? Я вже говорив з нашим менеджером про його брак зусиль у відділі розвитку. Він був там на 6 місяців довше, ніж у мене, але я написав 95% коду, коли ви виключаєте жахливість бази даних 5-ї нормальної форми, яку він "сприяв".

Будь-які пропозиції?

Посмертне:

У п’ятницю ми мали дискусію з менеджером, і я висловив свої турботи. Це призвело до трохи конфронтації, але в цілому я відчув, що менеджер став на бік зі мною. Отож, принаймні, зараз у нас заморожені дані, давайте подивимося, як це відбувається звідси.

"Кінцевий термін - через два тижні; нам потрібно заморозити схему, якщо ми збираємось її вдарити".

Виступаючи з менеджером І розробником на одній зустрічі:

"Зміни бази даних та коду повинні з'являтися одночасно. Якщо ви змінюєте базу даних, ви також повинні змінити і протестувати базу коду. В іншому випадку ви надсилаєте розбиті коміти, що неприпустимо, якщо ми дотримуємося цього терміну. ​​Я більше не буду виправляти код порушений вашими зобов’язаннями, я просто відмовляюсь від змін і залиште вам повідомлення про електронне повідомлення, оскільки я не можу розслідувати та виправляти проблеми поза роботою, яку мені призначено, і все одно очікую дотриматись терміну ".

Набагато складніше, якщо у вас немає плану тесту ...

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

Вам потрібно зіткнутися з ним і пояснити йому, як його зміни впливають на кодову базу і, отже, часові рядки проекту. Переконайте його, що йому потрібно врахувати вплив змін, перш ніж здійснити їх. Також змусьте його погодитися в присутності вашого менеджера з тим, що він буде нести відповідальність за будь-які затримки, які він викликає такою поведінкою

Якщо керівник команди не є розумною людиною (і він / вона не звучить розумно з вашого опису його поведінки), поговоріть зі своїм менеджером та поясніть йому, що ви не дотримаєтесь терміну з тим, як все відбувається. Попросіть його зайняти позицію і переконайтеся, що керівник вашої команди про це знає, провівши зустріч, де менеджер встановлює очікування.

Ви також повинні висунути свою справу щодо відсутності вкладу вашої команди в розвиток. Обидва питання повинні бути вирішені, щоб проект став успішним.

Вам доведеться дотримуватися певної стриманості у вашій команді, але це може бути складно для того, щоб грати на своєму становищі в ній.

Корисним способом вирішення цього питання може бути прийняття більш жорсткого документально підтвердженого контролю за змінами. Ви можете відтворити це, наполягаючи на тому, що на даний момент спеціальні зміни ставлять під загрозу вашу здатність керувати оновленнями системи таким чином, що не має непередбачених наслідків та загрозливих термінів наслідків (що правда). Тому наполягайте на тому, що всі зміни повинні мати документацію, яка показує запропоновані зміни та їх вплив на всі інші коди та структури. Ви будете вражені, наскільки це зменшить обсяг змін, що відбуваються :-)

Ви провели ретроспективу з командою? Якщо ні, утримуйте її. Коли ви це зробите, визначте незаплановані зміни (спілкування з) в базі даних як проблеми. Вкажіть вартість для вас та інших щодо ризику та якості трудового життя. Постійно працюючи 60 годинних тижнів не є стійким. Якщо ви не в змозі підтримувати свій темп розвитку, ви не рухаєтесь.

Крім того, ви робите TDD (тестова розробка) або автоматичний тест на функціональність / регресію? Якщо так, зміни в базі даних повинні спричинити зламані тести. Це має допомогти вирішити вплив та визначити код, який потрібно оновити.

У цьому випадку керівництво вашої команди не " занадто спритне ", а керівництво вашої команди - " спритний ковбой ". Проведіть ретроспективу, визначте, що пішло не так. Поставте пріоритет на високому рівні, а потім зверніться до нього під час наступної ітерації. Це повинно бути мотузкою у вашого спритного ковбоя !!!

Чи не було з вами те саме питання близько року тому? " Мій керівник каже, що A.Property = A.Property; добре ». Здається, що qurance було заборонене, тому що я не бачу цього в своїй історії коментарів. У будь-якому разі, справа в тому:

Якщо ви відчуваєте, що всі ваші керівники команд зіпсують вас, маючи майже половину свого досвіду, ви, мабуть, знайдете роботу без такої . Я б запропонував спробувати і стати ведучим як інший варіант, все-таки, якби ви могли, вам уже запропонували це зробити.