Co mam zrobić, gdy lider mojego zespołu łamie schemat bazy danych w związku z wydaniem?

Mój lider zespołu ma ten okropny nawyk zmanipulowania schematem bazy danych i wprowadzania zmian, które spowodowałyby poważne uszkodzenie bazy kodu (bez konsultacji ze mną, w jaki sposób zmiany wpłyną na bazę kodu).

Normalnie po prostu bym się z tym pogodził, ale mamy termin za 2 tygodnie, a dzieje się tak odkąd zacząłem półtora miesiąca temu. Zostałem zaangażowany, aby przyspieszyć rozwój projektu.

Z uwagi na termin, który spędzam już ponad 60 godzin tygodniowo, i tak naprawdę nie mam już energii, aby sobie z tym poradzić (próbowałem już na różne sposoby). Jesteśmy tylko 2-osobowym zespołem, a oprócz codziennej zmiany bazy danych, niewiele wniósł on w sensie faktycznego rozwoju (kodowania).

Obecnie mam wrażenie, że wykonuję całą pracę, a ponadto muszę „naprawić” to, co psuje jego zmiany.

Jak sobie z tym poradzić? Rozmawiałem już z naszym menedżerem o jego braku wysiłku w dziale rozwoju. Był tam 6 miesięcy dłużej niż ja, ale napisałem 95% kodu, kiedy wykluczasz potworność bazy danych w 5. normalnej formie, którą „przyczynił”.

Jakieś sugestie?

Sekcja zwłok:

W piątek rozmawialiśmy z menadżerem i wyraziłem swoje obawy. Doprowadziło to do trochę konfrontacji, ale ogólnie czułem, że kierownik był po mojej stronie. Więc przynajmniej mamy teraz zamrożenie danych, zobaczmy, jak to wygląda.

„Termin upływa za dwa tygodnie; jeśli chcemy go zrealizować, musimy zamrozić schemat”.

Rozmowa z kierownikiem ORAZ programistą na tym samym spotkaniu:

„Zmiany w bazie danych i kodzie muszą pojawiać się jednocześnie. Jeśli zmienisz bazę danych, musisz także zmienić i przetestować bazę kodu. W przeciwnym razie przesyłasz uszkodzone zatwierdzenia, co jest niedopuszczalne, jeśli mamy dotrzymać terminu. Nie będę już naprawiać kodu złamane przez twoje zobowiązania, po prostu wycofam zmiany i zostawię Ci wiadomość e-mail, ponieważ nie mogę zbadać i naprawić problemów poza pracą, do której mnie przydzielono i nadal oczekuję dotrzymania terminu ”.

Znacznie trudniej, jeśli nie masz planu testów ...

Będziesz musiał być bardziej zdecydowany i upewnić się, że wkrótce (tak jak wczoraj, przedwczoraj lub w zeszłym miesiącu) zdecydujesz się na schemat i pójdziesz naprzód. Nie ma rozsądnego sposobu, aby kontynuować tworzenie aplikacji z bazą danych, która jest ruchomym celem.

Musisz się z nim skonfrontować i wyjaśnić, jak jego zmiany wpływają na bazę kodu, a tym samym na linie czasu projektu. Przekonaj go, że musi rozważyć wpływ swoich zmian przed ich wprowadzeniem. Spraw, by zgodził się również w obecności swojego przełożonego na fakt, że będzie odpowiedzialny za wszelkie opóźnienia spowodowane przez takie zachowanie

Jeśli kierownik zespołu nie jest rozsądną osobą (a on / ona nie brzmi rozsądnie z twojego opisu swojego zachowania), porozmawiaj ze swoim przełożonym i wyjaśnij mu, że nie dotrzymasz terminu z tym, co się dzieje. Poproś go, aby zajął stanowisko i upewnił się, że lider zespołu jest tego świadomy, organizując spotkanie, na którym kierownik określa oczekiwania.

Powinieneś także popchnąć swoją sprawę dotyczącą braku wkładu lidera zespołu w rozwój. Oba problemy muszą zostać rozwiązane, aby projekt odniósł sukces.

Będziesz musiał wymusić na swoim zespole pewne ograniczenia, ale gra na tym stanowisku może być trudna.

Przydatnym sposobem rozwiązania tego problemu może być przyjęcie bardziej rygorystycznej udokumentowanej kontroli zmian. Możesz w to zagrać, nalegając, aby w tej chwili zmiany doraźne zagrażały twojej zdolności do zarządzania aktualizacjami systemu w sposób, który nie ma nieprzewidzianych, a termin zagrażających konsekwencji (co jest prawdą). Dlatego nalegaj, aby wszystkie zmiany musiały zawierać dokumentację przedstawiającą proponowaną zmianę i jej wpływ na cały inny kod i struktury. Będziesz zaskoczony, jak bardzo to zmniejszy liczbę wprowadzanych zmian :-)

Czy przeprowadziłeś retrospektywę z zespołem? Jeśli nie, przytrzymaj jeden. Kiedy to zrobisz, zidentyfikuj nieplanowane zmiany w bazie danych (problem z). Określ koszty ponoszone przez ciebie i innych w odniesieniu do ryzyka i jakości życia zawodowego. Ciągła praca przez 60 godzin tygodni nie jest zrównoważona. Jeśli nie jesteś w stanie utrzymać tempa rozwoju, nie postępujesz zwinnie.

Czy robisz także TDD (testowanie testowe) czy zautomatyzowany test funkcjonalny / regresji? Jeśli tak, zmiany w bazie danych powinny spowodować zepsute testy. Powinno to pomóc w rozwiązaniu problemu i zidentyfikowaniu kodu, który należy zaktualizować.

W takim przypadku kierownictwo zespołu nie jest „ zbyt zwinne ”, kierownictwo zespołu jest „ zwinnym kowbojem ”. Zrób retrospektywę, dowiedz się, co poszło nie tak. Nadaj mu wysoki priorytet, a następnie zajmij się nim podczas następnej iteracji. To powinno przywiązać twojego zwinnego kowboja !!!

Czy rok temu nie było z tobą takiego samego problemu? „ Lider mojego zespołu mówi: A. Właściwość = A. Właściwość; jest w porządku ”. Wygląda na to, że qustion został zbanowany, ponieważ nie widzę go w historii komentarzy. W każdym razie chodzi o:

Jeśli czujesz, że wszyscy liderzy twojego zespołu robią ci bałagan mając zaledwie połowę swojego doświadczenia, prawdopodobnie znajdziesz pracę bez niej . Sugerowałbym, aby spróbować stać się liderem jako kolejną opcją, ale gdybyś był w stanie to zrobić, już zaoferowano ci to.