Author Archives: Peter Špireng

Extrémne dobrý v extrémnom programovaní

Posted on by

the.agile.developmentJedna 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:

  • Prečo to vôbec robiť?
  • Ako to robiť?
  • Podrobný popis
  • Často kladené otázky ohľadom tejto praktiky
  • Možné problémy
  • Alternatívy k praktike
  • Zhrnutie
  • Zoznam literatúry na ďalšie štúdium

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é testovanie? Prečo nie.

Posted on by

agile.testingAgilný 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.

Úspech zabíja naliehavosť

Posted on by

sense.of.urgencyAk 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é.

Vyvolanie pocitu naliehavosti

Vytvorenie angažovaného riadiaceho tímu

Vytvorenie vízie a stratégie

Komunikovanie zmien smerom k ľudom

Posilňovať tých, ktorí podporujú zmenu

Získavať krátkodobé víťazstvá

Udržiavať vytrvalosť

Zaisťovať pevnosť zmien

Čo sa mení, nie je konštantné, alebo prečo to bez automatizácie nejde

Posted on by

Jednu z vecí o riadení, ktorú som sa naučil je, že pri dlhotrvajúcich projektoch je dôležité rozlišovať konštantné a meniace sa veličiny. Pod veličinami môžeme rozumieť akékoľvek počty alebo čísla, ktoré súvisia s projektom. Napríklad počet riadkov zdrojového kódu, počet ľudí v tíme, množstvo úloh v sprinte, počet dní/hodín/minút, počas ktorých trvá, kým sa zistí, že do zdrojového kódu bola omylom pridaná chyba alebo počet minút, ktoré trvá denná porada. Konštantná veličina je taká, ktorá sa časom nemení. Príkladom môže byť už spomínaný počet minút rannej porady. Táto veličina je väčšinou závislá od počtu ľudí v tíme a disciplíny ľudí, ktorí sa jej zúčastňujú, pričom väčšinou ide o interval (napríklad 5 až 10 minút). Dá sa povedať, že táto hodnota je konštantná (aspoň v prípade nášho tímu). Konštantné veličiny sú fajn. Fajn preto, že ak nájdete dobré riešenie, ktoré s nimi súvisí, tak sa o to už ďalej nemusíte starať. Čo sa týka denných porád, tak sme sa dohodli, že na porade budeme stáť, že každý povie to na čom pracuje, pracovať bude a či má nejaký problém, a že nebudeme zachádzať do detailov. To viedlo k tomu, že sa naše porady zmestili do 10 minút.

To, čo je v projekte nebezpečné, sú meniace sa veličiny. Hlavne tie rastúce. Z môjho pohľadu sa ako najnebezpečnejšia javí množstvo funkcionality v aplikácii. To je samozrejme žiadúci efekt. Problém je, že to má za následok rast množstva kódu (čo zase vedie k predĺženiu času automatického zostavenia, automatických testov, atď.), množstva času stráveného regresnými testami, množstva dokumentácie a pod. Hlavným problémom rastúcich veličín je, že súčasné riešenie nemusí byť v budúcnosti dostatočné. Dobrým príkladom, kedy rastúca veličina prevalcuje konštantné riešenie, je použitie agilných metód a manuálneho testovania.

Prvou z dvoch dôležitých požiadaviek, ktoré sú kladené na náš tím je, že umožňujeme zmenu priorít v backlogu (čo znamená, že máme len krátkodobé – sprintové – plánovanie, a teda v ďalšom sprinte môžu prísť ľubovoľné úlohy, a teda aj zmeny v kóde). Tou druhou je, že musíme byť schopní často zverejňovať nové verzie aplikácie s určitou konštantnou mierou rizika (inak povedané s čo najmenším počtom chýb). Tieto požiadavky viedli k tomu, že sme často nútení vykonávať regresné testy nad celou alebo veľkou časťou aplikácie. Takže na jednej strane máme rastúce množstvo funkcionality, ktoré spolu s požiadavkou na konštantnú úroveň rizika chyby v produkčnej prevádzke vedie k nárastu regresných testov. Na druhej strane je tu ale jedno obmedzenie a to je cena testovania. Keďže počet programátorov sa nemení, konštantný by mal ostať aj počet testerov. Tento rozpor je ako činná sopka – sem-tam vypúšťa dym až do chvíle, kedy je energie dosť a dôjde k výbuchu.

Spočiatku sme ako spôsob testovania zvolili ručné testovanie. To znamená, že aj regresné testy sa vykonávali ručne. Prvý rok a pol až dva to bolo únosné. V treťom roku sme narazili na strop možností našich testerov. Jednoducho už nebolo dostatok testerských síl, aby boli schopní otestovať všetko, čo bolo treba. Riešenie, ktoré bolo zvolené na začiatku, bolo vybrané na základe aktuálneho stavu veci. Až teraz sa jasne ukázalo ako nefunkčné práve preto, lebo pracovalo s veličinou, ktorá sa menila (rástla), a to množstvo funkcionality, ktorú treba otestovať. Ostávali len dve možnosti: zmeniť konštantu (počet testerov) alebo zvoliť iné riešenie.

Tým iným riešením sa ukázalo automatické testovanie. V podstate sme nevymysleli nič nové, pretože o automatickom testovaní sa hovorí prakticky v každej knihe o agilných metódach. To, čo sme museli vymyslieť bolo, ktoré nástroje a postupy použiť. Všetko to ešte komplikovalo to, že sme v podstate sedeli v rozbehnutom vlaku, t.j. na projekte sa stále pracovalo a naši testeri (ktorí by mali mať túto automatizáciu hlavne na starosti) mali dosť práce s ručným testovaním. Takže sme pozbierali všetok zvyšný čas, ktorý ostával a investovali ho do toho riešenia. To spolu s nejakou príležitostnou výpomocnou silou viedlo k tomu, že sa nám pomaly začali uvoľňovať ruky a mali sme čas pustiť sa aj do zložitejších častí.

Dnes sa dá povedať, že sme niekde v polovici splácania technologického dlhu z čias, kedy sme vykonávali ručné testy. Samozrejme, rastúce množstvo funkcionality má vplyv aj na množstvo automatických testov. To vedie k predĺženiu ich behu a času ich spravovania. Ale v konečnom dôsledku je to veľmi ďaleko od toho, aby to opäť udrelo o strop – teda narazilo na nejakú konštantu (tou najbližšou môže byť počet nočných hodín, ktoré máme na spúšťanie testov).

Množstvo literatúry o agilných metódach a aj vlastné skúsenosti ma presviedčajú, že sa veľké agilne riadené projekty bez automatizácie nezaobídu. Že požiadavky ako krátkodobé plánovanie a časté zverejňovania nových verzií musia viesť k jej zavedeniu. Na záver už len môj osobný zoznam výhod automatizácie:

1.       Znižovanie rizika (chýb, alebo akýchkoľvek problémov, ktoré by vedelo testovanie odhaliť)

2.       Odbúrava rutinnú prácu a uvoľňuje ruky pre kreatívnu prácu

3.       Informuje (výsledky testov si môže prečítať ktokoľvek)

4.       Núti k dobrému návrhu (napr. jednotkové testy) a pochopeniu (nahrávanie automatického testu často viedlo k hlbšiemu rozboru súčasného stavu funkcionality)

5.       Je niekedy zábava J (hlavne keď sa darí)

Pre tých, ktorý hľadajú nejaké zdroje:

[1] Paul Duvall: Continuous Integration: Improving Software Quality and Reducing Risk

[2] Lisa Crispin, Janet Gregory: Agile Testing

[3] Mike Gunderloy: Z kodéra vývojářem

Efektívna retrospektíva

Posted on by

agile.retrospectives

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.

Zákazník ako spoluhráč

Posted on by

innovation.gamesUž sa vám niekedy stalo, že ste dali zákazníkovi niečo len preto, aby zistil, že v podstate chcel niečo iné? Teória Lean-u by na to povedala, že ste práve vyrobili odpad. Samotná chyba ale nemusela byť vo výrobnom procese, ale v tom, že zákazník nevedel vyjadriť, čo presne chce. Agilné metódy radia, že máte so zákazníkom komunikovať tak často ako sa dá. Menej rád už ale ponúkajú v tom, ako presne to máte robiť. Ako z neho dostanete informáciu, ktorú síce má, ale o tom, že ju vlastní ani sám netuší? Luke Hohmann vo svojej knihe Innovation Games odporúča zahrať si so zákazníkom hru.

Ak si pod pojmom „hra“ predstavíte Človeče nehnevaj sa, tak to ste vedľa. Dá sa povedať, že väčšinou ide skôr o psychologické praktiky zabalené do pozlátka niečoho, čo ako hra vyzerá. Napríklad Product Box. Predstavte si, že si zvoláte niekoľko zákazníkov na stretnutie. Rozdáte im biele kartónové škatule, fixy, lepidlo, nožnice, farebný papier atď. a poviete im, aby skúsili vyrobiť obal na produkt, aký by si chceli kúpiť. A keď sú hotoví, tak na dôvažok sa ešte môžu pokúsiť svoju produktovú škatuľu akoby predviesť a predať ostatným zákazníkom. Vyberú sa najlepšie návrhy, odmenia sa nejakou pozornosťou a vy si na záver odnesiete kopec škatúľ na povrchu, ktorých môžete nájsť ozajstné bohatstvo informácii o tom, čo vaši zákazníci chcú. Toto je len jedna z 12 hier, ktorú Luke prezentuje.

Okrem teoretického úvodu a praktického záveru je kniha de facto katalógom. Katalógom hier s popisom ich použitia, vlastností, dobrých rád a trikov. Niektoré hry sú také jednoduché, že sa možno až zarazíte, prečo vás to samých doteraz nenapadlo. Hry majú rôzne charakteristiky ako napríklad náročnosť fyzickej prípravy, veľkosť skupiny zákazníkov s ktorými budete hrať, doba hrania atď. Podľa týchto charakteristík a podľa účelu potom viete vybrať najvhodnejšiu hru pre danú príležitosť. Okrem toho je pri každej hre uvedená krátka teória o tom, prečo hra funguje a niekde aj reálne informácie z používania hry. Ten teoretický popis je už na hranici psychologickej literatúry, ale to už je asi dôsledok toho, že hry reprezentujú len inú formu komunikácie.

O Scrum-e som už viac krát počul, že sa robí len veľmi ťažko, ak ho s vami zákazník „nechce hrať“. Ak neuznáva pozíciu Product Ownera, ak chce presný a dlhodobý plán alebo nechce počas vývoja komunikovať. Ak však máte šťastie a zákazník Scrum hrá, možno viete vašu komunikáciu s ním posunúť opäť o úroveň vyššie. Dostať z neho informácie tak, aby najbližšie, keď mu budete prezentovať produkt, mohol povedať, že je to presne to, čo chcel. Innovation Games ponúka návody ako na to. Určite to nie je instantné riešenie, ktoré len zalejete vriacou vodu a máte okamžite výsledky. Zorganizovať a správne odmoderovať takúto akciu vyžaduje aj nejakú prax, ale to, čo získate, môže byť natoľko unikátne, že tá námaha stojí za to.

Trénovanie agilných tímov v praxi

Posted on by

coaching.agile.teamsObčas sa stáva, že pri zavádzaní Scrumu uviaznete v bludnom kruhu. Ten kruh je tvorený dvoma faktami: agilné metódy začnú fungovať až v momente, keď ich ľudia začnú používať a ľudia začnú nejaké metódy používať až v momente, keď vidia, že fungujú. Tento cyklus sa dá prerušiť tým, že používanie dostanú ľudia jednoducho príkazom, ale to nie je v duchu agilných metód, ktoré stavajú ľudí na prvé miesto (určite tým stratíte ich angažovanosť, čo je vzácna a ťažko nahraditeľná surovina). Našťastie má tento problém aj iné riešenie, ktoré môžete nájsť v knihe Coaching Agile Teams od Lyssa Adkinsonovej.

Kniha sa pohybuje na hranici psychológie a riadenia, pričom som mal miestami pocit, že sa viac nakláňa k psychológii. Každopádne nie je jej cieľom vysvetľovať agilné postupy. Automaticky predpokladá, že v týchto veciach už máte jasno. To, čomu sa hlavne venuje, je práca s ľuďmi a postupy ako naviesť tímy k používaniu agilných metód. Presnejšie povedané, ako by ste sa mali vy správať, aby sa vám to podarilo. V hlavnej časti Lyssa prezentuje rôzne roly, v ktorých sa môžete ocitnúť, ak sa podujmete koučovať tímy:

  • Coach-Mentor – popisuje ako zvládať rôzne techniky koučovania (tím vs. jednotlivec) ako aj spôsob koučovania v rôznych fázach sprintu (dokonca ako koučovať koučaJ );
  • Facilitator – ako učiť ľudí správne realizovať porady;
  • Teacher – ako naučiť ľudí zvládať agilné praktiky;
  • Problem Solver – riešenie problémov projektu ako aj nastavenie tímu tak, aby ich dokázal v budúcnosti riešiť sám;
  • Conflict Navigator – riešenie konfliktov v tíme. Uvádza napríklad päť stupňov konfliktu: Problém, Nesúhlas, Spor, Križiacka výprava, Svetová vojna, ktoré môžu medzi ľuďmi nastať, a čo v ktorom prípade robiť;
  • Collaboration Conductor – podpora komunikácie ako základu spolupráce v tíme.

Autorka tak skúma pozíciu kouča z viacerých uhlov pohľadov. Každej takejto role venuje niekoľko podkapitol odporúčaných praktík a najčastejších problémov.

Vo zvyšných kapitolách sa snaží Lyssa presvedčiť, že správny agilný kouč musí začať od seba. Že musí absorbovať základné princípy agilného riadenia a žiť nimi. Často krát som mal pocit, že sa dokonca snaží skrz knihu koučovať čitateľa, hlavne pri niekoľkonásobnom opakovaní tej istej myšlienky len inými slovami (čo viedlo k miernemu nárastu objemu knihy, ktorému by sa dalo podľa mňa vyhnúť). Každopádne je v knihe daný silný dôraz na osobný rast a vývoj a skrz neho potom aj na vývoj vašich schopností predať agilné cítenie ľuďom. Zaujímavé sú takzvané úspešné a neúspešné režimy, v ktorých môžete skončiť, ak sa o koučovanie budete pokúšať.

Na záver sa dá povedať, že ak patríte k ľudom, ktorí nemajú agilnými metódami len žiť, ale majú aj poslanie ich šíriť ďalej, tak je toto kniha, ktorá by vás nemala minúť. Po prvé preto, lebo kníh, ktoré sa venujú koučovaniu a agilným metódam nie je veľa (podobná je snáď už len Agile Coaching od R. Davies a L. Sedley) a po druhé preto, lebo problematika koučovania je v nej rozobraná pomerne podrobne, a preto aj skúsený profesionál môže objaviť niekoľko drahokamov medzi riadkami. A ešte jedna myšlienka, ktorá sa mne osobne veľmi zapáčila (z kapitoly o tom, že pri agilných metódach musíte byť schopný prijať zlyhanie a zotaviť sa z neho): The battle cry of a team may be, „If we’re going to fail, let’s fail fast.“

Semafor

Posted on by

Viditeľnosť patrí k základným princípom agilných metód. Kontinuálne zostavovanie patrí základným praktikám agilného vývoja softvéru. Ak sa pokúsite tieto dva veci spojiť, veľmi ľahko vám môže vzniknúť jednoduché signalizačné zariadenie – semafor.

Semafor

Ten náš sme pripojili k systému len pred niekoľkými mesiacmi ale aj za ten krátky čas sa osvedčil. Je omnoho ľahšie prehliadnuť alebo ignorovať červenú na web stránke ale v oznamovacej oblasti Windows-u. O čosi ťažšie to ide vám na okraji zorného poľa zasvieti červená žiarovka (je umiestnený tak, aby na neho videl všetci členovia tímu – máme to šťastie, že sme všetci na jednom mieste). Reakcia na chyby pri zostavovaní sa skrátila na minimum. O vyzdvihnutí firemného povedomia  o vašom projekte mimo tímu ani nehovoriac (tak ako to už býva pri každej dobrej vizualizácii).

Je pripojený cez paralelný port a upravenú verziu klient CruiseControl.Net.  Na záver ešte uvádzam sprievodcu náhodného pozorovateľa, ktorý visí na nástenke blízko semafora.sprievodca.semaforom

Ako uspieť, ak ste už raz začali

Posted on by

obal.succeeding.with.agile

Nie vždy sa mi stáva, že sa mi dostane do rúk kniha, ktorá by dokázala posunúť môj názor na nejakú vec naraz vo viacerých smeroch. Tentokrát som mal  opäť raz šťastie, keď som natrafil na Succeeding with Agile od Mike Cohna. Je niekoľko vecí, ktoré sa dajú o tejto knihe povedať, a jedna z nich je, že ak to myslíte s agilnými metódami vážne, tak čas strávený jej čítaním nebude určite premrhaný.

Táto kniha nie je pre ľudí, ktorí si kladú otázku: „Čo sú to agilné metódy?“, alebo „Ako vlastne vyzerá Scrum?“. Autor predpokladá, že na to už máte odpovede a vedie diskusiu viac do hĺbky adaptácie agility. Je to kniha hlavne pre ľudí, ktorí čo-to o agilných metóda vedia, niečo si aj skúsili a narazili na rôzne druhy prekážok. Jej čítaním totiž veľmi ľahko zistíte, že vaše problémy nie sú až tak unikátne ako možno vyzerajú a ich riešenie už existuje. Zaujímavé sú napríklad takzvané „časté námietky“ ľudí voči agilným metódam a Mikové odpovede na ne. Niektoré vám možno budú pripadať povedomé…

Kniha je rozdelená na päť častí, pričom v prvej autor vysvetľuje základné fakty o adaptácii Scrumu. Nečakajte ale vysvetlenie toho, čo je to sprint. Namiesto toho Mike prezentuje 5-krokový proces, ktorý je vhodný k adaptácii Scrumu a vzory šírenia agilných praktík medzi tímami. Okrem toho zavádza pre mňa veľmi príslovečný pojem „organizačná gravitácia“ – t.j. pôsobenie (sily) zvyšku organizácie voči prechode tímu na agilnú metódu. Ak prekonáte túto silu, dostanete sa na orbit (úspešná a trvalá adaptácia), ak nie, stiahne vás to späť.

Druhá časť pojednáva o jednotlivcoch. Hneď prvá kapitola vás naučí poradiť si s odporom k zmene (veľmi dobré čítanie na túto tému je aj kniha „Pocit naliehavosti“ od John P. Kottera). Ďalšie kapitoly informujú o tom, ako zaviesť nové roly, ktoré so sebou Scrum prináša (vytvorením alebo transformáciou klasických existujúcich) a ako ľudom vštiepiť technické praktiky, ktoré sú pre agilný vývoj nutné.

V tretej časti si berie na mušku fungovanie tímov. Od štruktúry tímu, cez budovanie spolupráce až po podporu samoorganizovanosti v tíme. V tejto kapitole tiež môžete nájsť informácie o tom, ako by mal vyzerať váš backlog, sprint, plánovanie a čo robiť, aby  ste do vášho produktu zapiekli dostatočné množstvo kvality.

Štvrtá časť je zameraná na väčšie organizácie. Mike prezentuje svoje znalosti ako sa vysporiadať s veľmi veľkými projektmi alebo ako zaviesť Scrum do distribuovaného prostredia. Zvláštna kapitola je venovaná spoluexistencii agilných metód s inými (klasickými) metódami v jednej organizácii. Ak ste niekedy stáli pred problémom ako riadiť projekt, ktorý je vo vnútri agilný a navonok klasický-sekvenčný, tak v tejto kapitole nájdete zopár dobrý postrehov.

Posledná časť je najkratšia, ale o to silnejšia. Mike v nej vstupuje do oblasti, o ktorej som ja osobne zatiaľ veľa literatúry nevidel, a to meranie agility. Ako veľmi ja náš tím agilný? Kde sme v porovnaní s obdobím pred rokom alebo v porovnaní s inými tímami? Ako veľa hodnoty sme dodali zákazníkovi? Ak vás trápia tieto alebo podobné otázky, tak v tejto kapitole by ste mohli nájsť zopár drahokamov medzi riadkami. Osobne ma prekvapilo, aké jednoduché praktiky sa dajú použiť, aby sme zistili, akú veľkú hodnotu dodáva tím zákazníkovi (niektoré z nich sme v našom tíme vyskúšali, a bolo naozaj zaujímavé sledovať ako zopár jednoduchých obrázkov vyjasnilo pomery).

Kniha Succeeding with Agile je určená ľudom, ktorí agilné metódy skúšajú a boria sa s rôznymi problémami, ktoré takáto adaptácia prináša. Je určená pre bojovníkov, ktorí sa rozhodli bojovať s organizačnou gravitáciou, aj pre zvedavcov, ktorí by sa už radi dozvedeli niečo viac, ako ponúka základné video o Scrume na Youtube. Je cítiť, že Mike do knihy vložil svoje dlhoročné skúsenosti a že píše o veciach, ktorým rozumie. Preto by táto kniha mala byť v knižnici každej spoločnosti, ktorá to s agilitou myslí vážne.

ScrumMaster, alebo prečo to nie je také jednoduché

Posted on by

Na Agileee 2009 som mal tú možnosť sa účastniť diskusie niekoľkých prednášajúcich tejto konferencie. Okrem iných tém sa v jednom momente diskusia viedla o tom, kto to má byť ScrumMaster. Zatiaľ čo niektorí tvrdili, že je to človek, ktorý musí byť zručný pri práci s ľudmi a organizovaní, iní tvrdili, že to môže robiť aj ich 5-ročný syn. Že je to pozícia, ktorá nevyžaduje žiadne špeciálne zručnosti, pretože človek vykonáva len jednoduché veci ako kreslenie grafu alebo varenie kávy pre tím. Verím, že rozlúsknuť tento problém nie je jednoduché, ale aj tak sa pokúsim prispieť k objasneniu.

Máme tu teda dva typy ScrumMastera. Jedného ako silného vodcu, ktorý zvláda prácu s ľuďmi, rozumie agilným metódam a má silné zručnosti v oblasti organizovania práce. Na druhej strane je to niekto, kto vykonáva rutinné práce potrebné na to, aby tím mohol nerušene pracovať. Tieto dva typy predstavujú opačné strany spektra, pričom typy ScrumMasterov v jednotlivých tímoch sa môžu pohybovať v ňom.

Je nutné povedať, že na tím sú kladené požiadavky. Tieto požiadavky môžu byť vnútorné, čo napríklad môže znamenať, že tím musí byť schopný uskutočniť poradu, vyriešiť konflikty alebo navrhnúť riešenie nejakého problému, a tiež vonkajšie, ako napríklad, že musí odovzdávať prehľady o svojej práci alebo musí byť schopný zodpovedať otázky ohľadom plánovania.

Predstavme si teraz na chvíľu absolútne ideálne samoorganizovaný tím. Je to skupina ľudí, ktorá (ako skupina) dokáže tieto požiadavky splniť. Ak treba aby sa uskutočnila porada, tak sa niekto postaví, poradu zvolá a odmoderuje ju. Ak treba vyriešiť problém, tak sa zíde niekoľko ľudí, dajú hlavy dokopy a nájdu najlepšie riešenie. Niekto kreslí graf a niekto pomáha s riešením konfliktov. Takto by mohol vyzerať ideálny svet.

V reálnom svete ale tím nie je schopný splniť všetky tieto požiadavky. Nedokáže napríklad sám zvolať poradu. Dôvody môžu byť rôzne ale faktom je, že v schopnostiach tímu plniť požiadavky môžu byť rôzne medzery. A práve tieto medzery musí zaplniť ScrumMaster. Som presvedčený, že práve preto táto pozícia vznikla. Aby bola schopná zastúpiť tím v akciách, ktorých sám nie je schopný. Je dôležité povedať, že dobrý ScrumMaster by mal vykonávať len veci, ktoré tím nezvláda spraviť sám, čo je jeden z rozdielov medzi vedúcim tímu a ScrumMastrom. K tomu sa ale dostaneme neskôr.

schopnosti.vs.poziadavky

Ak sa teda vrátim k dileme, ktorú som popísal na začiatku, tak jednoznačná odpoveď je, že ScrumMaster by mal mať také schopnosti, ako vyžaduje situácia tímu, teda rozdiel medzi tým, čo sa od tímu požaduje a čo je schopný plniť. Ak je to tím ľudí, ktorý agilné metódy nikdy nepoužívali, tak ScrumMaster musí byť veľmi skúsený a zručný. Naopak v tíme, ktorý už agilne funguje dlhšiu dobu a kde je vysoká samoorganizovanosť, ScrumMaster môže mať len veľmi málo úloh a zodpovedností. Preto neexistuje finálny zoznam povinností ScrumMastera. Tento zoznam by musel byť zostavený pre každý tím zvlášť.

Okrem tohto dôležitého faktu, je tu ešte jedna vec, a to, že ScrumMaster nie je iné meno pre vedúceho tímu. Medzi týmito dvoma rolami je veľký rozdiel. V prvom rade je to pozícia voči tímu. Vedúci tímu je v hierarchii nad tímom. Je to niekto, na koho je možné eskalovať problémy a kto je naopak schopný delegovať prácu. Zároveň väčšinou preberá zodpovednosť za výsledok tímu.

veduci.timu

Úlohou ScrumMastera je ale tímu pomáhať. Preto je jeho pozícia vedľa tímu alebo dokonca pod ním. V žiadnom prípade by nemal preberať zodpovednosť a rozdeľovať prácu by mal len v prípade, ak si ju tím nie je schopný rozdeliť sám (čo na určitom stupni samoorganizovanosti musí byť schopný). Ale čo je najdôležitejšie, zatiaľ čo vedúci tímu má vymedzené povinnosti a práva a tie sa prirodzene nemenia, ScrumMaster by sa mal prispôsobovať tímu (to znamená, nevykonávať činnosti, ktoré je tím schopný vykonať sám) a mal by tím viesť k tomu, aby bol schopný čo najviac plniť požiadavky, ktoré sú na neho kladené.

scrummaster

Práva a povinnosti ScrumMastera sa môžu teda časom meniť a pri správnom smerovaní by sa mali zmenšovať a oslabovať. Táto zmena filozofie roly môže byť najväčšia výzva pri prechode na agilné metódy zo starého systému riadenia, pretože ľudia sa len neradi vzdávajú moci kontrolovať a ovládať.

Na záver už len jedna rada ako preniesť na tím viac kompetencií ScrumMastera: nechať jeho pozíciu rotovať. Za určitého dozoru a prispenia zvonku je možné, aby ScrumMastrom bol každý sprint niekto iný. Toto je veľmi dobrý spôsob, ako dať ľudom pocítiť, že prácu, ktorú doteraz vykonával niekto konkrétny dokáže vykonávať každý. Že na nakreslenie grafu alebo zvolanie porady nie sú potrebné nijaké zvláštne danosti. Časom sa môže stať, že pozícia ScrumMastra natoľko oslabí, že už bude skoro jedno, kto to je. A to bude príznak, že tím ide správnym smerom.