Daily stand-up dobre II. – najlepšie pred monitorom!

V prvom príspevku sme priblížili dôvody pre pravidelné stretnutia tímu. Ďalšou otázkou Scrum mastra by mal byť priestor, v ktorom stand-up robiť. Táto téma je samozrejme dôležitejšia pre tímy v jednej lokalite.

daily-standup1

Veľmi častou chybou je totiž stand-up v priestoroch tímu bez akejkoľvek zmeny. Jednoducho ľudia naďalej sedia za svojim počítačom a najväčší pohyb, ktorý spravia, je zdvihnutie hlavy od obrazovky v momente, kedy sa majú zapojiť. V momente, keď skončia, hlava im opäť padne smerom k monitoru a (vraj) počúvajú.

Stand-up tak nemá žiadnu dynamiku, nie je nič čo by vytváralo podmienky pre spoluprácu pri riešení spoločného problému tímu. Scrum mastri sa často čudujú, keď sa spýtam či je to dobrý spôsob. Nevidia veľa možností na zmenu. Veď odpovede na tri otázky prichádzajú a mítíng sa predsa konal.

Ako na to? Narušte komfortnú zónu. Aj preto sa odporúča, aby míting prebiehal pred fyzickou tabuľou.

Možno by vám pomohlo:

  • odísť od monitorov,
  • niekedy skutočne stačí aby sa ľudia iba postavili zo stoličky,
  • vytvoriť polkruh okolo tabule (hoci aj elektronickej, ale na jednej obrazovke!),
  • zabezpečiť aby tím nebol rušený či už telefónmi alebo chatom,
  • priestor by mal poskytnúť súkromie bez rušenia inými ľuďmi,
  • zároveň by ale ostatní mali mať možnosť si niekde sadnúť a pasívne sa zúčastniť stretnutia (iní scrum mastri, iné tímy, manažment),
  • ľudia mali mať tabuľu a papieriky na dohľad,
  • ľudia by si mali vidieť vzájomne do očí.

Práve táketo malé zmeny znamenajú väčšie predpoklady pre koncentráciu na tému stretnutia, aktívne počúvanie a prispievanie do diskusie.

A čo v prípade distribuovaného tímu? No tu od monitora asi neodídete, ale skúste si pred mítingom vypnúť email, skype, Facebook, Twitter a iné stránky, ktoré by vás mohli prípadne rušiť…

Ako to vyzerá na Vašom stand-up mítingu?

 

Daily standup dobre – I. Prečo?

Pôvodný článok na http://scrum.sk/index.php/daily-standup-dobre-cast-1-preco/

Denný stand-up je základnou ceremóniou v Scrum, ktorá je (chvalabohu) v slovenských dolinách aplikovaná často aj bez toho, aby bola oficiálne formalizovaná. Predovšetkým v malých firmách, kde ešte stále je rozhovor základom spolupráce.

Často však po niekoľkých mesiacoch zrazu tieto stretnutia nemajú “šťavu”. Mnoho ľudí nám pri koučingu namieta, že je to strata času. Prečo?

Pripravili sme preto pre Vás krátku sériu článkov o typických chybách, ktorými tímy samé brzdia svoju agilitu.

Čo je cieľom vášho standupu?

Najčastejším problémom je nepochopenie cieľa tohto stretnutia. Členovia tímu a scrum mastri ho považujú za stretnutie, na ktorom sa má reportovať stav projektu formou odpovedí na tri otázky: “Čo si spravil včera, čo budeš robiť dnes a aké máš problémy.”. Áno je pravda, že tieto otázky sú odporúčané. No nie je pravdou, že ich najväčší prínos je v reportingu.

Cieľom standupu je rozpoznať čo náš tím obmedzuje v dokončení našich zámerov dohodnutých počas plánovania, ku ktorým sme sa zaviazali.

Má to teda byť stretnutie viac o blízkej budúcnosti, než stretnutie o tom, čo sa stalo. Má to byť o tíme, nie o jednotlivcoch.

Tím sa má sústrediť na to ako dokončiť prácu, nie na to, ako je implementácia rozpracovaná. Agile je totiž založené na podpore dodávania funkčných výsledkov, ktoré ak nie sú dokončené, tak jednoducho nie sú použiteľné. Navyše trh je nevyspytateľný a zmeny sú dnes už konštantou.

Práve preto by ste ako tím mali byť pripravení aj počas sprintu dodať už dokončené user stories, resp. opravené chyby. Kedykoľvek.

 

Stavy v procese, stĺpce na Kanban tabuli

Článok je prebraný z http://scrum.sk/index.php/stavy-a-stlpce-na-kanban-tabuli/

Kanban tabuľa

Kanban tabuľa je skvelou pomôckou agilného tímu. Vizualizácia stavu úloh umožňuje tímu sa efektívne samoorganizovať a zároveň budovať dôveru v tíme aj mimo neho.

Každý stĺpec tabule označuje stav. A práve počet stĺpcov, teda stavov, je jednou z prvých otázok scrum mastrov počas prípravy tímu.

Odpoveď závisí od spôsobu akým ste sa rozhodli zavádzať Agile. Ste otvorení väčším zmenám? Alebo radšej opatrne a postupne?

Veľká zmena – maximalizácia minima

Pred niekoľkými mesiacmi sme začínali transformáciu v tíme, ktorý vytvára komplexný informačný systém už niekoľko rokov. V skutočnosti to boli štyri tímy so zložitejším procesom vývoja a teda aj s viacerými stavmi.

Ešte pred začatím transformácie sa však tím rozhodol maximálne zjednodušiť workflow tak, aby sa nemuseli vývojári zamýšľať kedy dať kartu do akého stavu. Pre svoju Kanban tabuľu preto zaviedli iba tri stavy.

Kanban simple workflow proces

Výhody sa ukázali okamžite:

  • Jednoznačný stav. Úlohu je nutné spraviť, alebo sa na nej pracuje, alebo je hotová.
  • Veľa kariet. Aj keď to znelo ako zvýšenie byrokracie, v skutočnosti sa ukázalo, že toto rozhodnutie viedlo tím k lepšej príprave počas plánovania. Požiadavky sú rozdelené na viaceré úlohy, ktoré jasnejšie popisujú prístup k riešeniu požiadavky.
  • Lepšie odhady – každá karta má svoj jednoznačný odhad. Je jasné, koľko sa na kartu plánuje a koľko času ešte zostáva. V predchádzajúcom workflow mal tím špeciálny stav označujúci čakanie. A práve v takomto stave karty ‘viseli’ , no tím nesledoval ich trvanie.
  • Organizácia tímu – každá  karta má svojho riešiteľa. Tak je možné lepšie rozdeliť úlohy medzi členov tímu.
  • Adresnosť problému – v prípade problému pri riešení úlohy je možné ľahko identifikovať, ktoré úlohy majú problém a zviditeľniť ich.

Pomalá zmena

Iný tím sa rozhodol, že zavedenie troch stavov nie je možné vzhľadom k ďalším firemným procesom, no identifikovali, že zjednodušenie je nutné. Otázne bolo ako zmeniť proces čo najmenej a zároveň najefektívnejšie.

Jedným z agilných princípov je pozorovanie a adaptácia. Preto sme v tíme začali s vizualizáciou aktuálneho workflow. Od momentu vzniku požiadavky až po dodanie výsledku používateľom. Táto technika sa volá Value Stream Mapping. Obrázok ilustruje príklad výrobnej fabriky.

Value Stream Mapping

Ďalším krokom bolo meranie trvania spracovania úloh v jednotlivých stavoch a pri presunoch medzi nimi. Keďže hlavným cieľom transformácie bolo skrátiť čas dodávky používateľom, zamerali sme na najdlhšie časti, ktoré stálo zato optimalizovať. Optimalizácia však neznamenala, že sa meranie skončilo. Každá lokálna optimalizácia má dopady na celkový proces, a preto je nutné pokračovať v meraní a ďalšej optimalizácii. Je to v podstate neustály proces.

Vizualizácia a meranie zároveň pomohli identifkovať stavy, v ktorých sa úlohy dlho ‘neohriali’. Úlohy boli cez nich iba presúvané. Tieto stavy boli z workflow odstránené čo zjednodušilo aj samotný proces.

Čo sa pýtať pri vytváraní Kanban tabule?

  • Prečo potrebujeme daný stav?
  • Kto potrebuje daný stav?
  • Ako dlho zostáva úloha v danom stave?
  • Má stav zmysel aj v prípade, že úloha nie je vývojová, ale napr.  napísanie dokumentu?
  • Potrebujete stav merať a vykazovať? Pre koho a prečo? Má to súvis s biznis hodnotou?
  • Čo je zbytočné?
  • Neexistujú iné workflow pre rôzne činnosti vývojového tímu? Napr. riešenie podpory, spracovanie kritických požiadaviek, požiadavky na súčinnosť.

Pr_duktívne plánovanie

Článok je prebraný z http://scrum.sk/index.php/produktivne_planovanie/

Počas niekoľkých posledných mesiacov sa mi naskytla príležitosť zúčastniť sa viacerých plánovacích stretnutí tímov s rôznou dobou nasadenia agile. Od úplných začiatočníkov až po starých harcovníkov, ktorí agile aplikujú už viac ako päť rokov.

Zaujalo ma na nich to, že:

  1. Efektivita plánovania nezávisí od trvania aplikácie agile.
  2. Tímy bez feedbacku upadajú do stereotypov a iba aplikujú procesy.
  3. Tímy sa zamerajú na zjednodušenie práce (rozumej lenivejú) a úplne zabúdajú na dôvôdy prečo sa plánuje.
  4. Výsledkom nie je plán, ktorému všetci rozumejú.
  5. Plán nie je plánom tímu, ale plánom jednotlivcov.
  6. Nesprávne pochopenie kedy a ako aplikovať story pointy a kedy hodiny.
  7. Nepochopenie, prečo vlastne odhadovať čas.
  8. Sprinty napriek plánovaniu aj tak nie sú ukončené načas a tím napriek tomu necíti zodpovednosť.

 

Možno predpokladáte, že tieto chyby mali tímy, ktoré začínali. No nebolo to tak. Tieto chyby sa objavili v skúsených tímoch. Vedené certifikovanými scrum mastrami.

 

A výsledok? Frustrácie manažmentu z nejasného termínu dodania, čo vedie k neustálym zmenám priorít. To prirodzene frustruje zákazníka aj tím. Navyše to prispieva k nemožnosti plánovania, práve kvôli častým zmenám. A začarovaný kruh je na svete. Plánovanie je frustrácia, ktorá bolí a preto ho chceme mať z krku. Preboha, veď za tie 4 hodiny sa dá toho tak veľa stihnúť naprogramovať.

Pravda starých otcov

Jeden z mojich prvých manažérov ma učil pravidlo brúsenia sekery. Jednoducho povedané, nedá sa len stínať stromy. To aj drevorubač sa musí zastaviť, vybrať si ten správny smer, vybrať stromy a nabrúsiť sekeru. Až potom rúbať stromy tak, aby vládal aj na ďalší deň. Ako je to v IT? (Lepší?) Vývojár chce vyvíjať. Všetko ostatné je balast. Sekera sa brúsi iba ojedinele.

No to brúsenie sekery má niečo v sebe…

Pravda starých agilistov

Agilné princípy ukazujú ako z tejto frustrácie von. Začať treba Agilným Manifestom, ktoré dáva do popredia funkčný softvér. Vytvorený v spolupráci tímu, zákazníka tak, aby bol pripravený na zmeny.

Účelom plánovania je robiť plánovanie, nie vytvárať plány.

Teda:

  • spoznať čo ideme dokončiť počas sprintu,
  • chceme začať s čistým stolom, začať novú iteráciu,
  • stanoviť si tímový záväzok k tomu, čo vieme dokončiť a koľko vieme dokončiť,
  • vytvoriť priestor pre spokojnosť. Spokojnosť tímu, klientov aj manažmentu.

Agenda

Často odpozorovanou chybou je úplne chýbajúca agenda stretnutia. Nepripravenosť z pohľadu organizácie času, postupu, priestorov a potrebného materiálu. Tím jednoducho prišiel na plánovanie a nechal sa unášať. V takýchto prípadoch začujete najčastejšie otázku ”Kedy vlastne máme obed?”. Áno, najčastejšie je práve táto prvou otázkou.

Čo je teda potrebné na plánovanie? Tu je niekoľko postrehov.

Čas

Predpokladajte  trvanie asi 2-4 hodiny podľa pripravenosti backlogu. Je to dlho? Radšej si sadnúť na dve hodiny a dohodnúť než potom zmätene hľadať spôsob riešenia niekoľko dní…

Pripravenosť

Dobrý scrum master pripraví miestnosť. Projektor, laptop, funkčné pripojenie k elektronickej tabuli. Telefón(y), web kamery ak je to potrebné.  Viditeľný časový rámec jednotlivých aktivít. Stopky alebo hodiny merajúce čas. A samozrejme pozve ľudí aj poslaním udalosti do kalendára. Dostatočne vopred. Najmenej 2 týždne vopred.

Dobrý produktový vlastník príde na plánovanie s pripravenými požiadavkami, ich prioritami. S odhadnutou biznis hodnotou, rizikom a MoSCoW. S akceptačnými kritériami. Vo forme, ktorú tím považuje za stav pripravený (definition of ready).

Dobré tímy už vedia čo v sprint backlogu je. Už si ho vopred každý preštudoval, napísal si pripomienky, resp. otázky a vie čo musí spraviť pre dokončenie požiadaviek. Má predpripravené konkrétne úlohy.

P1030082

V takomto prípade dokončí 10 ľudí plánovanie sprintu do 2 hodín určite. Postrehli ste ale tú disciplínu v príprave?

Kartičky

Budete potrebovať kartičky, kartičky, kartičky. A ešte raz kartičky. Zabudnite na notebooky. Plánovanie má byť tímovou prácou (manifesto).

S kartami sa ľahko manipuluje, ľahko sa prioritzuje, delí, vytvára nový obsah. Backlog sa jednoducho dá rozdeliť medzi viacero ľudí, zparalelniť prácu. Plánovanie tak bude intenzívne, efektívne a produktívne. Až keď skončíte plánovanie, až potom zadajte všetky karty do nástroja. Ak to urobíte všetci z tímu, tak zadať niekoľko desiatok kariet vám nezaberie viac ako pol hodinu.

P1050046

Aké je to s jedným laptopom a projektorom? Prduktívne. Všetci sedia okolo stola so založenými rukami a v tom lepšom prípade pozerajú na stenu. V bežnom prípade sa hrajú s telefónom pod stolom. Preto prduktívne.

Hmm, notebook

Ok, maximálne jeden, ak váš backlog je v elektronickom nástroji. Aby ste sa vedeli prehrabať v referenciách a ďalších potrebných informáciách. No prineste sprint backlog aj na kartičkách. Malá komplikácia, ktorá zvyšuje produktivitu.

Definícia Hotovo

Prineste si aj vašu definíciu Hotovo. Aby vám pomohla ako šablóna pri písaní úloh. Možno budete potrebovať viacero definícií. Pre user stories alebo chyby.

DoD

Rýchlosť a história

Aby ste sa vyhli zbytočnému deleniu požiadaviek na úlohy, do sprintu má produktový vlastník zaradiť iba toľko stories, koľko tím stihol dokončiť v predchádzajúcich sprintoch. Koľko story pointov bolo realné dokončených.

velocity

Kapacita

Zrátajte kapacitu tímu. Koľko dní budú členovia tímu v práci. Koľko hodín denne sa vedia venovať backlogu. Každú úlohu potom odhadnite v hodinách a nakoniec skontrolujte, či ich stihnete dokončiť.

Aby ste si vedeli overiť, či náhodou ste si nenaplánovali príliš veľa práce na sprint, ktorú nemáte možnosť stihnúť.

Kapacita

A výsledok plánovania?

Výsledkom dobrého plánovania sú:

  • prioritizované user stories,
  • dohodnuté akceptačné kritériá,
  • identifikované riziká,
  • rozdelené user stories na implementačné úlohy podľa definície hotovo a podľa charakteru požiadaviek,
  • odhadnutý čas imlementácie úloh,
  • overená možnosť dokončenia sprint backlogu podľa kapacity tímu a podľa dostupnosti jednotlivých členov tímu,
  • pocit, že vieme takýto sprint dokončiť.

Pocit je často pravdivejší než akákoľvek matematika….

Veľa úspechov pri plánovaní ďalších sprintov, ktoré sa vám podarí dokončiť.

Agile Manifesto slovensky

Som hrdý a veľmí rád, že po niekoľkotýždňovom úsilí sa podarilo niečo jedinečné.

Agile Manifesto v slovenskom preklade je oficálne dostupné na stránkach http://agilemanifesto.org/iso/sk/.

Pred niekoľkými rokmi sme v Agile@Slovakia iniciovali preklad použitím nástrojov, ktoré dala k dispozícii Agile Alliance. Bohužiaľ sa však táto aktivita zastavila. Napriek počiatočnému úsiliu sa ukázalo, že ľudia si museli na preklad násť dostatok času, no iterácie použitím nástrojov boli pomalé.

Premýšľali sme ako tento preklad dokončiť. Mnoho zo Scrum Mastrov potrebuje aplikovať koučing princípov a v mnohých firmách je anglický jazyk stále problémom.

Najlepším riešením sa ukázalo aplikovanie agilných princípov. Ľudia a komunikácia sú viac než procesy a nástroje. Rozhodli sme sa preto priniesť manifesto čo najbližšie k vám. Tak, aby sme stihli preklad iterovať počas 1 hodiny.

Tri slovenské mestá. Viac ako 50 ľudí. Aplikovanie agilnej techniky známej ako Triple Nickel. Ukázali sme tak účastníkom aj nový spôsob ako pracovať tímovo pri spodrobnení požiadaviek alebo počas retrospektív.

Na preklade sa podieľal Andrej Rehák,Barbora Moravcová,Dada Babušíková,Dušan Kocúrek,Dušan Mušák, Eva Kišoňová,Gabriel Kaputa,Ivan Kopčík,Iveta Tonhauserová,Ján Krajčík,Ján Polák,Ján Šimko, Jaroslav Kotuľák,Jaroslav Rybak,Karol Konkoly,Ľubomír Bogola,Ľuboslav Jochman, Marcel Majerník,Marcel Miklúš,Marek Kuzma,Marián Tkáčik,Martin Brzjak,Martin Kobyľan,Martin Kovač,Martin Major,Matúš Ferko,Matúš Kosa,Michal Bábics,Michal Augustín,Michal Dobiš,Michal Harhaj,Miroslav Mészáros, Oliver Textor,Ondrej Kubo,Ondrej Makši,Peter Kažimír,Peter Nosál,Peter Špireng,Peter Urban,Peter Užek,Radovan Balvan,Radovan Staš,Róbert Hájek,Robert Šoffa,Roman Pieron, Slavomír Bača,Tibor Szabó,Vladimír Olekšák,Vladimír Pavlík,Zdenko Vrábeľ,Zoltán Šipkai.

Ďakujeme všetkým za Vašu pomoc a podporu!

Preklad Agile Manifesto v Bratislave, 28.2.2012

Vo februári sa v Bratislave zišlo ako dvadsať ľudí, ktorí spoločne prispeli k prekladu Agile Manifesta do slovenského jazyka.
Bratislavský preklad vzišiel z predchádzajúcich výsledkov košického tímu.

Už budúci týždeň pokračujeme v Žiline!

Keď zákazník nevie, čo chce

jhkhkj45Mož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

Manažér v agilnom prostredí. Ako?

Tiež ste vo vašom tíme začuli vetičku: ”Manažment si opäť raz niečo zmyslel…”? Mohokrát vývojové tímy takto reagujú na zmenu. No často mylne predpokladajú, že manažment im chce zle. A bohužiaľ čsto je dôvodom aj spôsob, akým manažment zmenu komunikuje.

Prečo sa teda objavil manažment? Ako manažment pomáha a na čo je potrebný? Ako spojiť svet  vývojára a svet manažéra v agilnej spoločnosti?

Prečo manažment?

Manažérske myslenie sa objavilo už u starých sumerských obchodníkov. Prechod z manufaktúrnej výroby na industriálnu si vyžadoval zmeniť princípy tvorby produktov a organizácie práce. Produkty sa začali vytvárať väčším množstvom ľudí, ktorých bolo potrebné efektívne organizovať  tak, aby sa zvyšovala produktivita a zároveň mala správny ekonomický efekt pri dosiahnutí stanovených cieľov.

Od vtedy prešiel manažment mnohými transformáciami definovanými známymi autormi ako napr.Adam SmithFrederick Winslow Taylor alebo Peter Drucker. Najnovší vývoj manažmentu nás privádza k teórii obmedzení, Six Sigma a samozrejme aj agile.

Aj agilné projekty musia spĺňať rovnaké predpoklady: efektivitu produktivity, naplnenie cieľov, organizáciu práce a samozrejme ekonomické ukazovatele. A práve preto aj v takýchto tímoch môže manažér byť nápomocný a prospešný.

Ako sa však vystupovať ako manažér v tomto prípade?

Manažér

Douglas McGregor v šesťdesiatych rokoch postuloval Teóriu X a Y, ktorá delí prístup manažérov do dvoch skupín – X a Y.

Manažéra X je presvedčený, že ľudia sú leniví a práca ich nenapĺňa. Preto manažér Xpreferuje riadenie príkazmi, ktorých realizáciu kontroluje dávaním termínov a jasných inštrukcií ako príkazy naplniť. Názor podriadených nie je podstatný, podstatné je naplnenie príkazov.

Manažér Y funguje v inom móde. Je presvedčený, že ľudia chápu prácu ako ľudskú prirodzenosť. Tá ich nielen napĺňa, ale dokonca hľadajú spôsoby ako prijať zodpovednosť pri využití svojichnajlepších schopností.

Ľudia však často nevidia aké sú ich najlepšie schopnosti. A preto tento manažér podnecuje,inšpirujePomáha podriadeným s dosiahnutím požadovaného cieľa  a podporuje ich v ich snažení.  Ale asi to najdôležitejšie, aktívne počúva.

Manažér Z

V neskoršom období sa objavila aj definícia ďalšieho typu manažéra. Manažér Z podporujeidentifikáciu podriadených s firmou. Práve zamestnancom totiž záleží na úspešnosti firmy.

Manažér Z nepovažuje ľudí za zdroje. Preferuje vytváranie rodinnej atmosféry, podporuje tradície firmy a vytvára sociálne prostredie. A preto tento typ manažéra aj poskytuje slobodu a vytvára dlhodobé vzťahy.

Často je tento spôsob manažmentu označovaný aj za japonský spôsob. Možno ste o takomto prístupe počuli aj v kórejských spoločnostiach, v ktorýcj je bežné, že zamestnanec pracuje vo svojej firme po celý život.

Agilné tímy fungujú dobre ak spolupracujú s manažérom Y. Pár tímov má šťastie na manažéra Z.

Manažér v agilnom tíme

Manažér môže tímu pomôcť:

  • Nastaviť tím na úspech. Predovšetkým na začiatku transformácie.
  • Byť servant leadrom.
  • Aplikovať Kaizen v bežnom živote.
  • Neriadiť priamo, ale vytvoriť podmienky pre úspech tímu.
  • Vytvoriť správne komunikačné rozhrania medzi tímom a organizáciou.
  • Pomáhať stanoviť hranice a pravidlá komunikácie.
  • Vytvárať dôveru v tíme aj v tím samotný.
  • Podporovať otvorenosť.
  • Byť koučom.
  • Pomáhať odstraňovať problémy tímu, ktoré nevie odstrániť.
  • Pomáhať rozvíjať agilnosť organizácie.
  • Zamerať sa viac na stratégiu, nie taktiku prístupu.
  • Motivácia tímu a oslava úspechu.

Konferencia CzechTest 2013

CzechTestV dňoch 21. a 22. marca 2013 sa v Prahe (Clarion Congress Hotel ****, Praha) uskutoční tretí ročník medzinárodnej konferencie CzechTest zameranej na testovanie softvéru a systémov. Ide o jedinú konferenciu svojho druhu na území Českej Republiky a Slovenska.

Program konferencie obsahuje množstvo prednášok, ktoré odprezentujú nielen skúsení profesionáli z “našich krajov” ale aj medzinárodne uznávaní zahraniční experti zvučných mien z oblasti testingu. Pod vedením niektorých z nich je možné deň pred konferenciou, 20. marca, absolvovať aj špeciálne tréningy (pre-conference tutorials) zamerané na získavanie a zlepšovanie praktických testovacích zručností.

Tom Gilb

Tom Gilb

Časť programu sa zaoberá agilnými prístupmi a medzi “ťahákov” konferencie patrí rozhodne Tom Gilb. Jeho koncpet EVO (Evolutionary Project Management), ktorý sformuloval ešte v 70-tych rokoch minulého storočia je považovaný za jeden zo základných kameňov na ktorých Agile staval.

Súčasťou konferencie je každoročne súťaž o zaujímavé ceny (napr. iPad), prezentácie hlavných sponzorov, predaj špecializovanej literatúry a stravovanie pre účastníkov priamo v hoteli.

Účastníci, ktorí sa prihásia do 20. februára získavajú zľavu 20% z registračného poplatku, držitelia certifikátu ISTQB získavajú takisto zľavu 20%, pričom tieto zľavy sa kumulujú.