Alexej Krivitsky, agile kouč a organizátor známej konferencie Agile Eastern Europe, už dlho učí Scrum pomocou hry LEGO.
Pomocou tejto hry je možné veľmi názorne a prakticky pochopiť ako má agilný tím fungovať, ako plánovať produkt a ako sledovať priebeh pomocou Scrum.
Keďže túto hru hrajem aj ja pri našich agilných tréningoch, Alexej ma poprosil o preklad do slovenčiny. Ďakujem Tiborovi Radačovskému za pripomienky.
„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.
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. “
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…
Daniel H. Pink – Drive, The Surprising Truth About What Motivates Us
Už dlhšiu dobu sa zaoberám otázkou, ktorá by sa dala v krátkosti zhrnúť do vety “Ako správne motivovať agílny tím ?”. Dosť dlho som hľadal odpoveď hlavne na finančnú stránku motivovania ‘dospelého ‘ tímu, myslím bonusy a iné finančné nástroje. Naposledy som sa ju pokúšal hľadať medzi účastníkmi konferencie ALE2011 v Berlíne, kde som od viacerých ľudí počul ako odpoveď : “Dan Pink – Drive“. Konečne som sa k tej knihe dostal a tu sú moje postrehy bezprostredne po dočítaní.
Pre tých, čo by hľadali odpoveď na otázku okolo používania finančných nástrojov vopred avizujem, že Dan Pink má v tom jasno : Plať toľko aby otázka peňazí nebola na stole.
Ale aj tak je kniha skvelá.
Kniha samotná sa skaldá z troch častí. Jej nosnou myšlienkou je rozdiel medzi tým, čo veda pozná a business prostredie robí.
1. Nový operačný systém
Úvodná časť začína opisom rôznych experimentov (už z rokov 1949 a 1960 ), ktorých účel bol detekovať účinok vonkajšej motivácie na sledovaných jedincov. Ako inak s prekvapivým výsledkom.
Pink veľmi zaujímavo opisuje sociálne prostredie ako operačný systém, v ktorom právo a ekonomika je akoby interface vrstvou nad sadou protokolov, inštrukcií a predpokladov toho, ako svet funguje. A ako každý operačný systém, aj ten náš má verzie, v čase sa, ako všetci veríme, vylepšujúce. Vrátane problémov so inkompatibilitou. Náš názor na to, ako veci fungujú potrebuje čas od času upgrade. A ten čas je tu.
Veľmi podnetnou kapitolou je Sedem dôvodov, prečo cukor a bič nefunguje. Jednoduchá motivačná metóda vychádzajúca z predpokladu že je potrebné odmeňovať správne chovanie a trestať nesprávne v mnohých prípadoch vedie k tomu, že vo výsledku často dostávame menej toho čo chceme, viac toho čo nechceme a ako bonus neetické chovanie a potlačenú kreativitu. Zároveň ale vysvetľuje, kedy takáto priamočiara motivácia (ak-potom) môže prinášať výsledky.
V závere prvej časti autor definuje dva typy správania: a)Typ X – správanie podmienené hlavne vonkajšími faktormi a odmenami ku ktorým vedie aktivita. Oproti tomu b) Typ I – správanie reagujúce viac na vnútorné uspokojenie z aktivity samotnej. A áno, b) je správne. Pozitívny záver je, že Typom I sa nerodíme, ale sa ním stávame.
2. Tri elementy
V druhej, kľúčovej časti knihy sú rozobraté 3 hlavné motivátory. Autonómia, Majstrovstvo a Účel.
Autonómia riadiť si veci po svojom, zdokonaľovanie a snaha byť v niečom naozaj dobrý a v neposlednom rade robiť niečo čo má (vyšší/širší) zmysel je pre väčšinu ľudí viac ako tie veci, za ktoré si “štestí nekoupíš”.
3. Toolkit pre subjekty Typu I
Tretia časť knihy, predstavuje návod pre jednotlivcov, rodičov ale aj organizácie ako prebudiť vlastnú motiváciu a ako motivovať iných. Nie je to teória, je to konkrétny zoznam užitočných praktík. Za všetky mňa zaujali – predtým kým pôjdete spať si položte otázku : Bol som dnes (v čomkoľvek) aspoň o trochu lepší ako včera ? , alebo – zostavte a udržujte zoznam vecí, činností, ktoré NEbudete robiť.
Pre organizácie sa vyzdvihuje potreba vyčleniť čas na aktivity ‘mimo oficiálny plán’.
Kniha v závere obsahuje veľmi užitočný abstract, takže pre tých, čo sa im nechce čítať, alebo si len chcú pripomenúť dôležité myšlienky, stačí prečítať tých 6 strán. Ale pre serióznych záujemcov o myšlienky z tejto knihy, ktorí si ťažko nájdu čas na prečítanie radšej odporúčam pozrieť toto krátke video
http://www.youtube.com/watch?v=u6XAPnuFjJc (10min).
K dispozícii už je aj slovenský preklad “Čo nás poháňa, Prekvapivá pravda o tom čo nás motivuje a ženie vpred”
alebo český preklad s názvom “Pohon”
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ť.
Jedna z vecí, ktorú som sa naučil o tom, ako sa vysvetľujú agilné metódy (alebo v podstate čokoľvek, čo je netradičné) je, že niet nad dobrú metaforu. Moja obľúbená hovorí o tom, že vývoj softvéru je ako krájanie torty. Raz za čas (zväčša na konci iterácie) chcete dať zákaznikovi ochutnať to, čo pečiete. Tak ako torta je najlepšia, keď sa reže vertikálne (pretože obsahuje všetky tie rôzne, chutné vrstvy) tak ten prírastok kódu v tejto iterácii by mal byť vo všetkých vrstvách aplikácie (od databázy až po zobrazovaciu vrstvu). Skončiť iteráciu s tým, že máme hotovú kompletnú databázu, ktorú ale zákazník nevie oceniť, je ako odrezať niekomu kruh piškótového cesta zospodu torty. Kniha The Art of Agile Development od Jamesa Shora a Shane Wardena obsahuje okrem iných drahokamov aj množstvo podobných metafór.
The Art of Agile Development je príručka extrémneho programovania. Je dobrá pre úplných začiatočníkov aj pokročilých agilistov. Hneď prvá časť je určená tej prvej skupine. Vysvetľuje základné myšlienky, ktoré sa skrývajú za praktikami extrémného programovania. Rozoberá roly, ktoré v takom tíme sú a nechýba kapitola s informáciami ako to celé začať. Tí pokročilejší tam môžu nájsť tabuľku porovnania praktík, ktoré odporúčajú autori v extrémnom programovaní voči praktikám z prvého a druhého vydania Extreme Programming Explained od Kenta Becka a Scrumu.
Najpodstatnejšia z knihy je druhá časť. Tá obsahuje zoznam 37 praktík rozdelených do 5 oblastí. Praktiky sa rôznia od vyslovene technických, ako napríklad Pair Programming, Iteration Demo, Ten-minutes Build až po pomerne filozofické ako Trust (dôvera medzi členmi tímu alebo tímom a zákazníkom), Energized Work (t.j. prečo nerobiť nadčasy) alebo Slack. Každá praktika je podrobne rozobraná (kniha má 400 strán) a obsahuje časti:
Okrem toho sú medzi praktikami krížové odkazy, ktoré hovoria o tom, ktoré postupy je dobré používať spolu (a získať tak synergický efekt). Každá z piatich oblastí, v ktorých sú praktiky rozdelené, obsahuje tiež jedno cvičenie na prehĺbenie pochopenia myšlienky, ktorá sa za ňou skrýva.
Pre tých, ktorým sú známe praktiky a ktorí hľadajú niečo viac, je určená posledná časť. Autori sa v nej snažia ukázať ako rozvíjať agilné praktiky ďalej (často krát ide už o ladenie detailov vo vzťahu projekt – metóda riadenia). Zaoberajú sa hlavnými myšlienkami extrémneho programovania a snažia sa ukázať možné smery, ktorými sa dá ísť ďalej. Tretia časť obsahuje kapitoly ako Values and Principles, Improve the Process, Rely on People, Eliminate Waste, Deliver Value a Seek Technical Excellence.
Kniha je celkom dobre postavená a napísaná. Postupne začína základnými myšlienkami, vysvetľuje praktiky až finišuje otvoreným koncom o smerovaní ďalšieho vývoja. Veľmi ťažko v nej budete hľadať hranice medzi technickými praktikami vývoja a praktikami riadenia tímu, čo je ale pre extrémne programovanie príznačné. Nedá mi ale nevytknúť jednu vec. Autori de-facto ignorujú testerov. Hovoria hlavne o programátoroch a analytikoch a len sem-tam utrúsia poznámku typu: „K tomuto môže prizvať aj testerov.“ Osobne sa s týmto neviem stotožniť, pretože považujem testerskú prácu za rovnako dôležitú a komplikovanú ako prácu vývojárov (hlavne ak sa začne brať do úvahy automatizované testovanie).
A kde sú metafory, ktoré som spomínal na začiatku? Sú rozhodené po celej knihe, ale najviac je ich v druhej časti. V tomto smere považujem túto knihu za najlepšiu, akú som kedy mal v rukách. Na záver jedna za všetky: Predstavte si balvan na vrchu kopca. Ako tak stojí na tom kopci, ma sám o sebe potenciál hýbať sa, ale potrebuje malé postrčenie, aby sa rozbehol, aby sa tá energia uvoľnila. Tvar krajiny sa ale časom mení a to čo je dnes kopec môže byť po čase rovina a tak váhanie môže spôsobiť, že balvan stratí svoj potenciál. Balvan = hotový softvér, postrčenie = zverejnenie (release).
Agilný tím by mal byť multiprofesný. Okrem architektov a staviteľov, ktorí ťažko pracujú a budujú produkt, by mal obsahovať niekoho, kto povie, že sa program dá používať. Niekoho, kto sa pozrie na celú vec z inej perspektívy a nájde chyby, ktoré možno z tej pôvodnej nebolo vidno. Niekoho, kto stojí na polceste medzi programátormi a zákazníkmi, a tak sa vie najlepšie dorozumieť s obidvoma skupinami. Tušíte správne, že ten niekto je tester. Aspoň tak ho vidia Lisa Crispin a Janet Gregory v ich knihe Agile Testing.
Hneď na začiatku treba povedať, že kniha by sa dala rozdeliť na dve časti. Jedna sa týka vysvetľovania agilných metód ako takých. Rozoberané sú jednotlivé praktiky aj dôvody prečo ich používať. Tá druhá má za cieľ ukázať ako v prostredí týchto metód testovať. Teda zaoberá sa už len priamo testovaním. Dobrá správa je, že kniha má dosť strán (533), a teda obe polovice dostali dosť priestoru. Zlá je, že sa tieto dve časti knihou postupne preplietajú, a tak si neviete prečítať jednu alebo druhú podľa toho, čo vás zaujíma.
Autorky vidia testera ako veľmi dôležitú časť tímu. Hneď v prvých kapitolách, kde vysvetľujú agilné metódy, sa snažia presvedčiť, že tester môže byť iniciátorom aj katalyzátorom zmeny riadenia na agilné. S veľkou časťou týchto myšlienok som sa už stretol vo forme pre programátorov, to ale netratí na ich cene v tejto knihe. Nechýbajú klasické témy ako: metriky, spôsob zaznamenávania chýb, plánovanie a spolupráca s požadovanými štandardmi.
Druhá časť knihy je venovaná takzvaným štyrom kvadrantom testovania. Tieto kvadranty sú vytvorené kombináciou možnosti, či ide o testy na podporu tímu (t.j. zvýšenie kvality produktu) alebo kritiku produktu (t.j. vylepšenia používania) s možnosťami, či ide o technické testy (testy stability, škálovateľnosti atď.) alebo skôr obchodné testy (testy procesov, používania). Dá sa povedať, že všetka práca testera v agilnom tíme spadá do niektorých z týchto kvadrantov. Pre každý kvadrant Lisa a Janet uvádzajú zoznam postupov a nástrojov, ktoré môžu byť pre neho použité. Priznám sa, že silu tejto myšlienky som pochopil až na druhé čítanie, ale o to silnejšia mi pripadá. Zatiaľ v žiadnej knihe som nevidel tak jasne a rozumne rozdelenú prácu testera s pomerne kvalitným popisom. Dokonca každý kvadrant obsahuje kapitolu o tom, čo môže tester robiť, ak tím testy v danom kvadrante vôbec nepoužíva.
Ďalšia pomerne veľká časť je venovaná automatizácii. Obsahuje štandardné zoznamy dôvodov, prečo automatizovať testovanie, zoznamy nástrojov, ktoré sa dajú použiť ako aj menej časté témy ako napríklad, čo sa automatizovať neoplatí alebo ako naštartovať automatizáciu už v bežiacom projekte. Odkaz autoriek v tejto časti je jasný: „Čo sa dá, to automatizujte.“
Posledná časť knihy by sa dala označiť ako „sprievodca testera v agilnom tíme“. Postupne sú rozoberané jednotlivé fázy od plánovania releasu/sprintu, cez samotný beh iterácie až po nasadenie. Autorky sa snažia vysvetliť, čo je hlavnou zodpovednosťou testera a o čo sa má snažiť. To snaženie nie je len tak, pretože na niekoľkých miestach v knihe som sa dočítal radu, že ak vás ako testera nezavolajú napríklad na plánovacie stretnutie, tak sa tam proste dostavte a všetkým vysvetlite, že tam musíte byť.
Ako som už spomenul skôr, pozícia testera je brána s plnou vážnosťou ako seriózna inžinierska rola v tíme. Celou knihou sa preplieta myšlienka, že tester je ten najlepší komunikátor medzi zákazníkom (alebo doménovým expertom) a programátorom. Hovoria tomu „sila troch“ a tvrdia, že ak sa má riešiť nejaký problém, tak len vždy v takejto trojici. Osobne s takýmto striktným prístupom nemám skúsenosti ale v mnohých bodoch, na ktoré je v knihe poukázané, sa s Lisou a Janet zhodneme. Každopádne kníh, ktoré by sa venovali priamo agilnému testovaniu nie je až tak veľa, aby Agile Testing nestálo za prelistovanie.
Ak zvyknete brať do rúk knihy o riadení zmien vo firme, skôr alebo neskôr pravdepodobne narazíte na meno John P. Kotter. Kotter je človek, ktorého niektorí označujú za guru v riadení zmien. Je autorom niekoľkých kníh, z ktorých najznámejšie sú Vedenie procesu zmeny a Náš ľadovec sa potápa. Teória úspešnej zmeny, ktorú John prezentuje, hovorí, že táto zmena by mala prebiehať v ôsmich krokoch:
1. Vyvolanie pocitu naliehavosti
2. Vytvorenie angažovaného riadiaceho tímu
3. Vytvorenie vízie a stratégie
4. Komunikovanie zmien smerom k ľudom
5. Posilňovať tých, ktorí podporujú zmenu
6. Získavať krátkodobé víťazstvá
7. Udržiavať vytrvalosť
8. Zaisťovať pevnosť zmien
Práve prvému bodu z tohto zoznamu sa venuje kniha „Pocit naliehavosti“, a možno je to práve tento pocit, čo niekedy chýba pre úspešné zavedenie agilných metód.
Naliehavosť v autorovom chápaní znamená zanietenosť a odhodlanie pre zmenu. Je to tiež synonymum pre uvedomenie si, že zmena je opodstatnená. Že súčasný stav nie je dostačujúci. To, čo pocit naliehavosti zabíja, je sebauspokojenie. To je naopak pocit, že všetko je v poriadku a nič meniť netreba (hoci realita si zmenu vyžaduje – predsa len pocity neformujú realitu). Sebauspokojenie prichádza často po úspechu a je to to, čoho sa treba vyvarovať. Ďalším nepriateľom naliehavosti je klamná naliehavosť. Pod tým sa predstavuje generovanie činnosti, ktorá navonok vyzerá ako aktuálne potrebná, ale v skutočnosti neprináša žiaden osoh (napr. hasenie požiarov, ktoré možno ani tak veľmi požiarmi nie sú).
Jedným zo zaujímavých princípov, o ktorých John píše, sú červené vlajočky. Ak ste absolvovali poradu, na ktorej sa nič nedohodlo, len sa zabil čas a riešenie sa posunulo na nejaký nejasný termín, mali ste možnosť vidieť červenú vlajočku. Alebo ak vidíte, že predaj vašej firmy stagnuje (treba povedať, že kniha je písaná hlavne pre obchodné firmy) oproti iným firmám na trhu, práve sa pozeráte na červenú vlajočku.
V prvých kapitolách knihy sa venuje hlavne vysvetľovaniu pojmov ako je naliehavosť, sebauspokojenie a klamná naliehavosť. V tých ďalších (ktoré tvoria hlavnú časť knihy) už predstavuje konkrétne postupy ako naliehavosť vo firme vyvolať. Jedna z týchto stratégii je napríklad „Priniesť vonkajšie dovnútra“. Toto je ideálne pre firmu, ktorá v prevažnom čase rieši vnútorné problémy a nevšíma si, čo sa deje so zvyškom trhu. Dá sa to predstaviť ako vyvesenie porovnania grafov predaja našej a konkurenčnej firmy vo vstupnej hale spoločnosti, kde to bude všetkým na očiach. Alebo iniciovanie návštev konferencií z danej oblasti. Cieľom je priniesť čo najviac informácií zvonku do vnútra a prebudiť tak ľudí – vyvolať v nich pocit naliehavosti. V závere knihy sa autor venuje hlavne taktikám na udržanie tohto pocitu a jeho ďalšiemu využitiu. Keďže je to prvý z krokov pre úspešnú zmenu, predstavuje jeden zo základných kameňov úspešnej zmeny.
Myslím, že nie je náhoda, že bol to práve prvý krok, ktorý si John vybral a rozhodol sa mu venovať celú knihu. Nič nedokáže tak napomôcť zmene ako angažovanosť ľudí (a nič ju tak nevie brzdiť ako neochota). Angažovanosť sa dá vyvolať rôznymi spôsobmi (napríklad zosilnením motivačných stimulov – zvýšenie platu), a aj preto by som na možnosť vyvolať pocit naliehavosti pozeral ako na ďalší nástroj do zbierky, ktorý sa dá použiť, ak zlyhajú (alebo sú pridrahé) všetky ostatné.
V rámci agilných metód sa často odporúča pracovať v iteráciách. Tie totiž okrem iného umožňujú vykonávať v pravidelných intervaloch reflexiu voči stavu projektu. Jednou z takýchto reflexií je retrospektíva (inou je napríklad demo produktu). Kvalitnej retrospektíve môže stáť v ceste niekoľko prekážok. Napríklad vnútorné rozpory v tíme, nízka angažovanosť ľudí ohľadom ich práce, strach z vystupovania pred skupinou, ale aj obyčajná zábudlivosť. Práve vďaka týmto problémom je retrospektíva typ porady, ktorý si zasluhuje pozornosť a prípravu. Niekoľko veľmi dobrých tipov ako na to ponúka kniha Agile Retrospectives od autoriek Esther Derby a Diany Larsen.
Kniha začína všeobecnými radami ako viesť retrospektívu. Zaoberá sa krokmi ako vyjasnenie si cieľa, štruktúry a dĺžky retrospektívy. Ponúka postupy ako vyriešiť problémy s niektorými nežiadúcimi prejavmi ako je krik, nevhodný smiech a vystupovanie alebo aj neobvyklé ticho.
Hlavná časť knihy prestavuje katalóg rôznych aktivít, ktoré sú vhodné pre retrospektívu. Sú rozdelené do piatich oblastí totožných s piatimi fázami retrospektívy:
1. Set the Stage – aktivity na zahriatie a prebranie ľudí
2. Gather Data – získanie údajov ohľadom fungovania tímu a jeho problémov
3. Generate Insights – premena údajov na informácie; snaha nájsť podstatu problému
4. Decide what to do – rozhodnutie o ďalších krokoch v rámci riešenia problémov
5. Close retrospective – uzatváracia aktivita
Ku každej z týchto fáz retrospektívy ponúkajú autorky niekoľko rôznych aktivít, z ktorých je potrebné vybrať jednu pre vašu retrospektívu. Každá aktivita je popísaná v rovnakej štruktúre: účel, potrebný čas, popis, kroky, potrebná príprava a príklad na záver. Dokopy sa v tomto katalógu nachádza 30 rôznych aktivít, čo ja osobne považujem za dostatočnú zásobu na niekoľko mesiacov alebo rokov (podľa toho ako často retrospektívu vykonávate).
Tretia, posledná, časť knihy sa venuje rôznym druhom retrospektív. Okrem klasických iteračných retrospektív je tu priestor venovaný aj release a projektovým retrospektívam alebo spoločným retrospektívam pre viaceré oddelenia firmy. Autorky sa zaoberajú rozdielmi, ktorými sa líšia tieto väčšie retrospektívy od klasickej iteračnej.
Osobne by mi nevadilo, keby bola kniha Agile Retrospectives hrubšia a niektoré témy prebrala viac do hĺbky. Na druhej strane je nutné povedať, že kníh ktoré sa priamo venujú retrospektívam, nie je veľa, a preto som autorkám vďačný za to, že do tejto oblasti priniesli aspoň aké – také svetlo. Štruktúra, ktorú vo svojej knihe navrhujú, mi pripadá rozumná a prirodzená pre riešenie problémov. Z mojich skúsenosti viem, že často dochádza k chybe, že v reálnom živote často táto schéma nie je dotiahnutá do konca. Ak ste už niekedy zažili poradu, kde sa síce povedalo, v čom je problém, ale akosi sa zabudlo dohodnúť na tom, čo sa s tým bude robiť a kto to má na starosti, tak viete o čom hovorím (veľmi dôležitá štvrtá fáza „Decide what to do“). Ak vás stretávajú takéto alebo iné nepríjemné pocity v rámci vašich retrospektív, myslím, že je na čase prelistovať knihu Agile Retrospectives.