Neboli ste na Agile Prague 2012? Alebo ste boli a chcete si pripomenúť niektorú prednášku?

Videá sú už online na http://agileprague.com/news/news/videos-2012.htm

Poznáte tento vtip?

Otázka: „Je to veľké, hučí to a pohybuje sa to po lúke v kruhu. Čo je to?“

Odpoveď: „Trabant s trávou privretou do dverí.“

Ja viem. Ako vtip to nie je nič moc. Ale ako metafora toho, čo možno trápi zavádzanie agilných metód, to môže byť trefné. Ale poďme pekne po poriadku.

Prečo vodopád vyhráva? To je otázka, ktorá ma v poslednej dobe napáda, keď uvažujem o spôsoboch riadenia projektov, o ktorých počujem od známich pracujúcich v rôznych IT firmách. Sú to často buď metódy riadenia tak povedané ukuté na kolene bez nejakého základu, ktorý by mal hoci aj názov (to platí skôr pre menšie firmy) alebo komplikované rozsiahle metódy s dlhodobým (niekedy až nepríjemne byrokratickým) plánovaním (to platí skôr pre väčšie). To samo o sebe nie je problém. Ak metóda naozaj funguje, nech sa používa. Aj samotné agilné metódy nabádajú k prispôsobovaniu, čo môže viesť k úplne svojskému spôsobu riadenia (a asi by to k tomu aj viesť malo). To, čo mi na tých metódach pripadá zaujímavé je, že sa viac podobajú na vodopád ako na agilné metódy. Čím to je, že ľudia automaticky viac inklinujú k systému ako je vodopád oproti systému agilného projektu? Možno je to naším školským systémom, ktorý agilné metódy zatiaľ nevyučuje (opravte ma, ak sa mýlim). Možno je to prostredím, v ktorom žijeme (napríklad iné oddelenia vo firme, zákazník atď.) a ktoré je viac neagilné ako agilné. Alebo je to možno tým, že agilné metódy nie sú tak prirodzené ako vodopád. To posledné mi pripadá ako nebezpečná odpoveď. Už len preto, lebo tie prvé dve môžu byť otázkou času, ale tá posledná nie. Čo myslím tým prirodzené?

Ten pojem ma napadol keď som sa snažil človeku, inak už znalému agilných metód, vysvetliť, že pri agilnom vývoji sa paralelne píše kód a testuje. Z jeho výrazu tváre mi bolo jasné, že neporozumel. Nedokázal si to predstaviť. Ako sa to dá robiť paralelne? Veď jedna činnosť závisí od druhej. A tu je podľa mňa jedna z hlavných komplikácií. Myslím, že paralelná práca je pre ľudí omnoho ťažšie predstaviteľná ako sekvenčná. Sekvenčná je proste jednoduchšia. Prirodzenejšia. Keď sa kód napíše, otestuje sa. Nie je čo riešiť. Je to úplne jednoduché. Agilné metódy naopak tento proces komplikujú (s úmyslom skvalitniť a zefektívniť ho). A aj keď ponúkajú mnoho nástrojov na jeho zvládanie (ranné porady, sprint backlog, automatizácia…), tá paralelnosť tam stále je a stále to celé tak trochu komplikuje. Preto je možno menej pravdepodobné, aby sa samorastom vyvinula skôr metóda agilná ako tradičná. Lebo bez znalosti a viery v to, že to paralelne funguje, to nikto používať nezačne. Nechápte ma zle. Toto zamyslenie nie je kritikou agilných metód. Je to skôr ako pohľad do zrkadla. Ako keď sa ráno postavíte pred zrkadlo. Nerobíte to preto, aby ste sa zkritizovali. Robíte to preto, aby ste videli čo treba opraviť skôr ako sa vypustíte medzi ľudí.

Možno by ten problém paralelnosti nebol až taký veľký, ak by v tom nebol jeden háčik. Súčasné verzie agilných metód pracujú s pojmami, ktoré doteraz boli sekvenčné. U nás sme pred časom zaviedli praktiku, že keď úloha súvisí s grafickým rozhraním, tak sa pri jej štarte poradí najprv programátor s testerom o tom, ako to má vyzerať. Neviem, do ktorej fázy vývoja by ste takúto činnosť zaradili vy, ale pre mňa je to testovanie (ktoré prebieha paralelne s vývojom). Mnoho ľudí si ale pojem „testovanie“ spája s klasickým testovaním z vodopádového modelu. A teda keď im niekto povie, že majú paralelne testovať, tak si to nedokážu predstaviť. Podstata tohoto problém je, že agilné metódy znamenajú posun v úplných základoch procesu ale slovník pritom ostal rovnaký. Tieto pojmy potom vyvolávajú asociácie o klasickom vodopádovom modeli, že môže sťažovať vysvetľovanie a zavádzanie. Sme ako ten trabant na lúke. Pridávame plyn, aj sme v pohybe ale výhľad za oknom je akosi stále rovnaký. Slovník nás drží stále pri vodopáde.

Čo je riešením tohto problému? V tom nemám tak úplne jasno. Jedno riešenie by bolo vymyslieť nové pojmy pre fázy vývoja. Teda agilné testovanie by už podľa možnosti nemalo mať slovo „testovanie“ vôbec v názve. Ale toto vylepšenie by celý proces mohlo ešte spomaliť. Podobné riešenie sú story pointy (nový pojem) a človekodni (starý pojem). Tá priepasť medzi týmito pojmami bola však tak veľká, že sa medzi to museli vložiť ideálne človekodni (taký vývojový medzistupeň), aby to bolo ako tak stráviteľné. Nové pojmy pre vývojový proces by pravdepodobne rozvírili trochu hladinu, ale hlavne by mohli znamenať posun. Osobne považujem súčasnú verziu agilných metód za krok vpred v smere, v ktorom sa hýbe celý okolitý svet. Ostáva len dúfať, že kvôli jednému kroku nezabudneme chodiť.