Dlaczego nic nie możemy zrobić?

Pracuję w małym zespole, w średniej wielkości firmie, z której większość nie zajmuje się tworzeniem oprogramowania. Jestem najnowszym i najmniej doświadczonym programistą i przed rozpoczęciem nie miałem żadnego doświadczenia zawodowego ani akademickiego w zakresie oprogramowania, ale jestem bardzo zadowolony z tego, jak szanowany jest mój wkład i jestem wdzięczny za to, że zostałem poważnie potraktowany na tak wczesnym etapie kariery.

Mimo to wydaje mi się, że powinienem robić więcej przy tak dużej ilości czasu antenowego. Jako zespół wydaje się, że mamy problemy z wykonaniem zadań. Chciałbym być w stanie zasugerować coś, co poprawiłoby sytuację i myślę, że zostałbym wysłuchany, gdyby to był dobry pomysł, ale brakuje mi propozycji.

Do problemów, które mogę zidentyfikować, należą:

• Specyfikacja dostępnych zadań jest niewielka. Wynika to częściowo z faktu, że zarządzanie stanowi wąskie gardło i nie mamy pieniędzy ani ludzi, aby zaangażować się w wypracowanie szczegółowych wymagań tak bardzo, jak byśmy tego chcieli. Wynika to również częściowo z tego, że opracowywane przez nas oprogramowanie jest badawcze, a dokładna metoda nie jest jasna, dopóki nie zostanie wykazana i wykorzystana do ustalenia jej skuteczności.
• Lead Dev bardzo lubi to, co nazywa „prototypowaniem”, do tego stopnia, że ​​ostatnio zaczął nalegać, aby wszystko było „prototypowane”, co dla reszty z nas wygląda jak pisanie złego kodu i przekazywanie go modelarzom do zabawy. Nie jest jasne, czego oczekuje od tego ćwiczenia w wielu przypadkach. „Rzeczywista” implementacja cierpi wtedy z powodu jego nacisku, że dobra praktyka zajmuje zbyt dużo czasu od prototypowania. Nie zacząłem nawet rozwiązywać tej przekręconej logiki i nie jestem pewien, czy chcę spróbować.
• Oczekuje się, że modelerzy powiedzą nam wszystko o pożądanej metodologii z dokładnymi szczegółami, i jest absolutnie przekonany, że to, co wyszli, jest teoretycznie bezbłędne. Nie zawsze jest to prawdą, ale nie podejmuje się żadnych działań w celu naprawienia tej sytuacji. Nikt po stronie modelowania nie budzi żadnych obaw w ustrukturyzowany sposób, na który można zareagować, ani nie szuka wskazówek w zakresie stosowania najlepszych praktyk. Nic też się nie dzieje na temat ich pasywności.
• Próbowałem już wepchnąć TDD do zespołu, ale było to dla mnie trudne, ponieważ jest to dla mnie nowość i chociaż osoby z nadzorem nad moją pracą były skłonne to tolerować, nikt nie zyskał entuzjazmu. Nie mogę usprawiedliwić ilości czasu spędzonego na tarzaniu się, a nie na dokończeniu funkcji, więc pomysł na razie został porzucony. Obawiam się, że to nie zostanie ponownie odebrane, ponieważ nikt nie lubi, gdy mówi się mu, jak wykonywać swoją pracę.
• Mamy teraz serwer do ciągłej integracji, ale jest on głównie używany do uruchamiania wielogodzinnych testów regresji. Pozostawiono otwartą, że powinna ona również przeprowadzać testy pełnego zasięgu i testy integracyjne, ale w tej chwili nikt ich nie pisze.
• Za każdym razem, gdy podnoszę kwestię jakości za pomocą głównego dewelopera, otrzymuję odpowiedź na efekt „Testowanie funkcji A jest proste, funkcja B jest znacznie ważniejsza dla użytkownika, ale zbyt trudna do przetestowania, dlatego nie powinniśmy testować funkcji ZA'. Po raz kolejny nie zrobiłem żadnych postępów, próbując rozwikłać tę logikę.

.... uff. Kiedy tak to wyrażam, wygląda to znacznie gorzej, niż myślałem. Jak się okazuje, jest to wołanie o pomoc.

Pozwólcie mi przez chwilę grać w adwokata diabła:

Specyfikacja wykonywanych zadań jest niewielka ... Lead Dev bardzo lubi to, co nazywa „prototypowaniem”

Lead dev lubi prototypowanie, ponieważ specyfikacje są rzadkie. To chyba dobra rzecz; tak działają sklepy iteracyjne.

Oczekuje się, że twórcy modelu powiedzą nam dokładnie o pożądanej metodologii

To nie zadziała w sklepie iteracyjnym. Charakter iteracyjnego rozwoju polega na tym, że wymagania są często niekompletne. Iteracje są potrzebne do spełnienia wymagań.

Próbowałem już wepchnąć TDD do zespołu, ale było to trudne, ponieważ jest dla mnie nowością

To też nie zadziała; musisz zrozumieć technologię, zanim będziesz mógł ją ewangelizować. Ponadto w iteracyjnym sklepie ze skromnymi wymaganiami TDD może być zbyt dużym kosztem. Lepiej jest zachęcać do odpowiedniego zasięgu testów jednostkowych.

Mamy teraz serwer do ciągłej integracji, ale jest on głównie używany do uruchamiania wielogodzinnych testów regresji.

Może to być odpowiednie w małym, iteracyjnym sklepie.

Za każdym razem, gdy podnoszę kwestię jakości za pomocą głównego dewelopera, otrzymuję odpowiedź na efekt „Testowanie funkcji A jest proste, funkcja B jest znacznie ważniejsza dla użytkownika, ale zbyt trudna do przetestowania, dlatego nie powinniśmy testować funkcji ZA'

Wygląda na to, że twój sklep ma dość ścisłe ograniczenia czasowe; czy ci się to podoba, czy nie, jesteś związany tymi ograniczeniami.

Wygląda również na to, że pochodzisz z branży oprogramowania, która ceni sobie robienie rzeczy „we właściwy sposób”, a nie dopiero wprowadzanie ich na rynek. Nie ma w tym nic złego (w rzeczywistości jest to godne podziwu), z wyjątkiem tego, że pierwszy na rynku z wadliwym oprogramowaniem często wygrywa. To niesprawiedliwe, ale tak właśnie jest.

Tutaj skupię się na prototypowaniu

głównym problemem związanym z prototypami jest to, że mają one służyć jako dowód koncepcji

jeśli jednak nie możesz dalej budować prototypu i musisz odbudować produkt końcowy od podstaw, równie dobrze możesz nie zbudować prototypu i zmarnowałeś swój czas na jego budowę

radzę Twojemu zespołowi uzyskać pewną jakość i elastyczność tych prototypów. Wiem, że nie można stworzyć idealnych rzeczy za pierwszym razem, ale staram się być rozszerzalny na przyszłe wymagania

To są dobre odpowiedzi. Mogę tylko dodać, że „próba komunikowania się” jest w najlepszym razie niepewną propozycją. Zmiany w sposobie działania organizacji nie następują szybko. Kiedy to się dzieje, często przypomina to przypływ, w którym pęd rośnie z dołu i z góry. Będziesz szczęśliwszy, jeśli utrzymasz swoje oczekiwania na niskim poziomie i albo zaczekasz na szansę, by powiedzieć, jak to będzie zrobione, albo nie możesz się doczekać współpracy z inną organizacją.

Czy udało ci się zidentyfikować kogoś w firmie, który „łapie”, jeśli tak, to zaczep go i ucz się od niego jak najwięcej. Jeśli nie, zastanów się, zacznij uczyć się i rozwijać samodzielnie (dołącz do projektu Open Source lub uruchom własny projekt) i poszukaj miejsca, które może sprzyjać Twojemu rozwojowi.

Najgorsze, co może się zdarzyć, to zostać tam i nauczyć się, jak robić rzeczy w niewłaściwy sposób. Tak, należy podjąć pewien pragmatyzm, ale naprawdę wykwalifikowany zespół może robić rzeczy we właściwy sposób i nadal być na czasie z produktem wysokiej jakości. Wygląda na to, że twój obecny zespół nie ma tego, czego potrzeba i powinieneś zacząć szukać nowego.