Wskazówki / porady dotyczące zarządzania nowym zespołem z nowym kodem [zamknięte]

Jak radzisz sobie w nowym zespole, w którym jesteś najbardziej zaawansowanym programistą, a większość innych członków zespołu jest od ciebie młodsza o kilka lat. Zadanie, przed którym stoi zespół, jest czymś, czego nikt inny, włączając ciebie, nie wykonał wcześniej w swojej karierze.

Zarząd kładzie nacisk na wyższą produktywność całego zespołu, a jako starszy programista jesteś odpowiedzialny.

Jakieś wskazówki na temat atutów w takiej sytuacji? Oczywiście cały zespół potrzebuje czasu na naukę i nie zapominajmy o nowym zespole. Jednak terminy również się zbliżają ...

Nie pozwól, aby napięty termin lub nowość projektu kolidowały z dobrą praktyką inżynierską. Skonfiguruj repozytorium oprogramowania, zgódź się na styl kodowania, wymyśl zestaw testów itp. Nowość zadania nie powinna być aż tak wielka, o ile masz pod sobą wysokiej jakości ludzi gotowych ciężko pracować i uczyć się zadania przed nimi.

Innymi słowy: kierujesz, ponieważ kierownictwo jest przekonane, że twoje doświadczenie i doświadczenie zapewniło ci narzędzia potrzebne do tworzenia wysokiej jakości oprogramowania. Nie zapomnij nagle o swoich umiejętnościach, ponieważ to zadanie wydaje się teraz zniechęcające.

Po pierwsze, zacznij korzystać z systemu kontroli kodu źródłowego od pierwszego wiersza kodu. Nabierz nawyku sprawdzania kodu wcześnie i często.

Po drugie, wybierz strategię testowania . Oczywiście powinno to oznaczać testy jednostkowe, ale należy również rozważyć sposób zautomatyzowania testów akceptacyjnych.

Po trzecie, ustanów serwer ciągłej integracji , aby kod był regularnie budowany i regularnie testowany.

Gdy już to osiągniesz, jako zespół ustal kilka prostych standardów kodowania . Chcesz, aby Twój kod był czytelny dla wszystkich. Tak naprawdę nie ma znaczenia jakie są standardy. Wcięcie za pomocą zakładek, wcięcie za pomocą spacji, nawiasy klamrowe na tej samej linii, cokolwiek. Nie ma znaczenia, jakie są, tylko że wszyscy konsekwentnie je stosują.

Ponieważ zespół składa się głównie z młodszych programistów, często przeglądaj kod, aby upewnić się, że nie powodują nadmiernego zadłużenia technicznego w twoim systemie.

Na koniec rozważ użycie SCRUM . Jeśli tak, wynajmij trenera lub przejdź na szkolenie. Ponieważ wszyscy robicie coś, czego nigdy wcześniej nie robiliście, ustalenie realistycznych terminów jest po prostu niemożliwe. Dzięki SCRUM twoje kierownictwo będzie miało wgląd w to, co robisz na co dzień, aby mogli zobaczyć, jaki postęp jest (lub nie jest) osiągany. A ponieważ najwyraźniej zostały ci podane terminy, SCRUM przynajmniej gwarantuje, że jeśli nie dotrzymasz terminu, przynajmniej dostarczasz ukończone historie stopniowo, co jest prawdopodobnie lepsze niż zakończenie z gigantem system, który w ogóle nie działa.

Oprócz odpowiedzi udzielonej przez @chrisaycock ... Nie lekceważ czasu, który będziesz musiał przeznaczyć na mentoring / szkolenie itp. Jako lider musisz nauczyć się odpuszczać szczegóły i ufać swojemu zespołowi. Twoim zadaniem jest zostać aktywatorem, usuwaniem blokad na drodze i interferowaniem, gdy kierownictwo tam wkracza. W „normalnym” zespole, około 7 lub 8, kierownictwo nie programuje już, W twojej sytuacji spada to do 3 lub 4 (Może nawet mniej), nie jesteś zasobem programistycznym dla projektu.

Skoncentruj się na komunikacji w dwóch obszarach.

Nie jest to łatwe i jest to jeden z powodów, dla których ta praca jest trudna. Jeśli dotrzymanie terminu oznacza wycięcie funkcji, przejdź przez to. Jedyną rzeczą, której starasz się w tym wszystkim unikać, jest szybki kod, aby ustalić termin. To początek końca bazy kodu, który nie przetrwa dobrze, i początek zadłużenia technicznego, który dusi.

2) Komunikacja między zespołami. Ustaw formalne praktyki, takie jak Bryan i inni polecają. Upewnij się, że spotykasz się regularnie jako zespół, np. Raz w tygodniu jako dodatek do codziennych scrumów. Zdobądź szacunek i zaufanie, słuchając , najważniejszego narzędzia. Skoncentruj się na pomocy. Unikaj negatywnej krytyki za wszelką cenę. W razie potrzeby skorzystaj z pozytywnej krytyki i zachęty, np. „To świetnie, gdy rzeczą, którą możesz rozważyć, jest X„ ponad ”, to nie jest to, czego potrzebujemy, musisz zamiast tego zrobić X”

To, co zrobiłem, to zidentyfikowanie zdolnych, podzielenie i podbicie. Biorę najlepsze 2 lub 3 i zostaję ich kapitanami. Pozostali są następnie równomiernie dzieleni na drużyny podążające za kapitanami do ich własnych małych drużyn.

Daję kapitanom części lub moduły do ​​zrobienia w programie.

Kapitanowie przydzielają początkującym mniejsze zadania związane z programowaniem lub badaniem, jednocześnie wyjaśniając sobie, co robią, więc mentoring się dzieje.

Staram się zaaranżować pokój, aby wszyscy byli na tej samej otwartej przestrzeni, ale każda drużyna ma swój własny krąg komputerów. Lubię być w odległości krzyczącej do wszystkich, więc wszystko szybko się rozwija.

Jak dotąd działa to dobrze dla około 10-20 programistów. Mniejsze grupy po prostu lepiej są w jednej grupie i jeszcze nie pracowałem z niczym większym.