Možno poznáte ten príbeh. Stretli ste sa so zákazníkom. On vám povedal, čo chce, aby ste mu vyrobili. Ujasnili ste si to ešte niekoľkými otázkami a odobrali sa splniť jeho prianie. Keď ste sa o dva mesiace znova stretli a ukázali mu výsledok, zamyslene si ho prezeral a vyhlásil, že by to chcel trochu zmeniť. A vy postupne zisťujete, že žiadna zmena nemusí byť posledná. Kde je problém? Ako je možné, že nevie na prvý pokus povedať, čo vlastne potrebuje? Continue reading
Author Archives: Peter Špireng
Vodopád, Agile a ten tretí
Ak ste súčasťou vývoja softvéru, asi ste počuli o vodopádovom modeli. Je to pomenovanie pre metódu riadenia pozostávajúcu z jednotlivých za sebou nasledujúcich krokov vývoja (zber požiadaviek, analýza, návrh atď.). Je dosť možné, že ste už tiež počuli o agile. O tých divných metódach, kde za jedným počítačom môžu sedieť dvaja a každý deň sa stojí na porade. A to by mohlo byť o riadení projektov všetko. Ale nie je. Je tam ešte tretia metóda. Má mnoho foriem a žiadne oficiálne meno, ale ja jej budem hovoriť chaos. Toto je príbeh o troch svetoch, v ktorých môže žiť softvérový projekt.
Vývojári a zákazník môžu mať v určitom smere protichodné záujmy. Hlavne čo sa týka pružnosti vývoja softvéru. Prvý svet je svet vodopádu a zmrazených, nehybných požiadaviek. Je to svet vývojárov, kde sa všetky zmeny pekne rozanalyzujú a zapracujú. Všetko má svoj prísny poriadok, vždy je jasné, čo bude nasledovať na celej dĺžke plánu. Je to svet, kde zákazník ledva prežije. Najprv je nútený pomerne presne odhadnúť pol roka alebo rok dopredu, čo bude chcieť a potom začne byť jeho hlas ignorovaný alebo potláčaný. A niekedy až po roku zistí, čo si to dal vlastne vyrobiť (a že chcel niečo tak trochu iné)
Na druhej strane tejto pomyselnej planéty projektov je svet plný ohňa, výbuchov a neustálej zmeny. Je to svet, kde kríza strieda krízu, kde sa požiadavky menia z hodiny na hodinu. Je to svet, kde je softvér samá záplata a hack, až vyzerá ako narýchlo zbitá búda. Je to svet zákazníka a meniaceho sa trhu, kde jeden ASAP strieda druhý. Je to svet, kde vývojár ledva prežije. Neexistuje žiaden pevný systém, ktorého by sa mal držať. Nemôže uvažovať strategicky, lebo nikdy nevie, čo bude zajtra, a už vôbec nie o týždeň, mesiac. Je nútený robiť len nevyhnutné zmeny v kóde, len toľko, aby to fungovalo a môžeme ísť ďalej. Takto vzniká technologický dlh, ktorý spôsobuje, že riešenia sú čím ďalej tým viac skratkovité, kód sa len viac a viac zauzľuje, tie isté problémy sa na rôznych miestach riešia rôzne a kódom sa ako nepríjemný smog rozlieza duplicita.
Ak by ste si nakreslili na mapu tieto dve svety a spojili ich priamkou, niekde uprostred by ste našli agile. Agile je krok od vodopádu smerom k zákazníkovi a krok od chaosu smerom k vývojárovi. Je to kompromis. Zatiaľ čo svet vodopádu je nehostinný pre zákazníka a svet chaosu pre vývojára, je agile prostredie, v ktorom dokážu prežiť obaja. Na jednej strane poskytuje vývojárovi systém, v rámci ktorého vie fungovať, plánovať zmeny a mať aspoň čiastočne stabilné požiadavky. Na druhej strane umožňuje zákazníkovi meniť priority pre krátkodobé cykly, získavať prehľad, čo sa vyrába a môcť to pripomienkovať. Aj preto je svet agile tak trochu divný. Je to hybrid. Kompromis. Nie je úplne prirodzený ani pre vývojára ani pre zákazníka. Je to ale niečo, s čím sa dá dlhodobo prežiť na obidvoch stranách.
Keď sa rozhodnete prejsť na agile, čaká vás zodpovedanie niekoľkých otázok. Viem určite o dvoch otázkach, ktorým sa nevyhnete. Jednej ľahkej a jednej ťažkej. Tá ľahká znie: Kam sa chcem dostať? Je ľahká preto, lebo informácií o tom, ako by mal vyzerať agile, je už dnes obrovské množstvo. Detaily sa nemusia s vaším prípadom zhodovať, ale ak správne zavediete základnú štruktúru, doplnia sa sami. A teraz tá ťažká: Kde vlastne som? Toto je ozajstný oriešok. Žiadna kniha, návod alebo prezentácia vám s ňou pomôže. Jediným človekom, ktorý na to vie odpovedať, ste vy. Nedarí sa vášmu obchodu? Asi žijete vo svete polárneho ľadu a mali by ste sa vydať smerom k rovníku. Obchod je fajn, ale vývojári sú nejakí zničení a stále hasíte nejaký požiar? Asi žijete vo svete horúceho trhu a mali by sa ste zamieriť do miernejších pásiem.
Ujasnenie týchto otázok je pre úspešnú transformáciu na agile kritické. Keď viete kde ste a kam chcete ísť máte body dva s ich vzájomnou polohou a teda mapu! A s mapou sa vždy cestuje ľahšie…
Fyzický vs. elektronický Scrum
Scrum, ako aj iné metódy riadenia (či už pre tím alebo osobné), vyžaduje určité nástroje na realizáciu. Zoznam, grafy a iné artefakty, ktoré sú pre beh metódy nevyhnutné. Tieto nástroje môžu existovať vo forme elektronickej alebo fyzickej. Elektronická forma predstavuje rôzne špecializované softvéry alebo prispôsobené všeobecnejšie nástroje (Calc, Excel..), zatiaľ čo pri papierovej je to najčastejšie samotný papier alebo tabuľa (magnetická, korková …). Diskusia o tom, ktorá z týchto foriem je vhodnejšia, je prakticky nekonečná a to z jednoduchého dôvodu: univerzálna odpoveď na túto otázku neexistuje. Respektíve existuje odpoveď, ktorá ale nepomáha problém riešiť, a to je: pre každý projekt je vhodná iná forma. Keď už ale príde na lámanie chleba, musíte si vybrať…
To, čo pomáha sa dostať z tohto bludného kruhu otázky a odpovede je fakt, že každá z týchto foriem má svoje výhody a nevýhody. Práve tento zoznam bonusov a potenciálnych rizík by mal byť prostriedok, ktorý umožní zvládať túto dilemu. Je potrebné len zvážiť, ktoré vlastnosti sú pre váš projekt najdôležitejšie a vybrať. Poďme sa teraz bližšie pozrieť na jednotlivé výhody a nevýhody.
Elektronika
Ak sa rozhodnete použivať elektronický nástroj, je výber taký široký, až to začína byť nepríjemné. Vybrať si môžete buď nástroj, ktorý je šitý priamo na vašu metódu, ktorý vám dá presne to, čo potrebujete, ale na druhej strane vás môže obmedzovať, ak potrebujete niečo naviac. Alebo si môžete siahnuť po univerzálnejšom nástroji, ktorý si budete musieť najprv prispôsobiť. Teraz mám na mysli vyššie spomínané nástroje ako Calc alebo Excel, s ktorými viete robiť naozaj veľa, ale chce to vedomosti a čas. Rozdiel medzi týmito dvoma kategóriami je hlavne v tom, že s tým prvým si kupujete aj metódu, s tým druhým nie. Prečo ale po softvérovom nástroji siahnuť:
-
prístup z rôznych miest – toto je asi najdôležitejšia výhoda. Pre distribuovaný tím je elektronická forma prakticky nevyhnutná. Ale členovia tímu nie sú jediní, ktorých stav projektu môže zaujímať. Riadiaci pracovníci, obchodné oddelenie alebo zákazník. Alebo hoci aj ten monitor vo vstupnej hale, ktorý vysiela Sprint Burnd Down Chart náhodným okoloidúcim.
-
vyhľadávanie – jednoznačne jednoduchšie ako pri fyzickej forme.
-
prenositeľnosť – kopírovanie, zálohovanie, dlhodobá archivácia.
-
ľahký prechod na papier – rôzne grafy a zoznamy je často možno jednoducho vytlačiť a získať tak ich fyzickú formu.
-
automatizácia – systém dokáže automaticky za vás vykonávať niektoré práce. Kreslí graf, počíta priemery, posiela e-maily…
Fyzické nástroje
Pod pojmom fyzické nástroje si môžete predstaviť akékoľvek jednoduché prostriedky, pomocou ktorých viete v reálnom svete zobrazovať stav projektu. Tabuľa, papier, fixa, pero, nálepka, magnet, lepiaca páska, špagát, žiarovka, siréna atď. S hotovými fyzickými sadami pre Scrum som sa zatiaľ príliš nestretol, ale ak prehľadáte internet, určite nájdete dostatok inšpirácie. Prečo ale siahnuť po fyzickej forme:
-
sloboda – jednoduché nástroje vám umožnia vytvárať ľubovoľné zložité objekty. Obyčajná popisovacia tabuľa s fixou a sadou lepiacich papierikov poskytuje neuveriteľné množstvo možností kombinácií toho, ako ich dokopy použijete. Niečo nefunguje, tak ako potrebujete? Zahodíte a nahradíte iným riešením. Ak nefunguje ani to, skúsite niečo iné. Takáto sloboda ohnúť nástroj do požadovaného tvaru môže byť pri softvéry problém. A že by mali mať ľudia navrch oproti nástrojom hovorí už aj samotné Agile Manifesto.
-
hmatateľnosť – svet softvéru alebo poskytovania služieb má oproti klasickej priemyselnej výrobe jednu nevýhodu – to, čo firma vyrába, s čím sa každý deň pracuje, nie je hmatateľné. Na prvý pohľad to nemusí vyzerať až tak podstatne, ale je dôležité si uvedomiť, že spoločnosť za posledné desaťročia prešla revolúciou, zatiaľ čo my ľudia sme skôr evolučná záležitosť. Hmatateľné predmety je možné si podávať, rozostavovať ich v priestore, ukladať na kopy alebo hoci aj hádzať do koša. Všetko toto sú pre ľudí prirodzené činnosti, preto aj práca s fyzickými nástrojmi je prirodzenejšia.
-
jednoduchšia viditeľnosť – ak sa nerozhodnete pre nejaké komplikovanejšie riešenie ako je zapnutý projektor, alebo každodenné tlačenie stavu na papier má elektronická verzia jednu nevýhodu – je uzamknutá do vášho monitoru. Oproti tomu je fyzická často umiestnená na nejakom viditeľnom mieste, a teda je omnoho ťažšie ju prehliadnuť (pre vás, manažment alebo kohokoľvek, koho by to mohlo zaujať). Stačí len otočiť hlavu.
Myslím, že rozhodnutie o forme by malo padnúť pre každý projekt zvlášť a dokonca, že by malo byť možné ho zmeniť, ak sa ukáže, že druhá forma je vhodnejšia. Každopádne je možné tieto formy udržiavať aj obe naraz – synchronizovať. To si ale vyžaduje viac úsilia, a teda je otázne či to naozaj stojí za to. Takto sa síce dajú získať výhody obidvoch foriem, ale zaplatíte za to monotónnou každodennou prácou a rizikom, že sa synchronizácia rozíde.
Fedexday
Náklady firiem na vytváranie motivácie u zamestnancov nie sú malé. Obľubené sú teambuildingové akcie, výlety, finančné prémie a pod. To všetko stojí peniaze. A pritom čínnosť ako je vývoj softvéru (a vývoj všeobecne) môže byť sama o sebe natoľko zaujímavá, že sa stáva motiváciou. Ak neveríte, dá sa to jednoducho overiť. Môžete si skúsiť Fedexday.
Pre zamestnancov je Fedexday zážitok, pre zamestnávateľa sa to nedá nazvať inak ako veľa muziky za málo peňazí. Fedexday je súťaž, kedy za 24 hodín (preto ten Fedex v názve) musíte vyvinúť a dodať (t.j. musí to byť funkčné) nejaký výsledok. Pre softvérové firmy to znamená hlavne dodanie softvéru. To, na čom budete pracovať, akú technológiu použijete a s kým na tom budete pracovať, je na vás. Práve táto sloboda venovať sa niečomu, na čo ste si už možno dlho brúsili zuby, je hlavným motorom akcie. Je to síce súťaž a na konci je vyhlásenie víťaza, ale žiadne reálne vecné ceny nečakajte. Tie by len poškodili hlavnú motiváciu a tou je zvedavosť a snaha niečo dokázať. Fedexday neznamená len, že môžete robiť, na čom chcete, ale aj to, že máte na to 24 hodín a nie viac. Za ten čas musíte byť schopný dodať to, čo ste si predsavzali.
Pred určitým časom som sa takejto akcie zúčastnil a myslím si, že je to niečo, čo je prospešné pre firmu aj zamestnanca naraz. Zamestnanec môže zažiť nevšednú akciu, pri ktorej si otestuje novinku alebo vytvorí niečo, po čom už dávno túžil. Firma zase za malý obnos (poskytnutie priestorov, pizza) u ľudí zvýši motiváciu k práci. Začať pracovať na obed jedného dňa, pracovať 24 hodín bez oddychu a na ďalší deň opäť na obed to prezentovať je zážitok, ktorý možno nie je až taký adrenalinový ako skok s bungee lanom, ale má svoju osobitosť. Jedna z vecí, ktorú vás to naučí je, že ste schopný dodať hotovú vec za kratší čas, ako ste mysleli. Pritom prostredie ani nástroje sa nemenia. Len vaša motivácia.
Fedexday vie byť pre firmu pomerne silným impulzom. Je podľa mňa lepší ako štandardná teambuldingová akcia, pretože ľudia si vyberajú, čomu sa budú venovať, a teda sú do toho viac zapojení ako do nejakých súťaží, ktoré niekto pripravil. Tímy sa formujú sami, myšlienky sa realizujú v krátkom čase a učiaca krivka je prudká. Po 24 hodínach máte dosť. Ste zrelý na sprchu a do postele. Ale kombinácia toho, že ste sa za tak krátky čas prehrýzli problémom a dodali niečo čo funguje, že ste pochopili, ako to máte celé postaviť a potom to postavili … to jednoducho stojí za to.
Agile Estimation and Planning
„Cítiť istotu je určite nepohodlné, ale byť si istý, to je na smiech.“ -čínske príslovie
Agilné metódy pomerne výrazne nabúravajú zažité postupy metód tradičných. Nielen že radia preniesť riadenie a zodpovednosť na ľudí, nepísať dokumentáciu (aspoň nie toľko ako predtým) a nerobiť analýzu (aspoň nie príliš dopredu), ale dokonca hovoria o tom, že dlhodobé a presné plány sú na nič. Odhadovanie a na ňom závislé plánovanie by sa malo robiť nepresne alebo krátkodobo. Odhady by mali tvoriť ľudia a zákazník by mal akceptovať neistotu v tom, čo bude dodané. To sú veci, ktoré sú niekedy (a v niektorých situáciach) len ťažko predstaviteľné. Ak vás zmáhajú pochybnosti ako to má celé fungovať, možno by ste mali siahnuť po knihe Agile Estimation and Planning od Mike Cohna.
Kniha je (prekvapivo) o plánovaní a odhadoch. Neobsahuje prakticky žiadne vysvetľovanie agilných metód, a preto nie je vhodná pre úplného začiatočníka. Kniha nie je len popisom postupov a artefaktov plánovania, ale je tiež značnou mierou obhajoba toho, prečo je tento postup správnejší ako tradičný. Ak teda potrebujete nazbierať argumenty v prospech agilného prístupu, v knihe určite nejaké nájdete.
Čo všetko tam vlastne môžete nájsť? Kniha je rozdelená do šiestich častí: 1. Problém a cieľ; 2. Odhad veľkosti; 3. Plánovanie pre hodnotu; 4. Sledovanie a komunikácia; 5. Prečo agilné metódy fungujú a 6. Prípadová štúdia.
Prvá časť skúma plánovanie ako také. Snaží sa identifikovať princípy a ciele plánovania všeobecne. Ďalej postupne vysvetľuje filozofiu agilného plánovania, porovnáva ho s klasickým plánovaním a poukazuje na rozdiely. Ako napríklad vyzerá dobrý plán? Je to plán, na základe ktorého môže zákazník robiť svoje vlastné rozhodnutia. To v preklade znamená, že robíte plán, ktorý je dostatočne presný, aby sa zákazník napríklad vedel rozhodnúť, kedy začať marketingovú kampaň, ale zároveň v sebe obsahuje dostatok priestoru na prispôsobovanie zmenám v budúcnosti.
Druhá časť sa plne venuje procesu odhadovania. Snaží sa objasniť, čo je to story point a prečo je lepší ako reálny človekodeň alebo ideálny človekodeň. Nájdete v nej tiež rôzne techniky na odhadovanie.
Tretia časť sa už zaoberá praktickým postupom plánovania agilného projektu. Ako zostaviť backlog (a čo to vôbec backlog je), ako naplánovať release a ako iteráciu. Prioritizácia backlogu je téma sama o sebe a je jej venované niekoľko kapitol. Prioritizovať sa dá na základe rizika a hodnoty, alebo na základe ROI či Kanov-ho modelu. Táto kniha je jednou z mála, v ktorej nájdete agilné metódy a seriózne tabuľky s prepočtom investovanej a navrátenej hodnoty. Autor sa tiež venuje téme dobrých User Story, ale o nich už existuje samostatná kniha, ktorá ich rozoberá dopodrobna (moju recenziu na ňu môžete nájsť tu: http://agile.sk/?p=568). V knihe sa dá nájsť aj kapitola o zahrnutí neistoty (teda vytvorenia buffera) pre plán alebo plánovania pre viactímový projekt.
V štvrtej časti nasleduje pasáž o vizualizácii a komunikácii plánov a to hlavne smerom k zákazníkovi. Mike ukazuje rôzne typy grafov pre zobrazovanie aktuálneho stavu releasu a iterácie a vysvetľuje, ako s nimi pracovať a ako odkomunikovať taký parameter, ako je rýchlosť (velocity) tímu.
Piata časť je pomerne krátka a obsahuje v skratke argumenty, prečo agilné plánovanie funguje a šiesta záverečná časť obsahuje prípadovú štúdiu plánovania vývoja softvérového projektu – počítačovej hry. Posledná kapitola je obzvlášť dobrá, ak si všetku tú teóriu z predchádzajúcich kapitol neviete predstaviť v praxi.
Kniha Agile Estimation and Planning podáva vysvetlenia v oblasti, ktorá je pre projekt jedna z kľúčových. Ak už máte predstavu o agilných metódach alebo ich už nejakým spôsobom používate, ale to plánovanie sa akosi stále deje po starom, pretože ten nový spôsob pôsobí príliš exoticky, môže byť táto kniha dobrý sprievodcom ako ďalej. Každopádne to, že sa na približne 300 stranách venuje len tejto téme, je dostatočný priestor na to, aby bola rozpytvaná pre potreby ľubovoľne odborného publika.
Majster v každom z tímu
Agilné metódy ponúkaju veľa možností ako zrealizovať riadenie tímu a vedenie projektu. Z tejto množiny rôznych ceremónií, artefaktov, postupov a praktík je možné si zvoliť a nasmerovať tak ďalší rozvoj Scrumu v projekte alebo celej firme. Jedna z takýchto praktík je aj rotácia scrummástera. Teda keď je každý sprint (alebo iné obdobie) majstrom scrumu.
Túto praktiku sme asi pred dvoma rokmi zaviedli v našej firme (v tíme s približne 8 ľudmi) a po týchto dvoch rokoch môžem povedať, že to bola jedna z najlepších zmien. Najprv je ale potrebné si vysvetliť, čo to presne (aspoň v našom prípade) znamená. Tím bežal už niekoľko rokov pod vedením vedúceho tímu. Ten zabezpečoval riešenie všetkých problémov, technologický dohľad, aj samotnú realizáciu sprintu. To posledné znamenalo zvolávať a moderovať porady, pripravovať backlog, riešiť akékoľvek problémy, ktoré súviseli s prácou ľudí v rámci Scrumu. Práve činnosti z tejto kategórie sa ukázali ako vhodné na oddelenie a ich realizácia prešla na samotný tím. Namiesto toho, aby sme však zvolili jedného (toho správneho?) scrummastera, nechali sme ľudí v tíme v tejto pozícii sa striedať. Krok to určite nie je jednoduchý a vyžadol určitú dávku odvahy a podpory vedenia. Odmenov bolo, že to prinieslo ešte viac bonusov ako sa pôvodne očakávalo.
Samotná rotácia prebieha tak, že každý sprint je scrummasterom niekto iný z tímu. Nerobí sa žiadny rozdiel medzi úlohou človeka v tíme, preto tester je rovnako dobrý ako programátor a naopak. Úlohou scrummastera je zvolávať porady (denná, plánovacia, retrospektíva) a moderovať ich (t.j. držať vecnú diskusiu a sledovať čas). Okrem toho, pripravuje tabuľu s úlohami pre sprint a ešte niekoľko drobností, ktoré súvisia so sprintom. A to je vlastne všetko. Je to v podstate rovnejší medzi rovnými. Takto to už funguje 2 roky a prinieslo to niekoľko výhod:
- Väčšia zodpovednosť tímu – tým ,že ľudia majú viac pravomoci a riadia si svoju prácu sami, cítia za ňu väčšiu zodpovednosť. Takéto zapojenie do práce je veľmi cenné.
- Objavenie prirodzených lídrov – robiť scrummastera nie každému úplne sadne, ale zvládnu to všetci. Veľmi rýchlo sa však ukázalo, kto sa v tej úlohe cíti ako ryba vo vode.
- Ľahšie fungovanie tímu – chvíľkový pobyt na pozícii človeka, ktorý ma na starosti hladký priebeh sprintu každému dovolí pochopiť, čo scrummaster potrebuje od ľudí z tímu. Prestali sa objavovať prípady zabudnutia aktualizácie tabuľke, keď každý zistil, ako ťažko sa kreslí graf, ak nemáte aktuálne údaje.
- Nové prvky (impluzy) do fungovania tímu – iný scrummaster, iný človek. Rôzni ľudia sú postupne stavaní do pozície človeka, ktorý sa pasuje s (niekedy opakujúcimi sa) chybami. To prinieslo nové nápady a riešenia, ktoré by inak asi ostali skryté.
- Lepšie pochopenie Scrumu – lepšie raz vidieť ako 100x počuť a lepšie raz zažiť ako 100x vidieť. Každý sa na chvíľu dostane do kože scrummastera a otestuje si problémy, s ktorými sa pasuje. To viedlo k lepšiemu pochopeniu toho, prečo sa na dennej porade stojí a ako vlastne funguje burn down chart.
- Sprinty získali svoj charakter – určité prvky v sprinte si scrummaster môže prispôsobovať podľa seba. Každý sprint tak získava osobitný charakter toho, kto ho vedie. To narúša stereotyp a robí prácu zábavnejšiu.
Rotáciu scrummastera v našom tíme hodnotím jednoznačne ako pozitívnu vec a spätné preklopenie na pôvodný spôsob je v súčastnosti nepravdepodobné. Samozrejme to nie je len tak. Chce to trochu riskovať, chce to správnu firemnú kultúru a chce to aj prípravu – s úplne novým tímom ľudí to spraviť nemôžete (alebo áno?). Každopádne sa takto do tímu prenáša časť zodpovednosti a moci rozhodovať a to môže byť najväčší problém. Pre niekoho, kto je zvyknutý držať opraty riadenia pevne v rukách je predstava, že sa toho vzdá a dokonca, že to budú postupne robiť všetci ľudia v tíme, asi nereálna. Ale to už je len opäť o tom, že je potrebné sa vyrovnať s určitým pocitom neistoty v budúcnosti. Je to rovnaké, ako keď projekt nemá nakreslený gantov diagram s presným popisom na polrok dopredu. Namiesto toho má release plán, ktorý odpovedá na otázky nie presne, ale v intervaloch. Tieto veci sprevádza ten istý pocit neistoty ako pri rotácii scrummastera. Je to niečo, na čo je ťažké ale nevyhnuté si pri agilných metódach zvyknúť. Vieru v to, že všetko sa dá riadiť a určiť dopredu, môže ľahko zbúrať zajtrajšie ráno.
Agile ako bojové umenie
Zoznam kníh o agilných metódach sa rozrastá každým rokom a je už naozaj z čoho vyberať. Môžete si pozrieť knihy pre začiatočníkov, knihy pre pokročilých. Knihy o Scrum-e, knihy o extrémnom programovaní alebo knihy všeobecne o agilných metódach. Knihy s filozofiou, knihy s praktikami atď. Aby to bremeno voľby bolo o čosi ľahšie, pozrieme sa dnes bližšie na knihu The Agile Samurai od Jonathana Rasmusson-a.
Kniha pojednáva o agilných metódach všeobecne. Hneď na začiatku autor uvádza, že bude striedať slovníky zo Scrum-u a Extrémneho programovania a naozaj to robí. Obsah knihy je podľa mňa určený hlavne začiatočníkom. Hovorím to preto, lebo hneď prvé kapitoly vysvetľujú základné princípy agilných metód. Po pochopení základných myšlienok, ktoré sa za agile skrývajú, autor postupne podrobne rozoberá jednotlivé témy ako plánovanie, zostavenie a fungovanie agilného tímu a nakoniec rôzne praktiky ako Unit Testing, Refactoring a pod. Kniha je teda takým základným sprievodcom, ktorý vysvetľuje, na čo sú agilné metódy dobré, ale aj ako ich uviesť do reálneho života. V tomto smere nie je kniha jediná, pretože kníh s podobným obsahom je niekoľko. Poďme sa teda pozrieť, čím je od ostatných odlišná.
V prvom rade je v knihe veľa obrázkov a humoru. Autor hneď na začiatku hovorí, že to bude brať s humorom a naozaj aj tak robí. Obrázky sú podľa mňa zvolené celkom dobre a sú (lepšie slovné spojenie ma nenapadá) ľahko stráviteľné. Častokrát autor zopakuje v obrázku myšlienku, ktorú pred chvíľou rozobral v texte. To robí tú knihu priam ideálnu pre ľudí, ktorí nemajú čas alebo ochotu čítať. Stačí, ak by si prelistovali niekoľko strán, pozreli si obrázky a mali by mať základnú predstavu o čom agilné metódy sú.
Ďalšia zaujímavá praktika je takzvaný Inception Deck. Je to sada krokov, ktoré treba vykonať na úvod projektu, aby mali všetci jasné, čo sa bude robiť. Obsahuje kroky skôr do vnútra projektu ako: vytvoriť výťahový popis (popis projektu, ktorý by ste mali byť schopní povedať počas jednej jazdy vo výťahu), navrhnúť krabicu produktu, zostrojiť takzvaný NOT list (zoznam vecí, ktoré projekt určite nebude riešiť); ale aj kroky smerom von: zoznámiť sa so susedmi (so všetkými, ktorých sa projekt môže týkať), vyjasniť si so zadávateľom, čo sme schopní dodať a koľko to bude stáť a pod. Ide určite o zaujímavý postup, s ktorým som sa ja osobne v inej literatúre nestretol, a ktorú by určite stálo za to otestovať. Hlavne to vyjasnenie so zadávateľom môže projekt aj zabiť, ale o tom už agilné metódy sú: ak máme zlyhať, zlyhajme tak skoro, ako sa dá. Inception deck sa tiež dá chápať ako taký stres test v duchu: čo ťa nezabije, to ťa posilní.
V knihe sa tiež dá nájsť ešte zopár vylepšení známych praktík, ktoré mňa osobne zaujali. Jedno také vylepšenie je zmena otázok denného Scrumu. Namiesto klasického: Čo som robil včera, čo dnes a aké mám problémy, autor navrhuje odpovedať na otázky: Ako som zmenil svet včera? Ako ho plánujem zmeniť dnes? Ako sa viem dostať cez prekážky, ktoré mi stoja v ceste? Tvrdí, že takto formulované otázky môžu vyvolať úplne iné asociácie, pocity a odpovede, ako tie klasické.
Agile Samurai je kniha, ktorú by som venoval človeku, ktorý sa už dlho snaží pozrieť si niečo o agilných metódach, ale zatiaľ nenazberal dosť vôle. Vďaka obrázkom a humoru je ľahko stráviteľná, a teda môže poslúžiť svojmu účelu. Ak nie ste začiatočník a kniha sa vám dostane do ruky, nezahadzujte ju. Myslím, že aj vy ste si schopný z nej niečo odniesť. Minimálne Inception deck a zopár zaujímavých postrehov o agile. Napríklad aj myšlienku o zákazníkovi: „The agile customer is the “source of the truth” from which all requirements flow on an agile project. “
Prečo vodopád vyhráva?
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ť.
Čo majú spoločné agilné metódy a kuchynský budík?
Možno ste už mali tú príležitosť zažiť naozaj funkčný Scrum. Prechádzate sa po miestnosti, kde sedí tím a vidíte, že jeho práca je ako dobre namazaný stroj. Na burndown charte je jasne vidieť, že to ide so sprintom dole z kopca, vývojári komunikujú, zákazník spolupracuje. Proste paráda. A potom si sadnete za svoj stôl a pozriete sa na tú hromadu práce, ktorú vám treba robiť. Dokumenty, ktoré treba spripomienkovať, články, ktoré ste chceli preštudovať a dopísať ten mail, ku ktorému sa neviete prinútiť. Možno si v takú chvíľu pomyslíte, aké by to bolo super, keby ste aj pracovali tak plynulo a efektívne. Aké by to bolo super, keby existoval Scrum pre jedného človeka. No. On možno aj naozaj existuje. Hovoria mu Pomodoro Technique.
Pomodoro je technika, ktorú pravdepodobne vymyslel Francessco Cirillo a jej hlavným účelom bolo udržať vaše sústredenie na to, čo práve robíte. Už to samo o sebe je dostatočný krok vpred, ale technika bola ďalej vylepšovaná, až sa z nej stal systém na riadenie času (time-management). Pomodoro technika má mechanické srdce, ktoré udiera v intervale presne jednej sekundy. Je to totiž kuchynský budík v tvare paradajky, ktorý odmeriava váš čas, počas ktoré sa máte sústrediť. Po 25 minútach si môžete dopriať 5 minútovú prestávku (dôležité je robiť čokoľvek iné, čo nesúvisí s predtým vykonávanou prácou) a potom si dať ďalšie pomodoro. Po štyroch pomodorách máte nárok na polhodinovú prestávku. Ak počas pomodora dokončíte úlohu zo zoznamu, škrtnete ju a ďalšie pomodoro venujete ďalšej položke. Podstatné je, že počas pomodora robíte len jednu vec, pre ktorú bolo pomodoro vyhradené a vyrušenie eliminujete podľa možnosti na čo najmenšiu mieru.
Možno zatiaľ nie je jasné, čo má pomodoro s agilnými metódami. Tak poďme ďalej. Zoznam úloh, ktoré pomocou pomodora máte spracovať (tzv. Today List), si plánujete každé ráno z takzvaného Activity List, kde máte všetky potenciálne úlohy. Čokoľvek, čo vás cez deň vyruší, si zapíšete do jedného z tých zoznamov podľa toho, aké je to súrne. A teraz tá zaujímavejšia časť. Pri plánovaní zoznamu pre daný deň odhadujete koľko pomodor vám daná činnosť zaberie a zo štatistík, ktoré si evidujete, viete koľko pomodor za deň približne stihnete, takže viete čo si pre daný deň máte naplánovať. Na konci každého dňa okrem toho robíte retrospektívu o tom, ako presne sa vám podarilo úlohy odhadnúť, koľko ste toho stihli, koľko ste mali vyrušení a podobne. Ok. A teraz poďme prekladať do reči Scrumu.
Každé ráno si z backlogu vyberiem do releasu úlohy, ktoré by som mal v tento deň stihnúť. Urobím to na základe odhadu, koľko sprintov mi bude trvať vykonanie úlohy a koľko sprintov priemerne stihnem za deň. Následne spustím sériu sprintov. Počas sprintov nemením na čom pracujem. Keď sprint skončí, oddýchnem, prehodnotím, čo by som mal robiť ďalší sprint a spustím ho. Na konci releasu robím retrospektívu, aby som vyhodnotil svoju úspešnosť v odhadoch aj samotnej práci. Rozdiel medzi pomodorom a Scrumom je často krát len v použitom slovníku.
Tie metódy sú si tak podobné, že si viem predstaviť, že pomodoro je metóda, ku ktorej by sa dospelo používaním Scrumu na riadenie práce jedného človeka a jeho postupným prispôsobovaním. Z tejto podobnosti vyplývajú 2 zásadné výhody. Prvá výhoda je, že ak poznáte jednu z týchto dvoch metód, tú druhú pochopíte veľmi rýchlo. Druhá výhoda je, že rôzne techniky, postupy a vylepšenia pre jednu môžu byť aplikovateľné pre druhú.
Myšlienka o tejto podobnosti nie je tak úplne moja. Vysvetlenie pomodora s občasnými odkazmi na Scrum môžete nájsť v knihe Pomodoro Technique Illustrated od Steffana Nöteberga. Je to jedna z kníh o pomodore a podľa môjho názoru jedna z tých lepších. Ak by sa vám dostala do ruky, tak sa neľakajte obrázkov, ktoré vyzerajú, že ich kreslil žiak základnej školy (v skutočnosti to bol autor). Cieľom obrázkov je sprostredkovať ideu (jeden obrázok = jedna idea) a to sa podľa mňa darí. Autor vás postupne prevedie od dôvodov, prečo sa vôbec pomodorom zaoberať, cez jeho princípy, až po rôzne špeciálne vylepšenia a prípady použitia.
Scrum a pomodoro sú len iné obaly pre tie isté princípy. Každopádne nemusí byť pomodoro to jediné, čo sa vie vykľuť zo stretu sveta agilného riadenia a time managementu. Ak máte vlastné skúsenosti s používaním agilných metód na riadenie vlastnej práce, podeľte sa o ne…
Príbehy používateľov v praxi
Občas sa vyskytne kniha, ktorá mi nedá pokoj, kým si ju neprečítam. Jednu chvíľu o nej niekto hovorí na konferencii, potom na ňu nájdem odkaz v inej knihe alebo sa objaví v nejakom TOP rebríčku. Jednoducho si začnem hovoriť, že to všetko nemôže byť náhoda, a rozhodnem si tú knihu prečítať. Podobné to bolo aj s knihou User Story Applied od Mike Cohn-a. Keď sa mi dostala do rúk, všimol som si, že je zo série kníh „A Kent Beck Signature Book“. Hlavou mi preletelo: “Hm. Keď Kent Beck podpíše Mike Cohn-a, tak to som vážne zvedavý, čo to bude.“
User Story Applied neostáva nič dlžná svojmu názvu, pretože teóriu okolo techniky používania User Story rozoberá pomerne podrobne. Nie je to kniha pre ľudí, ktorí nepoznajú agilné metódy, pretože aj keď obsahuje dodatok popisujúci extrémne programovanie, nie je jej cieľom vysvetľovať základné princípy. Všetko sa krúti okolo User Story a práce s nimi.
Hneď v prvej časti je rozoberaná zaujímavá myšlienka. User Story nie je len tá kartička s popisom, ktorú máte zavesenú niekde na stene alebo uloženú v elektronickej podobne. Mike tvrdí, že User Story sa skladá z troch časti:
1. krátkeho popisu (to je tá už spomínaná kartička),
2. konverzácií počas vývoja,
3. akceptačných kritérií.
Čiže rozhovory medzi zákazníkom a vývojárom sú neoddeliteľnou súčasťou User Story. Čo inak znamená, že kým nie je hotová úloha, nie je hotová ani User Story – porovnajte to s klasickým postupom, kde zber požiadaviek musí byť ukončený pred ďalšími fázami vývoja. V tomto prípade kartička doslova vystupuje len ako pripomienka toho, že sa o tom ešte treba rozprávať. V prvej kapitole knihy sú ďalej rozoberané príbuzné témy ako vlastnosti správnej User Story, techniky na modelovanie User Roles, ako správne písať akceptačné testy alebo rôzne typy User proxies (nič sa nevyrovná skutočnému zákazníkovi).
Nasledujúca kapitola je o odhadoch a plánovaní. To, že sú v knihe zahrnuté aj tieto témy, je logické. Čo mi však vadilo, je rozsah tejto kapitoly, ktorý predstavuje približne tretinu knihy. Hlavne ak uvážim, že od rovnakého autora existuje kniha Agile Estimation and Planning ktorá sa tomu plne venuje (a v oboch knihách sú prezentované rovnaké princípy). Kapitola obsahuje rôzne postupy a techniky na odhadovanie User Story v Story points, a tiež návody ako plánovať release a iteráciu.
Po odbočke k plánovaniu sa v poslednej kapitole vracia Mike späť k samotným User Story a preberá rôzne špecifické témy ako: „smrad“ zlej User Story, prečo User Story nie je Use Case a v čom je rozdiel alebo ako sa pri plánovaní vysporiadať s nefunkcionálnymi požiadavkami a chybami. Zaujímavé je, že User Story môže pokaziť aj vývojár. Napríklad takým zlatokovaním – Goldplating (zlatokovanie je, ak vývojár svojvoľne pridáva rôzne super cool vylepšenia, ktoré ale zákazník nikdy nechcel – viac: wikipedia ). To len potvrdzuje to, že User Story je v tejto knihe chápaná nie len ako dokumentácia, ale aj ako časť procesu vývoja. V zostávajúcej časti kapitoly sa Mike ešte dotkne obľúbenej dilemy: je lepší softvér alebo papier (jedna z otázok, na ktorú asi nikdy nebude existovať jednoduchá odpoveď) a v jej úplnom závere sa dá nájsť 40 stranový príklad vytvorenia User Roles, User Stories a naplánovania Releas-u.
Na otázku, či sa oplatí túto knihu čítať, by som odpovedal protiotázkou: „Je váš zákazník spoluhráč, alebo protihráč?“. Ak váš zákazník patrí do skupiny, s ktorým sa ťažko spolupracuje, mohlo by sa stať, že keď sa po prečítaní tejto knihy pozriete do backlogu, tak zistíte, že veľa z tých požiadaviek vlastne nie sú User Story. Prípadne po prečítaní kapitoly o „smradoch“ zistíte, že tie vaše majú vážne pachové nedostatky. V takom prípade čítanie knihy môže byť frustrujúce. Ak však máte zákazníka, ktorý na túto hru pristúpil, potom si túto knihu kúpte alebo požičajte a prečítajte. Ak už máte používať User Story, je dobré im rozumieť.