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.