Agilné testovanie? Prečo nie.

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.

Meetup, Máj, Košice

Chcem pozvať všetkých záujemcov o Agile na prvý meetup, ktorý plánujeme v týždni od 23.5-27.5.

Cieľom je spoznať sa, odpozorovať postupy iných a naučiť sa niečo nové.

Ak chcete prísť dajte nám vedieť emailom.

  • Preferujete nejaký deň?
  • Máte záujem o nejaké konkrétne témy?
  • Chcete prispieť do programu ako speaker?

Navrhované témy:

  1. Zavádzanie Scrumu vo firemnom prostredí
  2. Čo znamená byť dobrý ScrumMaster
  3. Agile hry pre naše tímy

Organizácia

Meetup prezentácie sú limitované na 15 minút, max. 3 prezentácie + open space diskusia.

Vstupné 0 Euro, nápoje ani jedlo si každý hradí sám.

Workshop Scrum v reálnom živote, 7.4., Bratislava

Chcete produkovať rýchlejšie a kvalitnejšie ako konkurencia? Komplikujú Vám časté zmeny projektov život?

Scrum, agilný projektový framework, mení spôsob vývoja a dodávania produktov s výrazným zameraním na prispôsobenie sa meniacim sa požiadavkám zákazníka, skrátenie cyklu vývoja, zlepšenie tímov a zvýšenie kvality.

Registrovať

Workshop Scrum prakticky umožní Vašim tímom pochopiť základy frameworku, roly a ich zodpovednosti, agilné postupy pri vývoji a agilné metriky. Naučíte sa ako pracovať s množstvom požiadaviek a ako odhadnúť agilný projekt.

Scrum spoznáte praktickými príkladmi a hrami, ktoré budete môcť aplikovať aj vo svojich tímoch. Táto forma je overená stovkami účastníkov v minulých rokoch.

Prečo?

  • Pochopíte Scrum, roly a ceremónie. Dozviete sa o agilných princípoch a iných metódach.
  • Aplikujete Scrum prakticky počas workshopu.
  • Naučiť sa plánovať s prispôsobením sa častým zmenám.
  • Spoznáte spôsoby prioritizácie požiadaviek Vašich zákazníkov podľa obchodnej hodnoty.
  • Porozumiete ako je potrebné zmeniť myslenie pre zrýchlenie vývoja.
  • Naučíte sa praktické hry a príklady, ktoré pomôžu Vašim tímom pri adaptácii agile.

Pre koho?

  • Senior manažment – ak uvažujete o transformáci Vašej spoločnosti
  • Produktový manažment –  ak potrebujete pracovať s množstvom požiadaviek a chcete dodávať kvalitné produkty načas.
  • Projektový manažment – ak chcete riešiť dilemu trojúholníka rozpočet , rozsah a čas.
  • Vývojári, testeri a iné roly v tíme

Zažite Scrum prakticky!

Úspech zabíja naliehavosť

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 zmenyNáš ľ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

Konferencia Agile Central Europe

ACE_side_banner_155pxMáte cestu koncom marca do Krakowa?

Zájdite určite aj na konferenciu Agile Central Europe.

31.3 – 1.4. 2011, Monte Cassino 2, Kraków, Poland

Spíkri: Corey Haines, Monika Konieczny, Maria Diaconu, Alexandru Bolboacă,

Petra Skapa, Marc Löffler, Paweł Brodzinski, a ďalší

Vďaka organizátorom sa nám podarilo získať 25 EUR zľavu pre všetkých, ktorí použijú discount code: ACE!AgileSK

Agilná transformácia formou hry

Keď pred pár týždňami nás kontaktoval Zsolt Zsuffa z Budapešte ohľadom participácie na Agile Meetupe, ponúkli sme rôzne témy krátkeho školenia. S prekvapením sa však Zsolt priamo spýtal na agilné hry. Zaujali ho naše skúsenosti a výsledky a tak chcel skúsiť touto formou stmeliť aj agilnú komunitu v Maďarsku. Pre nás to bola možnosť konečne po prezentáciách urobiť aj niečo praktické, čo ľudia budú môcť vyskúšať aj vo vlastných firmách.

Prechod na agilné technológie je  v dnešnej dobe aktuálnym v mnohých spoločnostiach. Spoločnosti sú zväčša zamerané len na výsledky, ktoré sa dajú merať. V mnohých prípadoch však chýba niečo oveľa dôležitejšie, čo agile priam vyžaduje – zmena myslenia. Táto zmena vyžaduje čas a skúsenosti. Nedá sa naučiť, musí sa zažiť. Je to dospievanie. V takomto prípade je zlyhanie dokonca cennou skúsenosťou, ktorú chceme zažiť často a skoro, hlavne ak ste na začiatku transformácie.

Agilné hry sa stávajú (podobne ako v živote dieťaťa) katalyzátorom vývoja a stávajú sa tak lepidlom ktoré prepája teóriu s praxou. Sú možnosťou ako sa naučiť robiť agile na príkladoch. S pomocou kouča takto tímy nemôžu zlyhať pri učení ako agile robiť.

Hry hrajeme počas tréningov na Slovensku aj v zahraničí už niekoľko rokov. V Budapešti sme sa zamerali na hry vybrané pre transformáciu spoločností na agile:

  • vytvorenie tímu a jeho samoorganizácia
  • pochopenie problémov a zvyraznenie ich podobnosti v celom softvérovom priemysle
  • identifikácia dôvodov prečo agile vzniklo
  • naučenie sa ako robiť agile, ako pracovať v časových iteráciách, ako samoorganizovať nielen tím, ale aj prácu, prečo je jednoduché zadanie požiadavky často efektívnejšie než dlhé dokumenty
  • ako sa zlepšiť použitím retrospektívy

Originál viď ScrumDesk: Serious Play – accelerate your transition to Agile

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

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

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.