Jak informować nowych członków zespołu o projekcie? [Zamknięte]

Mamy zamiar zatrudnić 1-2 nowych inżynierów dla zespołu oprogramowania (składającego się z 3 programistów, 1 testera).

Jakie są kroki, aby zintegrować je z zespołem?

Moje pomysły to:

• przeczytaj dokumentację (standardy kodowania, dokumenty w stosowanych przez nas metodologiach programistycznych)
• poproś, aby przeczytali istniejący kod
• przypisz im kilka prostych zadań
• na końcu uczyń ich odpowiedzialnymi za część kodu

Co jeszcze możemy zrobić?

Projekt dotyczy sektora medycznego (system ultradźwiękowy) i trwa już 5 lat. Mamy coroczne wydania i właśnie kończymy jedno wydanie, gdy chcemy dodać 1-2 inżynierów.

Projekt znajduje się w fazie konserwacji (refaktoryzacja starszego kodu oraz dodanie nowych funkcji). Wszystko przebiega zgodnie z harmonogramem (mniej więcej).

Pochodząc od kogoś, kto w mojej karierze musiał przyśpieszyć wiele różnych baz kodowych, oto, co zasugeruję:

1. Poświęć krótki czas (może dzień lub dwa) na działania związane z korzystaniem z produktu, aby mogli zapoznać się z jego działaniami. Może to być weryfikacja błędów, wykonywanie planów testowania jakości lub przechodzenie szkolenia użytkowników.
2. Pracuj nad małymi, zlokalizowanymi błędami. Dzięki temu inżynier zapozna się z budowaniem i debugowaniem aplikacji bez konieczności uczenia się dużej ilości architektury.
3. Najlepiej napisz małą nową lokalizację, która jest zlokalizowana. Dzięki temu mogą napisać fragment kodu, a podczas pisania go poznają otaczające go fragmenty kodu, z którymi musi współpracować ich nowy kod.

Stamtąd rozszerz zakres i złożoność zadań w czasie, w zależności od poziomu doświadczenia i umiejętności inżyniera. To pozwoli programistom na poszerzenie wiedzy o bazie kodu.

Unikałbym czytania tylko zadań (dokumentacji lub kodu). Czytanie dokumentacji staje się naprawdę nudne bardzo szybko, a czytanie losowego kodu nie jest pomocne, ponieważ nie będą miały kontekstu do pracy. Trudno jest odczytać kod do recenzji kodu, jeśli znasz już produkt i bazę kodów. Nie widzę nic użytecznego po tym, jak nowy inżynier po prostu czyta kod.

Mam wrażenie, że tolerancja większości ludzi na czytanie dokumentacji jest dość niska (dobra na dzień lub dwa, ale poza tym prawdopodobnie będą mieć ochotę zrobić coś więcej).

Nie sądzę, że naprawdę można zrozumieć kod aplikacji bez rozsądnego zrozumienia samej aplikacji. Oprogramowanie prawdopodobnie ma wiele funkcji, którymi mogliby się „bawić” jako użytkownik; w końcu będą musieli móc to przetestować, więc spodziewam się, że bardzo ważne jest, aby wiedzieli, jak go zainstalować, skonfigurować i wykonywać z nim typowe zadania

Osobiście uważam, że przegląd architektury wysokiego poziomu jest zwykle bardzo przydatny, aby uzyskać podstawowe pojęcie o tym, jak rzeczy działają - Być może przeznaczyć godzinę lub dwie godziny pracy starszego inżyniera (lub siebie, jeśli to konieczne?) W pierwszym tygodniu, aby przejść podstawowe nakrętki i nakrętki głównego zastosowania. np. zrozumienie wszystkich podsystemów i tego, jak rzeczy są ze sobą powiązane, wiedza, które bity są obsługiwane przez oprogramowanie / biblioteki innych firm, a które bity muszą być utrzymywane wewnętrznie. (Chyba że Twoja organizacja ma aktualną dokumentację naprawdę wyjątkowej jakości, zgaduję, że nie ma sposobu, aby poradzili sobie z tego rodzaju sprawami, gdyby ktoś nie wyjaśnił im tego bezpośrednio za pomocą tablicy: - ))

Jeśli chodzi o dawanie im czegoś praktycznego, zadania konserwacji / ścigania błędów mogą być dobrym sposobem na przyspieszenie ich na chwilę (kilka tygodni / miesięcy?) - będą w sytuacjach, w których określone obszary funkcjonalności muszą być zrozumiane, przetestowane i debugowane; pomagając w pogłębianiu wiedzy o kodzie, wymaganiach, narzędziach używanych przez firmę, procesach rozwoju i produktach jako całości, przy czym, mam nadzieję, nie potrzebując pochłaniać zbyt wiele czasu od reszty zespołu programistów

Jako Lead spędzam co najmniej 2 dni z nowymi programistami. Przekonałem się, że rozwijanie relacji, w której wygodnie jest zadać nieuniknione pytanie „jak ci idzie postęp?” jest koniecznością. W każdej nowej społeczności istnieje strach, by się do niej dopasować ... ukrywamy błędy, zachowujemy się doskonale, poprawiamy sytuację, zmniejszamy trudność. Menedżer spędzający z kimś 2 dni poinformuje go, że nie o to chodzi w jego kulturze, i da mu przykład. Nowi koderzy potrzebują lekcji historii o tym, skąd przybyłeś i jak daleko jesteś. Dokumenty po prostu nie wykonują zadania sprawiedliwie.

Pracuję w branży od 10 miesięcy (po umieszczeniu), ale okazało się, że pomogły mi:

• Współdziałanie z innymi programistami i obserwowanie, jak rozwiązują problemy.
• Testowanie oprogramowania pomogło, musiałbym przetestować funkcję x, co oznacza, że ​​przeczytałem dokumentację dotyczącą funkcji x. Zrobiłem to dużo, pomogło.

Oba te pomogły mi trochę. Powodzenia.

Przejdę z wysokiego poziomu na niski.

Demo aplikacji jak najszybciej

Jedną z najważniejszych rzeczy jest to, że deweloper ma pomysł, nad czym będzie pracował. Podczas demonstracji zwróć uwagę na niektóre rzeczy, które były ostatnio rozwijane, oraz kierunek, w którym zmierza aplikacja.

Wyjaśnij architekturę wysokiego poziomu

To jest również bardzo ważne. Pozwól nowemu twórcy słuchać i zadawać pytania. Zrób to jako ćwiczenie grupowe z innymi deweloperami, którzy, mam nadzieję, wkroczą i pomogą ci. Dzięki temu nowy programista dowie się, że można otwarcie i szczerze mówić.

Przygotuj świetny dokument pokładowy

Posiadanie świetnego dokumentu pokładowego pomaga nie tylko nowym twórcom, ale także starszym. Może zawierać oczekiwania, przydatne linki i informacje o konfiguracji środowiska. (Nie potrafię powiedzieć, ile razy korzystałem z naszego systemu pokładowego, aby skonfigurować środowisko, kiedy dostaję nowy komputer ...) Powinno to być dobrze zorganizowane i do rzeczy, a nie pozostawać na dłużej i nie być wysypiskiem dla każdego mały szczegół.

Zachęcaj go do zadawania pytań (i bądź dostępny, aby na nie odpowiedzieć)

Z odpowiedziami prowadź je, ale nie mów im, co mają robić. Daj im wskazówki, ale pozwól im w końcu sami to rozgryźć.

Pomóż innym członkom zespołu przywitać przybysza

Moneta ma dwie strony, gdy ktoś dołącza do drużyny. Zespół musi mieć narzędzia, aby powitać również nowego programistę.

Niech podniosą małe lub dwa zadania

Pozwól im dodać coś nowego i widocznego do projektu, który jest w wersji demonstracyjnej. Kiedy zostanie pokazany, powiedz, kto to zrobił i jaką dobrą robotę wykonali. To naprawdę może zwiększyć samoocenę. Im szybciej czują się, jakby dodawali wartość, tym szybciej czują, że są częścią zespołu. Im szybciej poczują się upoważnieni do zrobienia wszystkiego, co mogą.

Zachęcaj ich do wykonywania trudniejszych zadań, gdy poczują się coraz bardziej komfortowo

Dobrzy kandydaci zrobią to naturalnie.

Jednym z przepływów „orientacyjnych”, przez który przeszedłem (i które okazało się przydatne) było coś w stylu:

1. Krótka prezentacja przedstawiająca „duży obraz”, jakie są komponenty, jak pasują i ogólna architektura.
2. Przegląd kodu, wprowadzenie do funkcji, które obsługują główną logikę komponentów przypisanych do mnie. Omówiłem niektóre rzeczy związane z konwencjami i stylem kodowania.
3. Przypisano wiele otwartych problemów i błędów o niskim priorytecie (które w dużej mierze były zlokalizowane w przypisanym do mnie komponencie i dość proste).
4. Oczekiwano, że przeprowadzę debugowanie za pośrednictwem aplikacji i poprosię o pomoc w sprawach, których nie byłem w stanie odczytać.
5. Po wprowadzeniu poprawki przeprowadziłem się przez proces (przegląd kodu, testowanie na poziomie deweloperskim itp.) Udostępnienia do integracji.
6. Powtórz dla pozostałych przydzielonych zadań / błędów.

Myślę, że to podejście (i jego odmiany) będzie przydatne, ponieważ:

• Było to bardziej praktyczne i względnie niezależne (stały brak trzymania ręki itp.). Dzięki temu nowa osoba ma wystarczająco dużo miejsca / czasu, aby przyzwyczaić się do kodu i sposobu, w jaki załatwia się sprawy w zespole.
• Jest to również korzystne dla całego zespołu, ponieważ można rozwiązać kilka zadań / błędów o niskim priorytecie. Osoba pomagająca nowym osobom ma również więcej czasu na radzenie sobie z przydzielonymi im zadaniami, ponieważ ciągłe trzymanie ręki nie jest wymagane, a czas można specjalnie zaplanować na rozwiązanie problemów / problemów, z którymi może spotkać się nowa osoba.

Początkowi pracownicy potrzebują niewielkiego, ale niezbyt małego i dobrze zdefiniowanego zadania do pracy. W ten sposób mogą zacząć wyczuwać strukturę kodu, próbując dowiedzieć się, jak wykonać swoje zadanie. W trakcie procesu pojawią się pytania, w których możesz skierować je do dokumentacji lub innych zasobów, które mogą pomóc w internalizacji bazy kodu. Pomaga także, jeśli cykl rozwijania, zatwierdzania, wdrażania jest krótki i mogą zobaczyć owoce swojej pracy w akcji tak szybko, jak to możliwe.

Tak właśnie chodzę

1. Daj im kilka zadań związanych z projektem (np. Jeśli twój projekt jest aplikacją bazy danych, poproś ich o utworzenie aplikacji do połączenia z bazą danych i wykonanie prostej operacji).
2. Kiedy odkryjesz, że zrozumieli pomysł pracy, daj im wersję demonstracyjną Projektu
3. Poproś ich o przeczytanie dokumentacji.
4. Zapoznaj się ze stylami i standardami kodowania
5. Później daj im kilka ćwiczeń debugowania (aby poznać przebieg projektu).
6. Poproś ich o naprawienie punktu, który już naprawiłeś (tylko po to, aby poznać ich logikę).
7. Wreszcie uczyń je częścią projektu.

Pamiętaj: bez względu na to, ile będziesz starał się, dopóki uczestnik nie zrozumie projektu całkowicie, nie będziesz w stanie wykonać z niego pracy w najbardziej efektywny sposób.

Po pierwsze - najpierw naucz się korzystać z oprogramowania, aby odkryć, jakie problemy rozwiązuje z perspektywy użytkownika. Jeśli nie ma interfejsu użytkownika (np. Jest to usługa zaplecza lub coś takiego), pozwól im korzystać z dowolnego dostępnego interfejsu, aby z niego korzystać. Uzyskanie nowego spojrzenia na oprogramowanie użytkownika jest zawsze dobre i może pomóc nowemu pracownikowi zobaczyć rzeczy, których nie możesz, ponieważ jesteś już osadzony w projekcie.

Po tym dobrym pierwszym projektem może być coś w rodzaju dodatku lub nowego modułu do dodania do oprogramowania, minimalizując niezbędną wiedzę na temat istniejącej bazy kodu. Pisanie czegoś nowego zawsze będzie łatwiejsze niż usuwanie błędów, które mogą wymagać wielu zmian w wielu plikach źródłowych. Moim zdaniem, przekazanie nowemu pracownikowi zadania naprawy błędu prawdopodobnie wyłączy go z firmy.

Twój plan zaznajomienia nowych z projektem wydaje się rozsądny. Pamiętaj jednak, że na początku będą musieli się wiele nauczyć. Zazwyczaj jest to przytłaczająca sytuacja. Musisz uzbroić się w cierpliwość i wielokrotnie odpowiadać na te same pytania. To normalne, nowi programiści muszą się dużo nauczyć, nie lekceważ tego. Jeśli zdenerwujesz się tymi powtarzającymi się pytaniami, ryzykujesz, że nie zadadzą tego i nie spróbują dowiedzieć się rzeczy, które w najlepszym razie mogą być bardzo powolne, ale często niemożliwe. Będą też musieli nauczyć się języka. Większość projektów zespołowych rozwija swój własny język. Wyjaśniając świadomie, staraj się unikać żargonu. Wyjaśnij to tak, jakbyś to wytłumaczył swojej mamie. Ponownie bądź cierpliwy.

Dodatkowo możesz spróbować zintegrować je z innymi członkami zespołu, próbując wykonać zadania w stylu centrum oceny, np. Zbudować most w 45 minut z 4 arkuszy papieru podtrzymujących filiżankę kawy. Używamy tej techniki w praktycznym kursie inżynierii oprogramowania, aby grupa 8 uczniów przełamała lody, zanim będą pracować nad jednym projektem przez 3 tygodnie. Pomaga przyspieszyć tworzenie zespołów.

1) Wyjaśnij im zasady i wytyczne dotyczące kodu. Podaj także ogólne wyjaśnienie działania aplikacji i ogólną strukturę kodu.

2) Znajdź kilka drobnych błędów lub projektów, które są w dużej mierze niezależne od innych kodów. Wyjaśnij, co należy zrobić, gdzie w kodzie i sprawdzaj je regularnie.

3) Powoli zacznij dawać im coraz większe projekty, sprawdzając je coraz mniej.

4) Od czasu do czasu usiądź obok nich. Możesz się wiele nauczyć, patrząc, jak ktoś inny rozwiązuje problem. Małe rzeczy, takie jak „och, możesz szukać funkcji w kodzie, naciskając ctrl-”. są bardzo przydatne.

Teraz odkryłem, że istnieją dwie skrajności :

• Ktoś, kto zadaje pytanie co pięć minut. „Co robi ta ścieżka. Dołącz?”. Powinni najpierw uzyskać odpowiedź od Google i przyjść do ciebie tylko wtedy, gdy nie mogą znaleźć odpowiedzi.

• I z drugiej strony, ktoś, kto pracuje przez pół dnia, nie zadając ani jednego pytania. Powinni czuć, że dobrze jest zadawać pytania. Chcę tylko, żeby najpierw to wypróbowali.

To była moja formuła i zastosowana z kilkoma nowymi osobami - kroki te okazały się bardzo skuteczne.

a) Wszyscy nowi programiści otrzymają wprowadzenie na temat wymagań projektu i procesów rozwojowych przez 2 dni.

b) Przypisanie 3-tygodniowego zadania pisania testów Junita dla kodu, który nie ma wystarczającego zasięgu.

c) Po wykonaniu 3 przydziel małe zadania

d) Przypisuj złożone zadania i gotowe.

Myślę, że po prostu przypisz kilka drobnych zadań, poproś, aby napisali kilka testów jednostkowych, sprawili, że debugują niektóre błędy regresji. Nic zbyt dużego ani wymagającego, ale wystarczająco, aby postawić je na nogi.

Powinieneś także wyznaczyć starszego programistę, najlepiej na nowego programistę, który mógłby pomóc mentorowi kandydatowi.

I tak, niech udokumentują, czego się uczą o systemie. Zakładam, że masz jakieś wewnętrzne strony wiki. Jeśli nie, jest to zdecydowanie konieczność zarówno na dłuższą, jak i krótką metę - zaskakująco szybki sposób na zwiększenie liczby ludzi. Strony Wiki nie powinny zawierać tylko dokumentacji kodu, ale także rzeczy takich jak znane ograniczenia (jest to oprogramowanie: D), obejścia, wskaźniki wydajności czas / pamięć itp.

Nie wyjaśniaj tylko dobrych praktyk i standardów kodowania, ale wyjaśnij, w jaki sposób skonstruowany jest odczytany kod. Wyjaśnij, co powinno robić oprogramowanie i jak to jest lub zostanie osiągnięte.

Nie zrozumieją, dopóki nie będzie pracy, więc proponuję rozdzielić ją na dwie części, jedną przed rozpoczęciem prawdziwej pracy, a drugą część po rozpoczęciu pracy. Przejrzą jakiś kod lub dokumentację i pomyślą „ WTF !? ”. Kiedy to nastąpi, ktoś będzie im towarzyszył i wyjaśniał drobne szczegóły.