nám mikro-interakce ◦ i kdybychom si stokrát mysleli, že jsme asociální ◦ izolace může mít znatelný negativní vliv na psychiku • Asynchronní code review přestávají fungovat, protože ve skutečnosti nebyly tak úplně asynchronní. • Porady online jsou z principu delší, zdají se méně produktivní ◦ není tak snadné vycítit náladu v místnosti ◦ úspěšné sdělení je složitější online než osobně • Když už si voláte s kolegou, je snadné si sdílet obrazovku Znak doby
rozvíjí se • Pair programming - dva lidi u jedné klávesnice, jeden naviguje, druhý píše • Mob programming - více než dva lidé u jedné klávesnice, jeden naviguje, druhý píše, další kontrolují, hledají, zapisují Mob programming, Pair programming a Sólo vývoj
friends. Pairing is more like a date. Much more focused and intense. Working alone is, well…, being alone.” - Allen Holub (twitter) “Pair programming isn't 2 people doing the work of one. It's 2 people avoiding the rework of 7.” - Jason Gorman (twitter) Mob, Pair a Solo programming
• Méně distrakce - je čistě ve vašich rukách. • Často vás ale přeruší nějaký nedostatek ◦ znalostí - “Musím najít jak se to dělá…” ◦ cíle - “Co že to tam chtěli?” ◦ energie - “Ty jo, už mi to dneska fakt nemyslí...” • Chybí feedback, sebereflexe je také značně náročná Solo programming
dialogu, ne z monologu. • Můžete se střídat v intenzivní činnosti. • Udržíte déle soustředění na práci, neodbíháte myšlenkami. • Je to výrazně náročnější, je nutné dělat přestávky. • Nesólový vývoj přirozeně podporuje ◦ knowledge sharing ◦ zastupitelnost ◦ kvalitu (ve smyslu, že se nevrátí tolik support issues) Pair programming
znamená méně context switchů. ◦ JIRA tasky, ◦ zápisky, ◦ průzkum jak se co dá udělat, ◦ komunikace na Slacku, ◦ …vývoj neznamená jen několik málo činností. • Ke shodě napříč týmem dojde snadněji. ◦ K neshodě bohužel taky. • Občas už je to moc, ale poznáte poměrně snadno, kdy to můžete rozpustit. • Není to pro každého, ale pokud to nezkusíte, nemůžete to vědět. Mob programming
• Smiřte se s tím, že (nedokumentovaná) komunikace je v týmu zásadní, normální a žádaná. • Fred Brooks - Myhical Man-Month (1975!) - čím větší tým, tím více nutných interakcí • Asynchronní code review je neosobní, často nudné, mnohé se přehlédne ◦ stejně se zeptáte, co tím kódem autor myslel ◦ bude se to muset opravit, nebylo by lepší kdyby takový kód vůbec nevzniknul? ◦ je pomalé Ale víc lidí na jednom tasku... to bude drahý, ne?
mobovat z obavy o vyšší časovou náročnost - aniž byste si to nastudovali, jste hloupý manažer. ◦ Vaše role v týmu je odstraňovat překážky, ne je vytvářet. • Máte-li pocit, že tyto techniky nevedou (dostatečně rychle) ke správnému cíli ◦ mluvte o tom otevřeně, ◦ staňte se součástí párovací/mobovací session, ať pochopíte o čem to je Software není výrobní proces a dva lidi nevyrobí dvakrát tolik software - obzvlášť pokud má být v jednom funkčním celku. Ale víc lidí na jednom tasku... to bude drahý, ne?
s někým, ne sám. • Osobně mi nepřijde přínosné dodržet techniku podle knížky, ale je to věc osobní preference. ◦ Jako kata je to ale dobrý nástroj, pak už to půjde samo. • Krásně to kde, když jsme i na osobní rovině na stejné vlně. ◦ A bohužel opačně. Pokud si navzájem nesednete, má to dopad na práci. Najednou je všechno špatně a spíš hledáte chyby druhého, než abyste byli konstruktivní. • Když jsem kódil sám ◦ Musel jsem se často doptávat - ať už googlu, zadání nebo kolegy z protější strany. ◦ Chyběl mi feedback, zvlášť když jsem zvolil nestandardní postup. ◦ Chyběla mi jistota, že jsem něco nepřehlédnul. Moje osobní pocity
říkalo brainstorming. ◦ Když není jasné, čeho chcete docílit. Vezměte do party stake-holdery, jako výsledek stačí i jednoduchý prototyp k dopracování. Nepočítejte s tím, že v takovém případě něco finálního vznikne, spíš si budete povídat. ◦ Když práce zahrnuje plejádu technologií nebo vazeb. ◦ Alespoň jednou za čas. • Nemobujte ◦ V širším složení, než je přínosné. O přínosnosti rozhoduje spíš pozvaný, než organizátor. Klidně se v půlce omluvte, že už do toho nemáte co přinést a držíte palce. ◦ S cílem něco vytvořit, pokud na to nejste dobře připraveni (například budete teprve číst zadání) Kdy (ne)mobovat
není úplně jasné. ◦ Když se pouštíte do neznámých vod nebo si nejste jistí s daným stackem. ◦ Když vám chybí motivace něco dělat. • Nepárujte ◦ Když je potřeba něco opravdu hluboce rozmyslet. Ale jen jako mezikrok před tím, než navrhované řešení ukážete ostatním. ◦ Když nemáte momentálně s kým, jako nouzové řešení. Kdy (ne)párovat
špatná rozhodnutí, které zanesete teď, se stokrát vrátí. ◦ Než rozpracujete novou fíčuru. dtto • Sólujte ◦ Když je potřeba hluboké soustředění. Ideálně jako mezikrok před tím, než to, co vznikne, ukážete ostatním. ◦ Když je jasné, jak pokračovat a už je to potřeba “jen nakódit”. Ale pozor, připravujete se o feedback na malá rozhodnutí (loop vs stream atp.) ◦ Když váš typický den je samý meeting, telefon, email, support. Ale to máte jiný problém ;) Kdy (ne)sólovat
nejde, změňte složení • dominantní osobnosti ◦ mluvte spolu, i dominantní osobnost dokáže spolknout vlastní ego, když o tom ví, ◦ přizpůsobte se (dominantní osobnost může udávat směr, ostatní ji korigují pokud je špatný) • tiché vody ◦ mluvte spolu (retro), ale netlačte na to ◦ ve skupině nemusíte nic říct a přitom se mnohé naučit • příliš mnoho kuchařů v jedné kuchyni ◦ řekněte si rovnou, kdo bude mít hlavní slovo - a vystřídejte na další session Obecně pomůže nebýt přehnaně formální, uvolnit atmosféru, nemluvit jen o práci. Problémy při pair a mob programming
(delší úseky pro skupiny) ◦ pro více organizované pravidelný režim ◦ pro ad hoc je zapotřebí se dobře navzájem znát nebo alespoň respektovat nečekaná přerušení ◦ výhodou zůstává, že na práci může pokračovat ten, kdo zůstal • nevhodné prostředí ◦ rušná kavárna nebo open-space vedle bufetu není dobrý nápad • technické poruchy (internet, bugy v nástrojích) ◦ kupte si dobrý USB mikrofon, ◦ jako jediný nástroj postačí i sdílení plochy a nějaký Slack, ◦ s internetem a výpadky proudu toho moc neuděláte Problémy při pair a mob programming
novým API. • Debugging/Support ◦ Ty nejzáludnější oříšky potřebují víc než jedno oko tak nebo tak. ◦ Příčina a řešení jsou často víc než na jednom konkrétním místě. • Infrastructure/Ops ◦ Velmi přínosné namíchat, pokud stále ještě oddělujete adminy a programátory • V podstatě jakýkoliv kreativní proces, u kterého je přínosný feedback, druhé oko a odlišné zkušenosti. Zkuste to a povězte o tom světu. Je to vhodný jen na nový fíčury?
• Občas si zavolejte nebo sedněte ve dvou spolu nad jednou věcí ◦ Třeba hodinu nebo dokud vám to přijde přínosné. Hodinu mimo sólo režim nepozná ani ten nejhorší manažer, obzvlášť remote. ◦ Jednou se pusťte do tasku jednoho, jindy druhého. Střídejte se v roli prezentujícího (drivera). ◦ Ne, neotravujete toho druhého zbytečně - zvlášť když to je plánované dopředu. • Pokud vám technika sedne, stane se z ní běžný návyk sám. • Zahoďte code review, pokud jste na tom párovali. • Jakmile cítíte, že vám chybí druhé oko, zavolejte si o pomoc. • Pokud narazíte na nějaký pekelný problém na produkci, zkuste to vyřešit raději rovnou společně. Jak začít?
Chovejte se k sobě s respektem. • Žádná otázka není blbá. • Nebojte se selhat. ◦ “Kecám do toho moc?”, “Je ten nápad dostatečně dobrej?”, “Nevím vůbec o čem mluví.” ◦ Zapomeňte na to a nabírejte zkušenosti, spolupracujte, ptejte se. Pokud se vám zdá, že neříkám nic nového a s kolegy si společně sednete/zavoláte kdykoliv se vám to zdá potřebné, tak to asi děláte správně. Nemá smysl stát se otrokem nástrojů a technik. Zkuste při tom sledovat, jestli při sólo práci máte autorské bloky nebo jestli vás sociální interakce příliš nepřetěžují a reagujte na to úpravou režimu. Na závěr
jurri
schroneko
manfredsteyer
bkuhlmann
kangnux
gotok365
scalar
zsmb
seike460
inouehi
ruzia
luisasofie_xoxo
kasacchiful
jponch
afnizarnur
brettharned
chriscoyier
pedronauck
michaelherold
jeffersonlam
tammyeverts
chrislema
philhawksworth
keathley
sstephenson
