poznáme.itAgileJak jsme zrušili QA…

Jak jsme zrušili QA…

Jak jsme zrušili QA… 2

Před nějakou dobou jsme v týmu řešili nespokojenost s tím, že nejsme dlouhodobě schopni dokončit to, co si naplánujeme. Sprinty ve Scrumu nám prostě nefungovaly. Těch důvodů bylo několik:

  • přílišný optimismus (známá nemoc odhadů)
  • nepředvídatelný support (je nám jedno, že máte plány, musí se to hned vyřešit!)
  • hromadění tasků ve frontě QA (celý sprint nic, na konci sprintu všichni chtějí odevzdávat)

Co s tím?

Přešli jsme ze Scrumu na Kanban. Tenhle experiment jsme si museli ve firmě trochu protlačit. Byli jsme tak trochu pionýři. Všechny týmy v té době pracovaly ve Scrumu. V rámci firmy bylo všechno sladěné – metodika napsaná na Scrum, work-flow v JIRA nastavené na Scrum, existovaly společně datované releasy následující po stejně datovaných sprintech, existovali sdílení Scrum masteři atd.

Nakonec jsme si ten Kanban prostě jako z prvních týmů vybojovali. Prošlo nám to i díky Jirkovi, který je Head of development a nakonec nás ve změně podpořil. Přechod na Kanban nám opravdu pomohl.

Ukázalo se, že dodržováním zásady Kanbanu Limited WIP (work in progress) tým nastartoval udržitelný předvídatelný rytmus a odstranil také problémy s přetahováním tasků mezi sprinty.

Zrušení pevně stanovených dní na hodnocení tasků do nových sprintů vedlo k tomu, že dnes děláme Estimation ad hoc. Třeba hned, třeba za hodinu., prostě když nám to dává smysl. Odpadá tak stres, že musíme rychle kouknout na nově zadané tasky, pro které máme za chvíli hodnotit jejich složitost a velikost. Nyní hodnotíme, když jsme připravení.

V okamžiku přechodu na Kanban jsem si dovolil prosadil ještě jednu změnu. Chtěl jsem, abychom v nově nastaveném work-flow zrušili fázi QA (quality assurance). Fáze QA následovala po fázi Engineering. Stav QA tedy reprezentoval situaci, kdy vývojář dopsal kód a s odpuštěním hodil výsledek na testera k ověření, jestli jeho práce funguje dle očekávání.

V týmu jsme měli čtyři vývojáře a jednoho dedikovaného testera. Musím říct, že si dodnes pamatuji moment, jak se vývojáři ani tester při představení nového procesu na novinku nadšeně netvářili. Četl jsem jim ve tvářích — Co si to vymýšlí? Proč rušit stav, ve kterém se řeší kvalita? Zkrátka Co blbne?

Změnou jsem spojil fáze Engineering a QA dohromady. Trval jsem totiž na následujícím pravidle.

Kvalita za dodaný task je odpovědností přiřazeného vývojáře.

Bylo potřeba týmu změnu samozřejmě vysvětlit a podporovat je v prvních krůčcích bez QA. Po krátkém čase 2–3 týdnů se však nový vzor chování stal normou. Až mě překvapilo, jak to šlo hladce.

Task pro vývojáře v našem týmu nyní již nekončí přehozením zdánlivě dokončeného tasku na testera. Platí železné pravidlo:

Dokud není celý task otestovaný, není dokončený. Je zodpovědností developera, že task dokončí a nerozpracuje druhý, nebo nedej bože třetí a čtvrtý.

A protože jeden tester v týmu bylo vzácné zboží, vedla nově nastavená pravidla k tomu, že si vývojáři začali mnohem více testovat tasky mezi sebou navzájem. Pokud chtěli vývojáři začít pracovat na novém tasku, museli starý task dokončit. Vývojáři se přizpůsobili. Limited WIP nedovolal otevírat další tasky.

Od začátku nám hodně pomáhá vizualizace celého procesu. KANBAN board vytvořený v JIRA máme neustále zobrazený na týmové televizi. Dovolím si odbočku a pochválím našeho Head of Development. Má JIRA customizace opravdu perfektně zmáknuté a je pravdou, že jeho úpravy týmům u nás ve firmě hodně pomáhají.

Na první zhlédnutí našeho boardu je každému z týmu jasné:

  • Kdo má rozpracované jaký task.
  • Jaké testy jsou pro dokončení tastku vyžadovány a jestli jsou již napsány.
  • Co máme hotovo. Co lze připravit. Co si lze vzít a začít na tom pracovat.
  • Co je BUG (červená karta) a co je nová User story (zelená karta).
  • Jak rychle dodáváme.
  • Kde co a jak dlouho drhne.
  • Jaké nám padají automatické testy

Dovolil jsem si náš KANBAN board částečně screenshotnout. Obrázek, který vidíte, zobrazuje aktuální časový snímek. Jsou na něm zobrazeny nejenom jednotlivé fáze a tasky, ale i další informace jako jsou story pointy, doba trvání tasku atd. Krásně je vidět fáze Engineering, která předchází fázi Done. Není nic mezi. Žádné QA.

Jak jsme zrušili QA… 4

Nově nastalá situace také ulevila testerovi. Mohlo by se zdát, že nebude mít co dělat. Naopak! Konečně se mohl zplna vrhnout na automatické testy, které nám v mnoha oblastech chyběly.

Koneckonců dnes už ani testera nemáme. Nikomu extra fáze QA ve výrobním work-flow nechybí. Celkově tým zrychlil. Máme více automatických testů (unit testů, GUI testů) a testování navzájem mezi vývojáři je přirozenou součástí denní práce.

Z dlouhodobého hlediska se v našem týmu se začlenění fáze QA do Engineeringu určitě vyplatilo.

Jak jsme zrušili QA… 6

A jak to máte vy? Zajímalo by mě, jestli se perete s podobnými problémy a jak jste je vyřešili?

Jo a dovětek: Kdybyste chtěli vědět proč preferuju ten Kanban. Výborný článek od Rika Highama.

Článok je pôvodne uverejnený na Mirovom blogu a s jeho dovolením aj na blogu robime.it.

Dobrý článok? Chceš dostávať ďalšie?

Už viac ako 6 200 ITečkárov dostáva správy e-mailom. Nemusíš sa báť, nie každé ráno. Len občasne.

Súhlasím so spracovaním mojich osobných údajov. ( Viac informácií. )

Tvoj email neposkytneme 3tím stranám. Posielame naňho len informácie z robime.it. Kedykoľvek sa môžeš odhlásiť.

Miroslav Zebrák
Miroslav Zebrákhttps://medium.com/@zebrakm
Jsem produktovým manažerem v LMC s.r.o, kde více jak 6 let denně vylepšuju produkty pro personalisty. Před příchodem do LMC jsem 4 roky pracoval v KOMIX s.r.o. jako CRM konzultant. Působil jsem i na Fakultě podnikohospodářské VŠE v Praze, kde jsem byl garantem kurzu Řízení vztahů se zákazníky. Zajímám se o technologické novinky a trendy. Jsem fanouškem sci-fi.

Čítaj ďalej: