Vedu tým - co s tím?

Vedení týmu v kontextu předmětu PV168 klade důraz na jiné aspekty, než co obnáší vedení týmu v praxi. Text níže není vyčerpávající seznam věcí, jedná se spíše o víceméně kategorizované myšlenky, které vám mohou pomoci si položit ty správné otázky.

Obecné věci

Vedení týmu nemá být věc na sílu, preferovaný je spíše konsenzus. Dobré vlastnosti vedoucího týmu jsou konzistence a důslednost.

Optimalizace výsledné práce

Běžný styl vedení projektu, kdy je cílem jej úspěšně zakončit. V praxi často viděný, byť dává smysl pouze v krátkodobém horizontu.

Pro potřeby PV168 doporučujeme upozadit, byť k tomuto stylu budete tíhnout.

Optimalizace předávání znalostí

Styl vedení, při kterém se napříč členy týmu sdílí znalosti. V předmětu PV168 preferovaná varianta.

Bus factor

Kolik programátorů musí zajet autobus, aby nebylo možné pokračovat v projektu?

Anekdotická otázka ilustrující zastupitelnost členů týmu. Hodnota 1 znamená, že má vedoucí projektu problém.

Vedení

Jako vedoucí týmu můžete vést členy týmu, můžete vést projekt po technické stránce. Můžete klidně zastávat obě role, ale není hanba plnit jenom jednu roli a tu druhou nechat na jiném členovi. Primárně byste se měli starat o členy týmu a také o kalendář.

Vedení týmu jako takového bere čas. Mějte to proto na paměti, abyste si nebrali tolik vývojářské práce jako ostatní členové týmu.

Čím víc očí, tím víc Adidas

Každou věc, kterou kdokoliv na projektu udělá, by měly shlédnout také oči někoho dalšího. Autorská slepota je ošemetná věc.

kooperace je výhodná ve všech fázích vývoje
dochází k výměně znalostí
- dokonce od slabšího směrem ke zdatnějšími členu týmu

Morálka

nepřepalte začátek
nenechávejte věci na poslední chvíli
… tedy pracujte průběžně

Styl práce

Párové programování

doporučujeme oproti programování osamotě
stabilní dvojice
- po zažití klesá výměna znalostí v týmu
- nadále roste efektivita v případě implementačních i návrhových rozhodnutí
fluktuující dvojice
- výrazná výměna znalostí
- může způsobovat “drhnutí” po změně dvojce, než dojde k zažití
lze rozdělit i na vývojáře a testera
- výměna znalostí je víceméně zachována
- snížena efektivita implementačních i návrhových rozhodnutí

Dělení práce

vertikální
- #fullstack
- mírně pomalejší vývoj (všichni dělají všechno)
- lepší výměna znalostí
horizontální
- vede ke větší specializaci
- pozor na BUS FACTOR

Testování

je doporučené psát si unit testy
- ruční zkoušení aplikace je také užitečné
testuje stejná dvojice, která tvořila
- rychlejší
- riziko autorské slepoty
testuje druhá dvojice
- pomalejší
- lepší sdílení vědomostí

Code review

opačná činnost k návrhu
dělá jedna osoba
- pokud je výrazně technicky způsobilejší
- pozor na autobus
dělá celý tým, druhá dvojice
- předávání zkušeností

Návrh

dělí se na
- kompetence (horizontální dělení)
  - balíčky
- úrovně abstrakce (vertikální dělení)
  - třídy a vztahy mezi nimi
  - třída a její metody
(protřepat) nemíchat
- obzvlášť v případě horizontálního dělení

Procesní záležitosti

Komunikace

Vyberte si platformy, kterou budete používat pro komunikaci, pro trackování požadavků. Například Zoom, Discord, gitlab issues, osobní setkání.

Pravidelnost

stanovte si termín 1-2x týdně 10-15 minut
projděte
- kdo co udělal
- kdo co bude dělat
- kdo se na čem zasekl
pomůže k průběžné práci

Retrospektiva

po konci etapy (milestone) se setkejte
proberte
- co členům vyhovuje
- co jim vadí (a jak to opravit)
pochvalte dobře odvedenou práci

Nejdřív mysli, potom konej

Každé zadání si nejprve rozmyslete a až potom jej zhmotněte.

rozmyslete to společně v týmu
rozmyslete si to sami
- ale předneste myšlenky týmu
- samotným přednesem se donutíte k preciznější formulaci nápadu

Kdy je práce hotová

dohodněte si, co znamená, že je zadaný úkol hotový
- může se lišit dle typu práce
mají ho schválit ostatní členové?
má mít napsaný test?
má být ozkoušený?
má mít code review?
…

Práce s lidmi

Abnormální člen

je některý člen výrazně technicky zdatnější?
- nechte ho vést vývoj
- je lepší, aby méně programoval a více vedl ostatní
- bude mít důležitější slovo na code review nebo při návrhu
je některý člen výrazně horší?
- aktivně ho zapojujte do dění
  - klidně mu dávejte jednodušší, ale pracné úkoly
- střídejte mu dvojice

Konflikt

nechte horké hlavy vychladnout
- ale řeště problém za čerstva
diskutujte problém bez diváků
- například při problému dvou členů si vyslechněte každého zvlášť
- až pak se s nimi sejděte a mějte roli mediátora
preferujte osobní komunikaci
- pokud se nemůžete sejít, tak si zavolejte
- je lepší zapnout kameru
- vyvarujte se psané formě
  - chybí intonace a další komponenty komunikace

Teď si udělejme retrospektivu, jak se vám zatím daří vést tým.