28.09.2010

Párová práce v provozu a údržbě SW

Párové programování je známé téměř každému kdo něco ví o vývoji software. Pro mnohé se dokonce párové programování rovná Extremnímu programování jako přístupu. Párová práce obecně (nejen programování) a jeho implementace v případě provozu a údržby tak rozšířená není, především díky časté argumentaci, že v tomto kontextu není použitelná či není možné ji plánovat. Příspěvek diskutuje párovou práci obecně a ukazuje, jak je možné ji použít v provozu, údržbě a podpoře informačních systémů a IT služeb.

Párové programování je pravděpodobně nejvíce kontroverzní Agilní praktika. „Sedět celý den ve dvou s kolegou a programovat to, co bych byl schopen naprogramovat sám? Je mi to nepříjemné… Co na to řekne můj nadřízený? Bude si myslet, že jsem neschopný. Platí nás dva a uděláme práci za jednoho člověka…“ Toto je jen minimum názorů, které jsem o párové práci slyšel od kolegů a spolupracovníků. Párová práce je těžká, protože atakuje naši komfortní zónu a naše ego (říká nám, že nejsme nejlepší, že děláme chyby), proto je její implementace náročná, je často nepochopená a odmítána tolika lidmi.

Překročení komfortní zóny není příjemné …

Jednou z příčin odmítání a nepochopení párové práce je také tradiční pohled managementu řízený aktivitami a také utilizací (musíme reportovat 8h aktivit denně; ano 8h aktivit denně je důležitější než celkový výsledek). Tento pohled je zaměřený na aktivity spíše než na výsledek. Jádrem je maximální utilizace lidí v týmu s cílem doručit řešení co nejdříve v dané kvalitě. Jakýkoliv prostoj je brán jako ztráta. Důsledkem tohoto postoje je pak například mnohem více chyb, jelikož programátor musel programovat dál zatímco čekal na výsledky testů od testera (pozdní zpětná vazba). Oprava těchto chyb je ale opravdová ztráta (waste). Z pohledu tradičního managementu však ne, programátor je totiž plně utilizován! To jsme ale trochu odbočili. Pojďmě tedy připomenout, co to vlastně je párová práce a párové programování.

Párové programování

Nejznámější verzí párové práce je tzv. párové programování (Pair programming) velmi známé a propagované Kentem Beckem v Extrémním programování [Be01]. Párové programování vyžaduje dva spolupracující programátory u jednoho počítače. Oba se při práci vzájemně doplňují a střídají. Jeden může psát unitový test a druhý už přemýšlet o implementaci dané třídy. V průběhu párového programování se nemění pouze členové dvojice u klávesnice, mění se také samotné páry – členové týmu rotují. Jedná se o plánovanou aktivitu, ne ad hoc přístup podle potřeby (který je samozřejmě také přínosný).

Párové programování má několik nezanedbatelných, jasně viditelných přínosů [Be01], [WK99]:

  • Větší kvalita kódu – před kolegou programátorem tíhneme k tomu přijít s lepším řešením, než bychom použili, pokud bychom kód psali sami.
  • Vícero vývojářů přispívá k návrhu aplikace – při rotaci párů se u kódu vystřídá více programátorů, jejich názory/řešení jsou konfrontovány s více lidmi, jejich znalost je přenášena na jiné.
  • Jedná se o konstantní revize kódu – není třeba provádět další sezení, schůzky navíc, záběr je širší, než můžeme během formálních revizí kódu obsáhnout.
  • Zvýšená morálka – pro některé je programování v páru zábavnější, než programování o samotě (většinou extraverti) a pokud mám vedle sebe kolegu tak opravdu programuji, nesurfuji, nepíši maily kamarádům či manželce.
  • Kolektivní vlastnictví kódu – pokud každý na projektu párově programuje a páry často rotují, každý člen týmu si vytvoří znalost zahrnující většinovou bázi kódu, nejen části aplikace. Každý je pak nahraditelný a dovolená, nemoc či odchod jednoho člena týmu neznamená pohromu pro určitou část aplikace. Minimálně na určitý čas je v týmu někdo, kdo je schopný kolegu nahradit.
  • Mentoring a sdílení znalostí – párové programování je nejjednodušší (rozuměj nejméně bolestná a nejefektivnější) cesta předání/nabytí znalosti. Dokonce i zkušený kolega, který znalost předává se může naučit nové věci.
  • Větší sounáležitost týmu – lidé se více poznají, střídají se ve spolupráci, naučí se více spolupracovat a komunikovat, pochopí odlišnosti kolegů.
  • Programátoři jsou méně vyrušováni dotazy ostatních, jsou tedy méně často rozptylování od práce a nejsou tak často nuceni přepínat kontext, což vede ke snížené produktivitě.
  • Potřebný menší počet pracovních stanic – extra (volné) stanice mohou být v průběhu párového programování využívány například pro proces neustálého integrování či pro hledání dokumentace a možných řešení na fórech apod.

Podívejme se na následující obrázek Scotta Amblera [Am06] zobrazující cenu chyby a rychlost zpětné vazby v případě že programujeme v páru a v případě, že programujeme sami a čekáme na odezvu testera. Zajímavé, že?

Cena chyby v průběhu životního cyklu aplikace a techniky minimalizující cenu opravy chyby v různých fázích.

Typické námitky ohledně párové práce

Technika párového programování má spoustu zastánců i odpůrců. Typickou námitkou manažerů je, že stejnou práci nyní dělají dva lidé, tudíž je produktivita těchto dvou lidí přibližně poloviční či že dostanou stejnou práci se zdvojenou kapacitou/náklady (ano, manažeři často vidí členy týmu jako zdroje či náklady).

Další námitkou, ale naopak z řad vývojářů či pracovníků údržby způsobená pravděpodobně ješitností, jsou protesty proti párové práci, jelikož tvrdí, že nepotřebují nikoho do páru, že jsou dostatečně zkušení, že dělají stejně kvalitní řešení a podobné námitky. Realita je však jiná, řada empirických statisticky významných studií a reportů dokazuje mnohem (díky párovému programování) kvalitnější řešení dodané v kratším čase, či oproti tradičním metodám a postupům vůbec dodané, viz například [Op07], [Con95], [Nos92], [WK99].

Jako jeden z příkladů uvedeme studii profesora Noska z Temple University provedenou v roce 1998. Profesor Nosek studoval 15 zkušených programátorů řešících složitý problém po dobu 45 minut. Daný problém se vztahoval k jejich organizaci a daní programátoři ho řešili v jim známém prostředí s jimi používanými nástroji. Zmíněných 15 programátorů rozdělil na 5 řešících problém samostatně (kontrolní skupina) a zbývajících 10 rozdělil do dvojic (experimentální skupina), které pak řešili stejný problém párově. Jak jednotlivci, tak páry měli stejné podmínky, prostředí a k dispozici jim známé nástroje. Studie shrnuje výsledky pomocí statistických oboustranných T-testů:

  • K překvapení všech manažerů i zúčastněných všechny experimentální skupiny (dvojice) překonali jednotlivce (kontrolní skupina).
  • Dvojice také zmínili, že nebyly pod tlakem, ale řešení si více užívaly.
  • Dvojice také více věřili svému řešení.
  • Dvojice doručily řešení úkolu v průměr o 40% rychleji s tím, že doručili kvalitnější algoritmus.

Před experimentem byli programátoři skeptičtí ohledně řešení stejného problému ve dvojici, mysleli si, že to opravdu nemůže být zábavný proces. Výsledky studie však ukazují opak a to jak v efektivnosti a kvalitě výsledků, tak v jejich pocitu a požitku při společném řešení [Nos92].

Párová práce v provozu a údržbě

Jelikož některé z výše zmíněných výtek jsou na denním pořádku a zažité zvyky se překonávají jen těžce, je vhodné začít plánovaně s párovou prací (nejen programováním) malými kroky. Podle naší zkušenosti jsou nejlepší praktické výsledky, když nepoužíváme párovou práci po celý den všech 5 dní v týdnu, ale pouze v určitých plánovaných (ne tedy ad hoc) případech provozu, podpory a údržby IT služeb či informačních systémů:

  • Párové hledání příčiny kritických a středně kritických problémů/chyb a návrh řešení – párově se snažíme identifikovat možnou příčinu problému/chyby a navrhnout jeho řešení/opravu. Díky párovému spolupráci je identifikováno více možných příčin, zaznamenáno více symptomů (logy, záznamy monitorovacích nástrojů) a rychleji lze projít více možných postupů (znalostí báze, fóra). Navíc určité symptomy částečně známé jednomu pracovníkovi mohou doplnit chybějící informaci druhému. Další variantou může být paralelní práce: jeden programátor hledá příčinu díky symptomům a druhý mezitím napíše unit test pro danou část, čímž roste také sada testů a tím pádem i kvalita řešení. Tento přístup tedy vede nejen k rychlejší identifikaci příčiny a rychlejšímu a kvalitnějšímu řešení, ale také k neustálému učení a rostoucí znalosti základny zdrojového kódu.
  • Návrh implementace změny, kdy v páru navrhneme a probereme několik možných řešení podle pracnosti a dopadu – jedná se vlastně o instantní oponenturu návrhu. Samozřejmostí je pak také implementace vývojářského testu, který může napsat jeden vývojář, zatím co druhý již píše strukturu vybraného řešení.
  • Revize kódu implementované změny/opravené chyby – samotné párové programování lze považovat za instantní revizi kódu. Přísedící s námi prochází to, co právě píšeme a může si všimnout nějaké chyby či nevhodné konstrukce. Navíc díky tomu, že říkáme, co píšeme, neopomeneme nějakou základní aktivitu (typicky inicializace proměnných, objektů či uvolnění zdrojů, testování na null). Vyčleníme párovému programování tedy určitý časový úsek denně či týdně podle velikosti změny/opravy (doporučujeme provádět hlavně s architektem produktu, IT služby či daného modulu).
  • Spolupráce zkušeného a nezkušeného programátora – nezkušený se učí tím, že okoukává práci zkušeného a naopak v případě, že nezkušený sedí u klávesnice, zkušený na něj dohlíží, vysvětluje a instruuje ho, v případě potřeby se vymění, aby bylo vysvětlení prakticky ukázáno (sdílení znalosti touto formou na reálné práci – oprava chyb či implementace změny, je nejefektivnějším způsobem učení).
  • Kontrola dodržování navržených mechanismů architektury – architekt během dne párově programuje určitý čas (například 30 minut až 1 hodinu) s jednotlivými programátory, aby ukázal použití mechanismů architektury (u klávesnice architekt) a aby se ujistil, že jsou tyto mechanismy a pravidla následovány (u klávesnice programátor) – cílem je udržení kvalitního a přehledného kódu a pravidel architektury.
  • Předání znalosti architektury IT služby či informačního systému týmu údržby – programátoři předávají znalost architektury informačního systému či IT služby pracovníkům údržby pomocí párového programování (konkrétně přímo ukázkou opravení chyby/implementace změny) na pravidelné bázi – několikrát týdně v průběhu fáze předání znalosti či neustále v průběhu údržby (pokud se jedná například o týmy u stejné organizace).

Zastáncům Extrémního programování (XP) se budou výše zmíněné názory zdát pravděpodobně málo extrémní. Z naší zkušenosti však tento mix přinesl nejlepší výkony a výsledky hlavně v úvodních fázích implementace této praktiky a přináší je i v kontextu poměru investice/přínos v provozu a údržbě. Kritickým faktorem úspěchu párové práce je pravidelná obměna pracovníků pracujících v páru, většinou po určitém časovém intervalu (každý den či týden).

Plánovaná vs. neplánovaná párová práce

Většina z nás provádí párovou práci (většinou návrh, programování či lokalizaci chyby) intuitivně, neplánovaně, ad hoc podle potřeby. Typickým příkladem takové párové práce v údržbě může být následující ukázka:

  • Kolega: „Mám tady někde chybu co mám opravit a nemůžu ji lokalizovat, dělám na tom už asi 3 hodiny, nevíš čím to může být? Dělal si na tomto modulu minulý měsíc…“
  • Vy (vyrušen v práci jdete pomoci kolegovi)
  • Kolega: „Podívej, procházím log a zde to podle této výjimky způsobuje metoda této třídy. Když ji ale debuguji, tak … Ahá, díky moc za pomoc, to je ono!!!“
  • Vy (mírně podrážděně): „No, nemáš za co…“ a jdete si sednout na své místo a vzpomínáte, kde byl ukončen váš myšlenkový tok.

Toto rychlé odhalení příčiny chyby je přesně ukázka síly párové práce. Důslednost, kterou zvolil kolega díky vaší přítomnosti pomohla odhalil zdroj chyby (a to pouhým následováním postupu, který by oba v páru následovali hned od začátku společného úkolu, ne až po 3 hodinách práce [1]). Výstupem takové ad hoc párové práce je sice úspěšné vyřešení problému, má ale několik neblahých důsledků:

  1. Prvním a také nejzásadnějším je neustálé vyrušování ostatních kolegů, což způsobuje přepínání kontextu a ztrátu jejich soustředění (tzv. task switching). Ochota takto vyrušovaných kolegů pomáhat je den ode dne menší.
  2. Druhým viditelným problémem je plýtvání času. Pracovník se ozval se svým problémem až po třech hodinách neúspěšného hledání zdroje chyby, v případě plánované párové práce mohl být problém vyřešen během několika minut.
  3. Úspěšnost neplánované párové práce také závisí na typologii daného člověka, extrovert se pravděpodobně nebude rozpakovat zeptat brzy, díky častému rušení ho ale kolegové mohou později ignorovat. Naopak introvert se nemusí zeptat vůbec a bude spoléhat na proaktivitu někoho ze zkušenějších kolegů.

Z těchto důvodů je plánovaná párová práce využívaná pro výše zmíněné účely mnohem efektivnější a přispívá také k lepší týmové práci a porozumění kolegů.

Je zřejmé, že párové programování je mnohem více o softskills než o technických dovednostech a jeho zvládnutí vyžaduje mnoho snahy a pokusů od všech zúčastněných a podporu kouče minimálně pro řešení vznikajících konfliktů.

Použité zdroje:

  • [Am06] Ambler, S.: The Full Life-Cycle Object-Oriented Testing (FLOOT) Method
  • [Be01]  Beck, K.: Extreme Programming ExplainedEmbrace Change. Addison-Wesley. 2001.
  • [Con95]Constantine, L. L. 1995 Constantine on Peopleware. Englwood Cliffs, NJ, Yourdon Press.
  • [Nos92] Nosek, J. T. The Case for Collaborative Programming. Communications of the ACM. Březen 1998, pp. 105-108.
  • [Op07] Opelt, K.: Overcoming Brook’s Law. In: Proceedings of 8th International Conference XP 2007, Berlin: Springer, pp. 175-178, doi …
  • [WK99] Williams, L. A., Kessler, R. R. 1999 All I Really Need to Know about Pair Programming I Learned in Kindergarted. Communications of the ACM, vol. 43, issue 5, pp. 109-114
  • [1] Zde úřaduje tzv. nepozorná slepota, kdy jsme schopni přehlédnout viditelné chyby, změny či paradoxy, jelikož se naše soustředění zaměřuje pouze jedním směrem a také je nastaveno určitým směrem díky znalosti řešení, viz například příspěvky a experimentální videa (http://psyche.cs.monash.edu.au/v5/psyche-5-03-mack.htmlhttp://viscog.beckman.uiuc.edu/djs_lab/demos.html).

Máte k tomu co říct?

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *