Czy (młodszy) programista powinien dążyć do usprawnienia procesów i praktyk w zespole programistów / IT?

Jestem młodszym programistą, który ma możliwość kształtowania procesów mojego zespołu, jeśli mogę uzasadnić zmianę i jeśli pomaga to zespołowi w wykonaniu pracy. To dla mnie nowe, ponieważ moje wcześniejsze firmy mniej więcej miały sztywno określone procesy pochodzące z zarządzania.

Mój zespół jest dość mały i nieco nowy (<3 lata). Brakuje im:

• dobrze zdefiniowane środowisko programowania / zarządzania pracą (jak scrum)
• silna własność produktu
• dobrze zdefiniowane role (np. pracownicy biznesowi wykonają testy ręczne)
• regularne spotkania standup
• skonsolidowany proces śledzenia problemów (mamy narzędzie, proces wciąż się rozwija)
• jednostkę, system, regresję lub zestaw testów ręcznych lub listę
• dokumentacja dotycząca logiki biznesowej i procesów
• baza wiedzy do dokumentowania wskazówek wewnętrznych i dotyczących klientów

Lista jest długa. Zarządzanie jest otwarte na wdrażanie ulepszeń, o ile wartość jest uzasadniona i pomaga wykonać najważniejsze prace (mianowicie rozwój). Podstawowym założeniem jest jednak przejęcie odpowiedzialności za wdrożenie, ponieważ nikt nie zrobi tego za Ciebie. Jest rzeczą oczywistą, że niektóre z powyższych projektów są nietrywialne, bez wątpienia czasochłonne i najwyraźniej nie są pracami rozwojowymi.

Czy warto (młodszego) dewelopera starać się robić powyższe w miarę upływu czasu? A może najlepiej „pozostać na swojej linii” i skoncentrować się na rozwoju oraz pozostawić zarządzanie definicją procesu i optymalizacją?

Jak dotąd dobre odpowiedzi, ale nie obejmują one wszystkich zasad.

Z mojego doświadczenia wynika, że ​​wiele osób po studiach ma fantastyczną wiedzę teoretyczną - znacznie lepszą niż ja lub wielu innych seniorów, którzy przez dziesięciolecia budowali oprogramowanie do życia.

ALE, a to duży ALE, ta wiedza nie jest ugruntowana w żadnym praktycznym scenariuszu. W prawdziwym świecie wiele z tych teorii się nie zgadza, a przynajmniej musi być przyjmowane z ogromnym ziarnem soli, ponieważ w praktyce okazuje się, że nie działa tak dobrze w scenariuszu z prawdziwego świata.

Przykład: aplikacja, nad którą pracowałem dawno temu, została zaprojektowana przez genialnego teoretyka OO, zaprojektowanego zgodnie z zasadami i teorią OO do T, z mnóstwem wzorów stosowanych wszędzie.

To był fantastyczny projekt oprogramowania.

Niestety spowodowało to koszmar produkcji i konserwacji. Baza kodu była tak duża i złożona, że ​​miejsc nie można było zmienić; Nie dlatego, że był wyjątkowo kruchy, ale ponieważ był tak złożony, nikt nie odważył się go dotknąć w obawie przed tym, co się wydarzy (pierwotny architekt / projektant był wykonawcą, który dawno już odszedł).

Działał również bardzo słabo, właśnie ze względu na wielowarstwową strukturę wzorców i bibliotek klas, które wymagały projektowania. Na przykład kliknięcie przycisku na ekranie, aby wykonać pojedyncze wywołanie bazy danych, spowodowałoby utworzenie kilkuset instancji obiektów i wywołań metod - wszystko w imię zapewnienia luźnego łączenia i tym podobnych.

Ten architekt był profesorem uniwersyteckim i napisał kilka książek na ten temat. Nigdy nie pracował jako programista przy komercyjnym projekcie.

Ludzie z praktycznym oprogramowaniem do budowania doświadczenia zdaliby sobie sprawę, do jakiego potworności ten projekt nieuchronnie doprowadziłby, i przyjęli bardziej pragmatyczne podejście, prowadząc do systemu łatwiejszego w utrzymaniu i działającego również lepiej.

To samo może dotyczyć wielu innych rzeczy, które możesz spotkać jako świeżo upieczony absolwent lub nowy pracownik w każdej firmie. Nie zakładaj, że ponieważ twoja podstawa teoretyczna mówi ci, że coś jest nie tak lub nieoptymalne, to nie ma zbyt dobrego powodu, aby robić to w ten sposób.

Nawet teraz, mając ponad 20-letnie doświadczenie w tej dziedzinie, obawiam się krytykować sposób, w jaki rzeczy są wykonywane w firmach, z którymi współpracuję. Wspomnę mimochodem, że zauważyłem, że rzeczy są inne niż w moim doświadczeniu bycie najbardziej optymalnym, ale nie w wojowniczy sposób. Prowadzi to często do interesujących rozmów, dlaczego te rzeczy są takie, jakie są. Może nastąpią zmiany, a może nie, w zależności od tego, czy wartość zmiany rzeczy jest mniejsza niż koszt.

Nie bój się sugerować, że można to zrobić lepiej, ale zawsze upewnij się, że nie spotkasz się z tym, że jesteś znanym dzieciakiem, ale raczej współpracownikiem, który stara się nie tylko uczyć, ale także pomagają usprawniać procesy doskonalenia firmy, a nie tylko poprawność teoretyczną.

Tak, ale z dużą ostrożnością!

Pozwól mi to wyjaśnić.

Powinieneś dążyć do poprawy możliwości oprogramowania. Jeśli spojrzysz na kod / zespół / biznes / projekt / zarządzanie i twoją pierwszą odpowiedzią jest wzięcie prysznica, to nie da się go zamieszkać. Jeśli twoją pierwszą odpowiedzią jest wykrzyczenie tak! ... a następnie narzekać, gdy zostaniesz wyrzucony z biura, musisz uczynić swój dom bardziej przyjaznym mieszkańcom. To uczucie, a poznacie to.

To powiedziawszy, pracujesz w skomplikowanej sympatii . Wszystko, co zrobisz, prawdopodobnie pójdzie nie tak i prawdopodobnie pogorszy sytuację, przynajmniej w krótkim okresie, ponieważ prosta zmiana ma fale. Więc najpierw stańcie się pokorni, nie mam na myśli naciskać ani zaakceptować, że rzeczy muszą być złe, mam na myśli pogodzenie się z faktem, że wasze dobre intencje zwrócą się przeciwko wam wściekle.

Problem

Z najlepszymi intencjami możesz poczuć, że konieczna jest szeroka zmiana, i nie zgadzam się, że takie sytuacje istnieją, ale poświęć chwilę, aby się nad tym zastanowić. Obecny system działa, ty i twój zespół produkujecie kod, być może jest powolny, może bolesny, ale działa i wszyscy macie doświadczenie w tym, jak to zrobić. W przybliżeniu wiesz, czego się spodziewać, w skrócie jesteś doświadczonym profesjonalistą w tym systemie.

Po szerokiej zmianie nikt, oprócz może implementatora, nie wie, czego się spodziewać. Krótko mówiąc, wszyscy zostali zresetowani do poziomu neofity w tej części systemu. To nie jest dobrze. Neofici muszą nauczyć się nowych zasad, co wymaga czasu. W tym czasie neofici popełniają błędy, ponieważ nie są praktykowani. Te błędy stają się częścią systemu, z którym teraz musisz żyć, i nie jest tak bliski jak teraz.

Droga naprzód

Są chwile, kiedy cięcie, nagrywanie i odbudowywanie jest zdecydowanie najlepsze, co możesz zrobić. Jest to szczególnie atrakcyjne, jeśli nikt nie ćwiczy w starym systemie, ponieważ jedyną utraconą rzeczą jest skodyfikowana wiedza. Jeśli ta wiedza jest całkowicie niezrozumiała, to już ją utracono, a rozpoczęcie od nowa jest jedynym wyborem. I odwrotnie, jeśli metoda kodyfikacji lub sposób jej wykorzystania jest problematyczny, ale funkcjonuje, wiedza ta jest nadal dostępna i być może warto ją zachować, a może nie - Po prostu nie podejmuj decyzji lekko.

Innym wyborem jest praca z systemem, aby każdy miał ramy odniesienia, ale zmiana małych części systemu, tak aby wszyscy w zespole byli świadomi lub, jeśli nie są świadomi zmiany, zarówno łatwo zawiadomienie i łatwe do nauczenia. To jest podstawa praktyk zwanych Kaizen . Bardziej zorientowana na deweloperów formuła została zaprezentowana w prezentacji Golenie złotego Jaka, bardzo polecam obejrzeć go i przemyśleć.

Znajdź więc drobiazg, który można zmienić, który poprawi twoje życie i, miejmy nadzieję, życie kilku innych. Napraw lub popraw sytuację. To da ci praktykę i doświadczenie we wprowadzaniu zmian w praktyce. Upewnij się, że otrzymałeś informację zwrotną: czy mógłbyś omówić to lepiej, czy rzeczywiście był użyteczny, czy zdenerwował inną część systemu. Rozwijaj wyczucie tego, co można zrobić i jak to zrobić.

Teraz wydarzyły się trzy rzeczy:

• ulepszyłeś system,
• masz doświadczenie w zakresie zmiany systemu
• zespół widział, jak pomyślnie zmieniłeś system.

Teraz wybierz inną rzecz do ulepszenia, w miarę wzrostu doświadczenia i eliminowania problemów z zawieszaniem się, zaczniesz stawić czoła trudniejszym problemom w systemie, ale przynajmniej teraz, gdy powiesz, że musimy zmienić X:

• Wiesz, jak zmiana wpłynie na system
• Wiesz, jakie problemy to spowoduje (jakie reguły wymagają ponownego uczenia się)
• Znasz kilka natychmiastowych sposobów naprawy lub poprawy problemów, które wprowadzi zmiana
• ludzie wokół ciebie wiedzą, że znasz system i potrafisz go z powodzeniem zmieniać

Tak, możesz. ALE...

Musisz być ostrożny.

Na początku mojej kariery (bardzo dawno temu) miałem szczęście / pecha, że ​​dostałem się do kilkumiesięcznego projektu jako „Junior”.

Jako pierwszą rzecz, którą zauważyłem, nie było (OMG) repozytorium kodu! Wszystkie scalenia kodu zostały wykonane ręcznie, wysyłając do siebie pliki zip pocztą.

Poszedłem więc do mojego (również nowego) menedżera i zasugerowałem, że powinniśmy mieć repozytorium. Odpowiedź brzmi: Ok, zorganizuj to ....

Więc zorganizowanie repozytorium kodu bez pomocy było nowością w firmie, teraz było to upokarzające doświadczenie.

Kiedy wszystko ustawiłem, (szok) nikt nie chciał z niego korzystać. Próbowałem więc pchać sprawy naprzód i na szczęście mój kierownik zrozumiał, że to ważne, więc miałem wsparcie.

Ale to spowodowało, że nie byłem zbyt lubiany i niestety dostałem pseudonim pochodzący z systemu kontroli źródła.

Tak więc, moim zdaniem, najpierw zapoznaj się z członkami swojego zespołu, co według nich jest ważne, aby je skonfigurować.

Może mają też listę taką jak twoja. Może wszystko przemyśleli i chcieli zrobić to „coś” na liście. Może oni ... (cokolwiek) ....

Cały zespół musi być wyrównany.

Ale jeśli nie są, możesz nadal pracować profesjonalnie. Znajdź podobnie myślących ludzi i pracuj razem, jak Twoim zdaniem należy to zrobić. Jeśli przyniesie to dobre rezultaty, więcej osób będzie z Tobą współpracowało, w końcu stanie się to procesem.

Podobnie jak w przypadku kodu, to samo dotyczy procesów programistycznych: konieczna jest ciągła poprawa.

Tak, zawsze powinieneś starać się ulepszyć to, co można poprawić.

Pamiętaj jednak, że wiele osób, z którymi współpracujesz, może już być profesjonalistami i wiedzą, co jest nie tak i co jest potrzebne.

Czy warto (młodszego) dewelopera starać się robić powyższe w miarę upływu czasu?

Tak, zawsze warto starać się ulepszać. W końcu najlepiej wiesz, jakie problemy napotykasz.

Ale jak wspomniałeś, jest wiele problemów do rozwiązania i wiele z nich nie jest zbyt cennych. W wielu miejscach pojawią się bariery nie do pokonania dla Twojego sukcesu lub innych ludzi, którzy są znacznie lepiej przygotowani do ich poparcia. Należy więc zawsze staram się dokonać rzeczy lepiej, nawet jeśli oznacza to zbieranie która rzeczy spędzić czas starając się lepiej.

Ponieważ ostatecznie, jeśli nie jesteś częścią rozwiązania, jesteś częścią problemu.

Tak. Ale zmiany organizacyjne są trudne nawet dla seniorów, więc jeśli naprawdę chcesz coś zmienić, zrób to we właściwy sposób:

• Nie w pierwszych tygodniach: użyj tego czasu, aby:

  • Stwórz dobre pierwsze wrażenie. Pokaż, że pasujesz do zespołu.
  • Zrozumieć kulturę i politykę lub swoją firmę. Czy można bezpiecznie forsować zmiany?
  • Zbuduj dobre relacje ze współpracownikami
  • Dowiedz się o procesie, zasadach i potrzebach swojego zespołu
  • Naucz się swojej pracy i rób to najlepiej, jak potrafisz. Na pewno będziesz wystarczająco zajęty.

• Wybierz swoje walki. Zdobądź kilka wczesnych zwycięstw : możesz przybyć z energią, aby wszystko zmienić, ale to nierealne. Skoncentruj się na nisko wiszących owocach i pokaż, że Twoje pomysły działają. Chcesz, aby byli otwarci na bardziej złożone ulepszenia. I pamiętaj, że w książkach jest łatwiej.

• Rozważ implikacje dla innych : robię refaktory wpływające na wiele plików. Nawet jeśli poprawią kod, muszę być bardzo ostrożny, aby uniknąć przekształcenia połączeń w ból w dupie. Spróbuj także zrozumieć, dlaczego tak działają. Być może nie mogą używać Scruma, ponieważ brakuje im testów i, co zrozumiałe, boją się często wypychać nieprzetestowany kod do produkcji. Napisanie wiarygodnego testu nie jest łatwym zadaniem. Obecny kod może być naprawdę trudny do przetestowania. Ponadto zespół nie może wykorzystywać ani pisania testów, ani testowalnego kodu. Obecna baza kodu może być szczególnie trudna do przetestowania i wymaga ponownej analizy. Zmiana tego problemu może wymagać lat, ale przynajmniej możesz skupić się na pierwotnej przyczynie.

• Nie oceniaj. Nie wymagaj. Zapytaj o to i słuchaj uważnie: jest to moment, w którym komunikacja ma kluczowe znaczenie, a my, programiści, zwykle nie jesteśmy zbyt dobrzy w subtelnych niuansach. Istnieją techniki, które mogą pomóc . Łatwo jest naciskać na nasz pomysł zamiast skupiać się na odpowiedzi. Najpierw upewnij się, że czują, że masz ich punkty. Zrozum, że uczucia są ważne. Co powoduje ta zmiana? strach? niewystarczalność? gniew? udaremnienie? nadzieja? Leniwy? Głupi? (Nigdy nie sprawi, że ludzie poczują się głupio). Oczywiście wcześniej zadałbyś wiele pytań, co pozwoli uniknąć wielu fałszywych kroków.

• Daj przykład : narzekanie jest łatwe, tworzenie zmian jest trudne. Pokaż wyniki, a ludzie ci uwierzą. Jeśli nie używają testu, możesz napisać testy jednostkowe. Jeśli ludzie nie dokumentują, możesz udostępnić zespół dokumentów Google. Zrozum, że „Ok, zrób to” jest jednym z najlepszych możliwych scenariuszy, a następnie musisz je dostarczyć. W takim przypadku musisz pomyśleć, jakich zasobów będziesz potrzebować . Przykład: daj mi małą instancję Amazon i dwie godziny od administratorów dla serwera Jenkins

• Zachowaj mały i prosty (i tani): Nie chcesz czekać na formalne zatwierdzenie budżetu, ani nie każ swoim szefom myśleć, że tracisz cenny czas od drogich programistów. Byłoby wspaniale mieć oprogramowanie do przeglądu kodu lub ocenić kilka narzędzi typu open source, ale na razie skorzystamy z repozytorium.

• Uzyskaj masę krytyczną: zbierz grupę ludzi skupionych na poprawie jakości. Możesz nawet iść z nimi na konferencje i poprosić o pomoc lub mentoring. Ludzie opisują „przebudzenie gigantycznego fenomenu” w bazie zespołu dosłownie buntuje się przeciwko niektórym głupim praktykom, które spowalniają produktywność. To byłoby naprawdę niebezpieczne i nie poleciłbym tego. Ale jeśli cała grupa się zgodzi, zmiana jest łatwiejsza.

• Daj mi trochę czasu. Następnie głosuj ze swoimi stopami: możesz wypróbować to przez kilka miesięcy do dwóch lat. Ale niektóre firmy nie mają łatwych rozwiązań. Niektóre zespoły nie chcą się zmieniać i nie mają zachęt. A niektóre podstawy kodu to czysty horror. Jeśli uważasz, że to ty jesteś przeciwko światu, pamiętaj, że w ofercie jest wiele ofert pracy. Chcesz nauczyć się dobrych praktyk, a na dłuższą metę będziesz lepszy w pokoju z nieznacznie niższą płacą, ale zdobywając doświadczenie, które uczyni cię bardziej wartościowym.

Premia: Jeśli ci się uda, zapisz to w CV / rozmowach kwalifikacyjnych. Jako Junior zazwyczaj nie masz wiele do powiedzenia, a zmiana na lepsze jest zawsze świetnym znakiem. Chcesz mieć bardzo jasny i realistyczny pogląd na to, co zrobiłeś osobiście i na czym polegała praca innych. Wyobraź sobie następujące pytanie do rozmowy kwalifikacyjnej.

• Opowiedz mi o czasie, w którym zrobiłeś różnicę w zespole.
• Cóż, byłem w miejscu, gdzie mieli bardzo staromodne praktyki. Wiele osób nie było z tego zadowolonych, a wydajność miała duży potencjał do poprawy. Zaproponowałem więc szybki eksperyment z retrospektywami, zrobiliśmy X i Y, w wyniku czego uzyskaliśmy ten cudowny wymierny wynik ”.

Tak. Ale nie rzeczy, które sugerujesz.

Z Twojej listy Testy jednostek / integracji są jedyną pozycją, na której możesz robić postępy.

Możesz zacząć dodawać je samodzielnie przy minimalnym nakładzie czasu i wyświetlać natychmiastową wartość. Jest to problem techniczny z powszechnie akceptowanymi korzyściami i nie wpływa na inne praktyki pracy. Jednocześnie zyskujesz wiedzę mdore o bazie kodu, nawet jeśli wyniki nie są akceptowane. Łatwa sprzedaż.

Pozostałe to ogólnie procesy biznesowe obejmujące cały zespół, a nawet inne zespoły. Możesz zasugerować ulepszenia, ale młodszy pracownik będzie miał trudności z ich zmianą, a proces ich zmiany nie jest ogólnie techniczny i prawdopodobnie nie ma związku z normalną pracą.

Sugerowałbym również takie rzeczy, jak konfigurowanie potoków CI, automatyczne wdrażanie, wersjonowanie, biblioteki pakietów jako dobre rzeczy do ataku

To zależy od:

• ile oczekujesz od lepszych praktyk
• ile wysiłku będziesz musiał dołożyć, aby się tam dostać
• jaka jest szansa na sukces i ryzyko - od zwykłego niepowodzenia adaptacji po nowe praktyki są naprawdę okropne, jakość kodu obniża się, kluczowi ludzie odchodzą, wszyscy cię nienawidzą i musisz znaleźć inną pracę w innym mieście, w którym nikt nie zna twojego imienia

Zasadniczo: w zakresie twoich obowiązków leży spędzanie rozsądnego czasu na propagowaniu tego, co uważasz za najlepsze - ale decyzja powinna spoczywać na zespole lub zarządzaniu. Pamiętaj, że wyobcowanie ludzi rzadko jest tego warte, nawet jeśli skończysz na lepszych praktykach.

Nie zaczynaj od najbardziej skomplikowanych rzeczy, takich jak Scrum. Zacznij od najłatwiejszych możliwych kroków.

Nie wspominałeś o zarządzaniu kodem źródłowym. Czy masz jakieś repozytorium kodu źródłowego (git, svn, cvs, ...)? Strategia tagowania i rozgałęziania? To są proste kroki, które może zrobić początkujący. Przeczytaj, jakie problemy rozwiązują te kroki (spróbuj), i jak pomaga to Twojej firmie zmniejszyć koszty (właśnie tym interesuje się zarząd).

Kolejnym krokiem mogą być automatyczne kompilacje, nocne lub bezpośrednio po każdym zameldowaniu, np. W Jenkins. Możesz także uruchamiać testy automatycznie. I dodaj kilka narzędzi do pomiaru jakości kodu (och tak: zdefiniowanie niektórych standardów kodowania jest również dobrym krokiem).

Jeśli chodzi o scrum, lepiej przeczytaj o „Extreme Programming” (XP). Scrum opiera się na wielu pomysłach na XP i dodaje sformalizowany proces wokół nich - koncepcji XP można nadal używać bez tego procesu.

Sugeruj rzeczy, dostarczaj informacji z przeszłości, próbuj przekonać innych do wypróbowania ich, analizuj wyniki, ... ale nie oczekuj zbytniej współpracy od innych: większość ludzi woli trzymać się swoich starych złych nawyków. Ale kiedy tego nie spróbujesz, nic się nie poprawi.

Powiedziałeś, że zespół jest nowy (3 lata), więc jeśli nie możesz teraz wprowadzić dobrych zasad, trudniej będzie to zrobić 10 lat później. Niektóre z rzeczy, o których wspomniałeś, takie jak system testowania i wersjonowania, należą do tych, które możesz już zasugerować, ale nie wyrzucaj takich sugestii bez podkreślania ich oczywistych zalet i wybierania narzędzi wymaganych przez stos programistyczny.

Na początku zadawaj pytania

Czytając twoją listę, zasugeruję następujące pytania (wróć do listy, aby zobaczyć, jak pasują):

• Jak mogę zobaczyć, jakiej pracy żądają właściciele firm?
• Próbowałeś [Scrum]?
• Kto jest właścicielem tego produktu?
• Jakie są role?
• Czym zajmuje się ta rola?
• Jaka rola jest odpowiedzialna za [tę aktywność]?
• Czy próbowałeś codziennego standupu?
• Jak przekazać przeszkody pozostałym członkom zespołu?
• Jak dowiedzieć się, nad czym pracują inni członkowie zespołu?
• Czy powinniśmy umieścić [to] w narzędziu do śledzenia problemów?
• Jak powinniśmy napisać [to] w narzędziu do śledzenia problemów?
• Kiedy [to] się dzieje, czy powinniśmy umieścić to w narzędziu do śledzenia problemów jako [to]?
• Jak testujemy?
• Jak rejestrujemy nasze testy, aby inni mogli je ponownie wykorzystać?
• Próbowałeś [JUnit]?
• Gdzie jest to [udokumentowane]?
• Próbowałeś [MediaWiki]?

Zamień odpowiednio elementy w [nawiasach], aby pytania miały sens lub pasowały do ​​twoich priorytetów. Rozważ przeformułowanie, jeśli moje sformułowania nie pasują do Twojego stylu.

Być może już zacząłeś to robić. Preferuj rozmowy jeden na jednego nad rozmowami grupowymi. Ponieważ jeden na jednego, możesz lepiej przeczytać, co myśli druga osoba. Czy ta osoba jest za tą zmianą? Przeciwko temu? Słabo? Wściekle?

Kiedy jesteś nowy, zadawanie pytań jest praktycznie bezpłatne. Ludzie powinni oczekiwać, że będziesz zadawać pytania. Nawet jeśli twoje pytania pośrednio opowiadają się za stanowiskiem, któremu się sprzeciwiają, nie powinny się złościć. Powinni wyjaśnić, dlaczego sprzeciwiają się temu stanowisku. Odradzam sprzeczanie się z nimi. Kłótnie mają tendencję do umacniania pozycji bardziej niż przekonuje. Zwróć uwagę, kto ma jaką pozycję i idź dalej.

Później podejmij kroki

Poszukaj sposobów, w jakie Ty i być może inni (tj. Ci, których zauważyłeś wcześniej zgadzając się z Tobą), mogą rozpocząć zmiany, które chcesz. Nie każdy chce awansu? Dlaczego nie? Być może ci z was, którzy tego pragną, mogą mieć własne wsparcie. Nie tak skuteczny jak w przypadku całego zespołu, ale bardziej niż teraz.

Jeśli masz przeszkodę (i zakładasz, że nie możesz uczestniczyć w pojedynku), wyślij e-mail do zespołu, aby uzyskać pomoc.

Określ, jakie powinny być role, być może przy wsparciu innych osób, które się z tobą zgadzają. Zacznij konsekwentnie chodzić do ludzi, gdy praca wiąże się z rolą, którą ty (prawdopodobnie grupa, którą uważasz) powinnaś mieć. Jeśli się odepchną, poproś ich o określenie, kto powinien być właścicielem tej roli.

Poproś właścicieli produktów (które zidentyfikowałeś) o napisanie opisów, w jaki sposób ich zdaniem produkt powinien działać teraz iw przyszłości.

Zainstaluj platformę testową (jeśli inni to sprzyjają, podejmij wspólną decyzję, która platforma) i używaj jej do swoich projektów. Kiedy naprawiasz błędy, pisz testy. Udokumentuj to w raporcie o błędzie w narzędziu do śledzenia problemów (napisano test demonstrujący błąd, przechowywany w [lokalizacja]). Zachęcaj innych do uruchamiania testów, gdy wprowadzają zmiany. Jeśli nie, uruchom testy samodzielnie i w razie potrzeby prześlij problemy do modułu śledzącego.

Jeśli możesz uzyskać wsparcie zarządzania, zainstaluj oprogramowanie wiki lub podobne i zacznij dokumentować swoje rzeczy. Jeśli ludzie zadadzą ci pytania, które pokazują, że nie przeczytali dokumentacji, skieruj je na odpowiednie strony. Zachęć ich, aby zadawali więcej pytań, jeśli nie rozumieją dokumentacji. Jeśli nadal będą zadawać pytania zawarte w dokumentacji, odpowiedz na nią, odpowiadając. Zastanów się, czy nie zachęcić ich do aktualizacji wiki, jeśli uważasz, że problem miał charakter strukturalny, a nie brak czytania.

Sugerowałbym koncentrowanie się tylko na jednym zadaniu na raz. I na pewno pchaj tylko jeden na raz. Nie naciskaj mocno. Zobacz ten przykład pchania mocniej, niż oczekiwała grupa. Skoncentruj się bardziej na zmianie swojego zachowania niż ich. Jeśli twoja droga jest właściwa, powinno to być oczywiste dla obserwujących cię ludzi. Czyny mówią głośniej niż słowa. Staraj się nie powtarzać z tą samą osobą podczas szturchania. Po doprowadzeniu konia do wody, pozostaw wybór, kiedy i czy wypić.

W końcu będziesz starszy

Z czasem twój zespół zatrudni nowych ludzi. Przestaniesz być nowym pracownikiem i będziesz mógł promować swoje stanowiska z nowymi ludźmi. Współpracuj z nimi, aby wprowadzać zmiany. I może się okazać, że robisz postępy również ze swoimi obecnymi kolegami z drużyny. Lub jeśli to nie działa, poszukaj nowej pracy, w której mają lepsze praktyki. Nie ma pośpiechu. Masz pracę. Możesz poczekać chwilę na lepszą pracę, poprawiając ją lub znajdując lepszą.

Krótka odpowiedź : Nie, z wszystkich powodów przedstawionych w innych odpowiedziach. Nawet będąc deweloperem średniego lub wyższego szczebla, zwykle lepiej najpierw zrozumieć , dołączając do nowego zespołu.

Proponowane rozwiązanie :

1) Za każdym razem, gdy zobaczysz coś, co według ciebie powinno zostać poprawione, zwróć na to uwagę! (w zeszycie, w notatce cyfrowej ...)

2) Po 6 miesiącach wróć do swoich notatek i sprawdź je. Ile pomysłów wydaje się teraz bezcelowych i nieodpowiednich? Najprawdopodobniej dużo zaoszczędziłeś sobie wstydu. Jeśli jakieś pomysły nadal się utrzymują, teraz będzie dobry moment, aby je przedstawić, jeśli to możliwe, najpierw je testując.

Późna odpowiedź i uzgodnij wiele dobrych treści w innych odpowiedziach.

Myślę, że należy wezwać, że kluczową kwestią nie są tutaj konkretne praktyki, ale ogólna kultura zespołu.

• Tworzenie zmian kulturowych jest trudne .
• Co więcej, jeśli widzisz jako „młodszego”

Wszystko inne może nastąpić, jeśli istnieje sposób na ciągłe doskonalenie .

Moje podejście do osiągnięcia tego jest następujące:

• Udokumentowane procesy i procedury
• Retrospektywy z zespołem, którego działania są zmianami w dokumentacji procesu.

Sądzę, że jeśli nie masz sprintu, nie masz jeszcze regularnych retrospekcji. Wystarczy rozmowa z zespołem, a następnie podjęcie działań.

Możesz łatwo rozpocząć proces dokumentowania. „Jestem nowym facetem, czy mam rację? Pozwól mi to zapisać”. Ważne jest, aby samemu śledzić ten proces lub spróbować zadzwonić do nas tam, gdzie się on kończy.

Być może zaczynasz od takich rozmów, które odbywają się ad hoc, a następnie sugerujesz regularne rytuały.

Takie podejście pozwala na stopniowe, łagodnie miękkie podejście. Możesz uniknąć pojawienia się jako junior, który wszystko to wie, i zamiast tego staraj się być facylitatorem zespołu dokonującego zmian.

Niektóre uwagi:

• Niektóre zespoły mają kiepski proces, ale tak naprawdę już to wiedzą. Chcą się zmienić i potrzebują czegoś, co to przyspieszy. Inne zespoły naprawdę utknęły na ich drodze i dużo trudniej je zmienić.
• To samo dotyczy osób fizycznych.
• Musisz być na to wrażliwy i dowiedzieć się, kto w zespole jest otwarty na zmiany, a kto nie. Zrozum dlaczego.
• Znajdź łatwe wygrane.
• Spraw, by zmiany były mile widziane w zespole: Znajdź ich indywidualne punkty bólu i spróbuj je naprawić.