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

9

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

project-management productivity product-management

— Fanatyk 23
źródło

Powinien być na pm.stackexchange.com

— JBRWilkinson

5

@JBRWilkinson Nie zgadzam się. Chodzi o bycie liderem technologicznym młodszych programistów z napiętym terminem. Zgodziłbym się, jeśli chodzi o zarządzanie projektem młodszych programistów, jednak bycie liderem technologicznym różni się od bycia menedżerem.

— wałek klonowy

13

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.

— chrisaycock
źródło

Upewnij się, że każdy w zespole ma możliwość oszacowania wszystkich zadań, które zostaną mu przydzielone, aby mieć możliwość wpisania się na czas. Ponieważ twój zespół wciąż uczy się lin, nie angażuj nikogo więcej niż pięć godzin dziennie, kiedy zamieniasz szacunki w upływający czas. A jeśli terminy nie mogą być dotrzymane, upewnij się, że Zarząd wie o tym jak najszybciej.

— Dawood ibn Kareem

1

@David - Jak ćwiczyłeś 5 godzin (właściwie nie jest to zła liczba do użycia, ale skąd to wiemy)? Po prostu przyznaj, że szacowanie takiego projektu to bzdura i powiedz zarządowi.

— mattnz

3

Myślę, że większość ludzi jest produktywna przez około 6 do 6,5 godziny dziennie. Kilku radzi sobie więcej niż to, ale myślę, że to dobra średnia. Ale ponieważ zespół jest nowy, co najmniej jedna godzina dziennie będzie poświęcana na naukę. I wierzę w szacowanie - chociaż nie wszyscy są w tym dobrzy, musi być lepsza niż tylko wskakiwanie i programowanie, nie wiedząc, jak długo zajmie to zadanie.

— Dawood ibn Kareem

Pomaga uzyskać wpisowe, jeśli zachęcisz członków zespołu do opracowania szacunków przed zobaczeniem planowanego czasu i nie przekroczą znacząco planu. Posiadanie ich oszacowania przed obejrzeniem innych oszacowań również pozwoli uniknąć poparcia oszacowań.

— BillThor,

@BillThor: Na pewno sprawisz, że facet wykona pracę, aby ją oszacować, i wykorzystaj jego liczby jako punkt wyjścia. Właśnie oszacowałem pracę i powiedziano mi „Myśleliśmy, że będzie to 1/3 tej pracy”. Dlaczego nawet zawracali sobie głowę pytaniem, czy wie, ile to zajmie?

— mattnz

7

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.

— Bryan Oakley
źródło

2

+1 za kontrolę wersji i sprawdzanie kodu wcześnie i często.

— jmq

2

Uważam, że kontrola źródła jest tak niezbędnym procesem, że powinna być wykonywana niezależnie od składu zespołu, bez względu na wszystko.

— maple_shaft

6

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.

— mattnz
źródło

+1 za przydzielenie czasu na mentoring i szkolenie. Skuteczny lider technologiczny sprawia, że młodsi programiści są produktywni.

— wałek klonowy

„Nie jesteś zasobem programistycznym dla projektu”. Zastanawiam się, czy jego kierownictwo czuje to samo, heh. Mam nadzieję, że nie zostaniesz programistą „bohatera” projektu.

— jmq

Miałem wrażenie, że OP był po prostu najbardziej zaawansowanym programistą i nie miał żadnego specjalnego tytułu ani obowiązków (tj. Nie jest on „liderem technologicznym” ani „architektem”). W takim przypadku z pewnością jest zasobem programistycznym i prawdopodobnie oczekuje się, że będzie najbardziej produktywny.

— TMN

@TMN: Odzwierciedlałem rzeczywistość tego, co dzieje się w zespole z jednym wykwalifikowanym / doświadczonym facetem i wszystkimi innymi znacznie mniej wykwalifikowanymi. Bez wątpienia doświadczony facet, jeśli koduje, będzie najbardziej produktywny i oczekuje się, że będzie kodował. ZESPÓŁ będzie najbardziej produktywny, jeśli tego nie zrobi. W nieoświeconej organizacji menedżerowie mierzą indywidualne wyniki, więc najlepszy facet źle wygląda, robiąc to, co najlepsze - sprawiając, że TEAM występuje, i dostaje za to niewielką nagrodę. Lepiej powiesić juniorów na sucho i sprawić, by wyglądał świetnie.

— mattnz

1

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”

— śmieciowy
źródło

0

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.

— Jason Sebring
źródło

Divide & Conquer ma swoje pułapki. Widziałem, jak kończy się to, gdy każdy podzbiór wymyśla koło (źle) z powodu podobnych problemów, z którymi boryka się cały zespół.

— NWS

Tak, szczególnie jeśli jesteś w oddzielnych budynkach, dlatego staram się trzymać wszystkich w otwartej przestrzeni i regularnie spacerować. To, co robię, to budowanie podstawowych sygnatur API i ustawianie zespołów, aby je budowały, aby wszystko się łączyło.

— Jason Sebring