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.
źródło
Odpowiedzi:
Pozwólcie mi przez chwilę grać w adwokata diabła:
Lead dev lubi prototypowanie, ponieważ specyfikacje są rzadkie. To chyba dobra rzecz; tak działają sklepy iteracyjne.
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ń.
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.
Może to być odpowiednie w małym, iteracyjnym sklepie.
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.
źródło
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
źródło
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ą.
źródło
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.
źródło