O čem bude řeč

Firem a týmů, které přešly na agilní vývoj, stále přibývá. A to je dobře! Agilní vývoj může spoustě firmám pomoci – ale ne každé a také se musí dělat správně. Zajistit kvalitu v agilním prostředí je často velkým oříškem pro mnoho firem. Setkávám se s tím dnes a denně na svých kurzech i konzultacích. A tak jsem se rozhodl, že základní principy objasním v tomto článku. Cílem článku tedy je vysvětlit, co je agilní vývoj, vysvětlit co je agilní testování a jak se provádí. Jak říká Simon Sinek: začneme s proč. 😀

Proč se bavíme o agilním testování

Svět se změnil! Rychlost, s jakou se nám mění technologie i požadavky, nabrala tak na obrátkách, že již není možné plánovat na jeden rok, co se bude vyvíjet. Je potřeba to dělat častěji, třeba každých čtrnáct dní (tzv. Sprint). Agilní vývoj přišel s řešením jak zajistit vývoj, který bude iterativní a inkrementální, a tedy bude řešit problém rychlých změn a také to, že management/byznys neví, co přesně trh nebo zákazník potřebuje. On to často neví ani sám zákazník… 😉 Ale to nevadí, pokud máte možnost po každém Sprintu předvést zákazníkovi, co za nové featury (funkce) dostal, a on si je může rovnou vyzkoušet a zjistit, jestli to je to, co potřebuje. Díky tomu se nevyvíjí naslepo, ale vše je ihned prověřeno v reálném provozu. A jak s tím souvisí agilní testování? Agilní testování je způsob, jakým zajistit kvalitu právě v agilním vývoji. Protože nejčastější formou agilního vývoje je použití SCRUM frameworku. Budeme se dále bavit především o něm, i když většina principů je univerzálních a dají se použít v jakémkoliv agilním vývoji.

Co je agilní vývoj (Scrum)

Slovo SCRUM pochází z ragby a znamená tu „skrumáž“ hráčů při vhazování míče. Všichni jsou do sebe zakleslí a působí jeden na druhého, někteří táhnou spolu, někdy proti sobě. Stejně tak ve vývoji formou Scrumu je zásadní tým. Tým je složen z členů, kteří mají různé role. Nejdřív si představíme Product Ownera (PO). Jeho úkolem je vědět, co zákazník potřebuje, a přináší tyto informace do týmu. Jeho druhou nejdůležitější úlohou je stanovovat priority požadavkům, které se vyvíjejí (tzv. user story). Druhou rolí je Scrum Master (SM). Toho si můžete nejlépe představit jako takového týmového kouče. Jeho úkolem je zajistit, aby tým pracoval efektivně. Tedy např. sledoval, jaká je aktuální efektivita týmu, a zjišťoval, jak ji tým může zlepšit. Nedělá to ale formou direktivních nařízení ale koučováním. Další úlohou SM je odstraňovat překážky (tzv. impedimenty), které brání ve vývoji nebo v práci členům týmu. A nejdůležitější rolí jsou samozřejmě samotní členové týmu. Scrumové týmy bývají tzv cross-functional, tedy jsou sestaveny ze všech členů potřebných k tomu, aby se zákazníkovi mohla dodat část softwaru, která mu k něčemu podstatnému je (tzv. product increment). Jsou to tedy typicky vývojáři, testeři, analytici, devops specialisté, architekti, UX designeři atd.

Všichni tito členové včetně SM a PO se scházejí na společných mítinzích:

Backlog grooming
- Zde vám PO představí, co zákazník chce, ve formě user storek – ty musí byt dostatečně malé, aby se daly realizovat během 2-4 dní (pro 14-ti denní Sprint). Protože často nejsou, řeší se na tomto mítingu, jak je rozdělit na menší. Dále se dělá effort estimation (většinou formou tzv. Planning Pokeru).
- Cílem mítingu je tedy mít malé UST (User Story) seřazené v Backlogu (místo, kde jsou všechny požadavky) podle priority.
Sprint Planning
- Cílem tohoto mítingu je aby tým naplánoval, co vše se bude v následujícím sprintu dělat, tedy které všechny user story se budou implementovat, testovat a ideálně i releasovat.
- Postupuje se v backlogu od té nejprioritnější UST dále k méně prioritním, dokud má tým kapacitu, aby UST stihl dokončit.
Daily scrum (dříve označován jako Stand up)
- Jakmile je naplánováno, mohou se všichni pustit do práce a každý den se sejdou na Daliy scrumu, který trvá max. 15 min a každý zde odpovídá na 3 otázky: Co jsem dělal včera. Co budu dělat dnes a co mě blokuje. Tohle je signál pro SM, aby zajistil, že překážky budou odstraněny. (pozn: tohle je jeden z možných formátů)
Sprint Review (dříve označován jako Demo)
- Jakmile Sprint doběhne (typická délka je 14 dní), svolá se Sprint Review meeting, kde se předvede zákazníkovi, co se udělalo. A on nám na to hned dává externí zpětnou vazbu, jak se mu to líbí a jestli to je to, co potřebuje.
Retrospektiva
- Aby se tým mohl zlepšovat, potřebuje také vnitřní zpětnou vazbu. Ta se koná na Retrospektivě. Zde se opět všichni sejdou a v základu odpovídají na 2 otázky: Co se mi na Sprintu líbilo (a chci zachovat) a co se mi naopak nelíbilo (a chci, aby se změnilo, přestalo).