Dlaczego nic nie możemy zrobić?

9

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.

Tom W.
źródło
5
Jak dobra jest firma w wypychaniu oprogramowania, którego klient lubi i co lubi? Innymi słowy, czy zespół osiąga dobre wyniki, mimo że nie wierzysz, że proces jest gwiezdny?
Robert Harvey,
@Robert Harvey - Trudno mi ocenić. Produkty są wyjątkowo niszowe, a my (programiści) otrzymujemy mieszane wiadomości. Z jednej strony nowi klienci na przełomowych rynkach przebijają produkt bardziej, niż pierwotnie zakładaliśmy, i w konsekwencji znajdują usterki, które nie wydają się im przeszkadzać, ponieważ wyjaśniamy dlaczego i szybko je naprawiamy. Z drugiej strony, niektórzy duzi klienci instytucjonalni są nieufni i zaczynamy się łudzić, że wielokrotnie zmieniamy model. Zespół programistów jest obecnie jednym z nielicznych, nawet w firmie, więc wyglądamy dobrze w tej chwili .
Tom W
1
Chciałbym uzyskać od klientów jak najwięcej informacji zwrotnych na temat sposobów uzgodnienia podstawowego działającego „modelu” i spróbować go trochę zestalić. Zmiana modelu może być frustrująca dla klientów, ale jeśli jest to nowe, najnowocześniejsze oprogramowanie, to idzie w parze z terytorium.
Robert Harvey,
Dobre pytanie. Zauważyłem, że nawet przy otwartej publiczności prawdziwa zmiana jest trudna, chyba że można ją zobaczyć w praktyce. Radzę najpierw wypróbować metody zwiększenia produktywności, a następnie zademonstrować je zespołowi. Ćwicząc, możesz przyspieszyć rozwój TDD niż pisać / debugować / powtarzać.
Mike B,

Odpowiedzi:

19

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.

Robert Harvey
źródło
Myślę, że będziesz musiał podejść do tego z perspektywy „długu technicznego”. Każda firma dokonuje oszacowań czasu; zakładając, że twoje są już całkiem dobre, zacznij budować nadwyżkę od 10% do 20% w swoich szacunkach czasowych na refaktoryzację i szkolenie, i spraw, by się trzymało.
Robert Harvey,
Kontynuować; Iteracyjny rozwój to nazwa gry, masz rację. Problem w tym, że iteracja kończy się, zanim się faktycznie skończy, ponieważ otrzymujemy niejasne frazesy od modelarzy dotyczące tego, czy to, co zakodowaliśmy, jest naprawdę poprawne. Nikt nie może zidentyfikować żadnych błędów, więc co zrobiliśmy statki. Sześć miesięcy później okazuje się, że jest źle. Ja lubię być w stanie wskazać, że modelarze muszą mieć jędrniejsze kryteria testu przeciw, ale potem znowu, nie jest to ich zadanie, aby tak powiedzieć?
Tom W
2
@Tom: Dopóki nie nalegasz na testowalne specyfikacje od modelarzy, zawsze mogą powiedzieć Twojemu zespołowi, że źle to zrobili. Jeśli zamierzają pociągnąć cię do odpowiedzialności za tworzenie wyników z ich modelu, musisz pociągnąć ich do odpowiedzialności za dostarczenie testowalnych specyfikacji , abyś mógł zadeklarować sukces. Każda specyfikacja powinna zawierać w sobie jakiś test „iść, nie iść”, abyś ty i klient (lub modelerzy) mogli wspólnie uzgodnić, że test został zaliczony, bez podlegania interpretacji.
Robert Harvey,
Całkiem dobrze. Niestety, być może zobowiązujesz mnie do przyznania się do czegoś, czego nie chciałem - że brakuje nam kompetencji. Jest to ogólnie widoczne, ale szczególnie w przypadku modelarzy. W niektórych aspektach kładziemy nacisk na twarde specyfikacje, ale nadal są one błędne. Są naukowcami i mówiąc z doświadczenia, naukowcy mają tendencję do traktowania kodu jak eksperymentu - korygowania błędów w miarę postępów. Dla biznesu nie jest to po prostu wystarczająco dobre i należy oczekiwać profesjonalizmu, aby to rozpoznać.
Tom W
Nie ma nic złego w traktowaniu kodu jak eksperymentu; to część iteracyjnego procesu. Ale w końcu musisz się obejść, aby „ten kod akceptuje te dane wejściowe i oczekuje się, że wygenerują takie dane wyjściowe”. Do tego służą testy jednostkowe; stanowią część specyfikacji. Rozumiem, dlaczego chcesz robić TDD; wymusza na kodzie specyfikacje ... Ale potrzebujesz wsparcia ze strony kultury korporacyjnej, aby to zadziałało, a TDD ma w sobie coś z „religii”. Nie wszystko da się w ten sposób przetestować, więc w końcu być może będziesz musiał żyć z pewnym stopniem dyskomfortu.
Robert Harvey,
2

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

maniak zapadkowy
źródło
Właśnie od tego czasu staram się komunikować. Tak się składa, że ​​prototypy są często cenne i dostarczają nam niezbędnych lekcji na temat natury problemu. Jednak to, czy te wnioski zostaną wyciągnięte, jest pozostawione przypadkowi, a jakość wdrożenia zależy od tego, czy programista odtworzy zdobytą wiedzę z ich mózgu, a nie użyje prototypu do napisania specyfikacji. Główny deweloper mówi, że to drugie powinno się zdarzyć, a następnie nie zapewnia, że ​​tak się stanie.
Tom W
kiedy mówi, że chce prototypu, chodzi mu o minimalną działającą wersję i tak szybko, jak to możliwe. Będzie to fundament ostatecznej wersji. Problem z tym podejściem polega na tym, że młodsi deweloperzy (ogólnie) mogą pisać albo dobry kod, albo potrafią pisać szybko, ale rzadko mogą to robić jednocześnie.
Kevin,
2
Fred Brooks powiedział: „Napisz jednego, który wyrzucisz, i tak to zrobisz”, to tak samo dzisiaj, jak 40 lat temu.
mattnz
1

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ą.

Mike Dunlavey
źródło
1

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.

Michael Brown
źródło
„Czy zidentyfikowałeś kogoś w firmie, kto to„ dostaje ”? LOL
Kenzo