Náš tým dokončil vývoj story. Kód je napsaný, review proběhlo, změna je nasazená do testovacího prostředí a QA začíná ověřovat acceptance criteria. Pak se ale objeví bug.
Na první pohled nic neobvyklého. Bugy k vývoji patří. Jenže problém začíná ve chvíli, kdy tento bug blokuje dokončení story, ale tým se k němu nechová jako k blokátoru dodávky. Bug zůstane někde v backlogu, někdo ho možná řeší, někdo na něj čeká, ale tým mezitím otevírá další práci.
A právě tady vzniká jeden z častých problémů agilních týmů: blokující bugy nejsou řízené jako skutečné blokátory flow.
Blokující bugy nejsou vedlejší práce
V mnoha týmech se bug nalezený během testování začne vnímat jako samostatný technický ticket. Je zapsaný v Jira, má prioritu, možná má assignee, možná má i odhad. Ale z pohledu řízení dodávky se ztratí jedna důležitá informace: tento bug blokuje dokončení konkrétní story.
Pokud story nemůže být akceptovaná, nemůže být dokončená. Pokud nemůže být dokončená, ovlivňuje sprintový závazek, plán, flow metriky i důvěru stakeholderů. Takový bug tedy není „další práce“. Je to překážka v toku hodnoty.
Bug zjištěný při testování, který blokuje dokončení sprintové story, má vyšší prioritu než začínání nové práce.
To je jednoduché pravidlo, které může výrazně změnit chování týmu. Ne proto, že by bugy byly důležitější než nové funkce. Ale proto, že rozpracovaná práce bez dokončení nepřináší hodnotu.
Typický vzorec: story stojí, ale tým jede dál
V praxi tento problém často vypadá nenápadně. Na Daily tým probírá jednotlivé tickety. Vývojář řekne, že story je hotová a čeká na QA. QA následně oznámí, že našlo bug. Bug je založený. Tým to vezme na vědomí. A pak se pozornost přesune na další story.
Jenže původní story zůstává otevřená. Není hotová, není akceptovaná. Přesto se tým chová, jako by práce pokračovala normálně.
Výsledek je často tento:
- ve sprintu roste rozpracovanost,
- několik story čeká na opravy,
- QA musí opakovaně retestovat,
- vývojáři přepínají kontext,
- na konci sprintu se dokončuje ve stresu,
- a část práce spillne do dalšího sprintu.
Na první pohled to může vypadat jako problém s kapacitou nebo odhady. Ve skutečnosti jde často o problém řízení flow. Podobně jako u agilního odhadování může být viditelný symptom jinde než skutečná příčina. Story nebyla nutně špatně odhadnutá. Možná jen tým včas nerozpoznal, že blokující bug je překážka dokončení.
Proč tým blokující bugy podceňuje
Nejčastěji to není tím, že by tým kvalitu ignoroval. Důvody bývají praktičtější:
- bug není jasně propojený se story, kterou blokuje,
- story není na boardu viditelně označená jako blokovaná,
- bug má vlastní prioritu, ale neukazuje dopad na sprint,
- Daily se vede jako status report, ne jako řízení toku práce,
- tým nemá dohodu, že blokátory dokončení mají přednost,
- QA a vývoj nejsou dostatečně propojené během sprintu,
- bugy se berou jako „práce navíc“, ne jako součást dokončení původní story.
To poslední je klíčové. Pokud bug vznikl při ověřování acceptance criteria dané story, není to oddělená práce. Je to stále součást cesty k dokončení story.
Definition of Done musí být tvrdší než dobrý pocit
Ve Scrumu pomáhá tuto situaci ukotvit Definition of Done. Scrum Guide říká, že práce nemůže být považována za součást inkrementu, pokud nesplňuje Definition of Done. Jinými slovy: pokud story blokuje známý bug, který brání akceptaci, story není hotová.
Definition of Done tedy nemá být formální seznam někde v Confluence. Má to být praktická dohoda týmu, která chrání kvalitu a transparentnost.
Do Definition of Done bych u podobného problému doplnil například toto pravidlo:
Story může být považovaná za dokončenou pouze tehdy, když jsou vyřešené a retestované všechny blokující bugy nalezené během testování této story.
Není cílem tvrdit, že v produktu nikdy nesmí existovat žádný známý defekt. To by u větších systémů nebylo realistické. Cílem je rozlišit mezi defektem, který nebrání dodání, a bugem, který přímo blokuje dokončení konkrétní sprintové story.
Dobré vysvětlení Definition of Done najdete také na Scrum.org, kde je zdůrazněno, že DoD vytváří sdílené porozumění tomu, jaké standardy musí práce splnit, aby mohla být považována za dokončenou.
Jak v Jira pracovat s blokujícími bugy
Základní pravidlo je jednoduché: pokud bug blokuje story, musí to být vidět přímo na story.
Prakticky to může znamenat:
- story má link is blocked by na příslušný bug,
- bug má link blocks na původní story,
- story je označená jako blocked,
- bug má vyplněné prostředí, kde byl nalezen,
- bug obsahuje jasný popis, jaké acceptance criterion nebo test blokuje,
- bug má vlastníka, který za jeho posun odpovídá,
- na boardu existuje pohled na story blokované bugy.
Atlassian ve svých materiálech k bug triage popisuje triage jako proces identifikace, sledování, prioritizace a řešení bugů. Pro agilní tým je ale důležité jít ještě o krok dál: neřešit pouze prioritu samotného bugu, ale také jeho dopad na flow a dokončení sprintové práce.
Pokud používáte Jira, může pomoci i jednoduchý filtr nebo dashboard. Například:
Sprint stories blocked by bugs
Takový pohled by měl ukazovat minimálně:
- blokovanou story,
- blokující bug,
- stav bugu,
- assignee,
- stáří blokace,
- případně sprint nebo plánované dokončení story.
Jde o jednoduchou věc, ale výrazně mění konverzaci. Tým už se neptá pouze „kdo na čem pracuje“, ale „co nám brání dokončit rozpracovanou práci“.
Daily musí začít otázkou, co blokuje dokončení
Pokud tým řeší dlouhé trvání bugů zjištěných při testech, často nestačí upravit prioritu v Jira. Je potřeba změnit i způsob, jak tým řídí práci každý den.
Na Daily bych doporučil pravidelně projít tyto otázky:
- Které story jsou nejblíže dokončení?
- Které story jsou blokované bugem?
- Kdo dnes řeší blokující bug?
- Potřebuje řešitel pomoc?
- Máme bug řešit swarmingem místo individuální práce?
- Je potřeba eskalace, rozhodnutí PO nebo podpora jiného týmu?
Velký rozdíl je mezi větou „bug je založený“ a větou „bug blokuje story, Petr ho řeší dnes dopoledne, pokud se neposune do 14:00, připojí se k němu Jana“.
První věta pouze popisuje stav. Druhá věta řídí flow.
Pravidlo: blokátory před novou prací
Jedna z nejúčinnějších týmových dohod může znít:
Než začneme novou story, ověříme, zda některá sprintová story není blokovaná bugem. Pokud ano, nejdříve rozhodneme, jak pomůžeme s odblokováním.
To neznamená, že všichni musí vždy okamžitě přestat pracovat. Znamená to, že tým vědomě rozhoduje. Pokud někdo začne novou práci, zatímco jiná story stojí kvůli blokačnímu bugu, mělo by to být vědomé rozhodnutí, ne náhoda.
Toto pravidlo pomáhá snížit WIP a podporuje dokončování. Právě WIP, cycle time a čekání jsou důležité signály, které se vyplatí sledovat v rámci flow metrik.
Ne každý bug je blokující bug
Aby tým neupadl do opačného extrému, je dobré jasně rozlišit typy bugů. Ne každý bug musí okamžitě zastavit sprint. Ale každý bug, který blokuje dokončení story, musí být viditelný a řízený.
| Typ bugu | Význam | Reakce týmu |
|---|---|---|
| Blocking bug | Brání dokončení sprintové story | Řešit před novou prací |
| Major test bug | Významně omezuje akceptaci, ale nemusí blokovat celou story | Viditelně sledovat a prioritizovat |
| Minor defect | Neohrožuje dokončení story | Zařadit do backlogu |
| Cosmetic issue | Nízký dopad na uživatele nebo hodnotu | Řešit podle priority produktu |
Tato klasifikace pomáhá Product Ownerovi, vývojářům i QA mluvit stejným jazykem. Neřešíme jen technickou závažnost. Řešíme také dopad na dodávku.
Měřte stáří blokace, ne počet bugů
Počet bugů může být užitečný, ale sám o sobě neříká, jak moc bugy brzdí dodávku. Jeden blokující bug může způsobit větší problém než deset drobných defektů v backlogu.
Proto bych sledoval hlavně tyto metriky:
- počet story blokovaných bugem,
- stáří nejstarší blokace,
- průměrné stáří blokujících bugů,
- čas od založení bugu do opravy,
- čas od opravy do retestu,
- počet story, které kvůli blokujícím bugům spillnuly do dalšího sprintu.
Tyto metriky nejsou určené k hledání viníka. Mají pomoct týmu lépe vidět, kde se práce zasekává. Pokud chcete měřit kvalitu bez toho, aby se z metrik stal nástroj kontroly lidí, může pomoct článek Metriky kvality: jak udržet rychlost bez zhoršení stability.
Praktická týmová dohoda
Pokud bych měl navrhnout jednoduchou working agreement pro tým, zněla by takto:
Když bug nalezený při QA blokuje story ve sprintu, okamžitě ho propojíme se story, označíme story jako blokovanou a bug bereme jako prioritní práci. Takové blokace řešíme na každém Daily dříve než novou práci. Pokud se blokace nehýbe jeden pracovní den, tým na ní začne spolupracovat nebo ji eskaluje.
Tato dohoda je jednoduchá, ale řeší několik problémů najednou:
- zvyšuje viditelnost blokované práce,
- zabraňuje tomu, aby bugy zapadly v backlogu,
- nutí tým dokončovat místo otevírání další práce,
- propojuje QA, vývoj a Product Ownera,
- a dělá z bugů součást řízení dodávky, ne separátní technickou agendu.
Jak to zavést bez velké procesní revoluce
Začal bych malým experimentem na dva až tři sprinty. Není potřeba hned měnit celý workflow, přestavovat Jira projekt nebo zavádět složitou triage komisi.
Stačí pět konkrétních kroků:
- Každý bug blokující story musí být propojený se story přes link.
- Blokovaná story musí být viditelně označená na boardu.
- Na Daily se nejdříve probírají blokované story.
- Bug blokující sprintovou story má přednost před začínáním nové práce.
- Na retrospektivě se vyhodnotí stáří blokací a dopad na dokončení sprintu.
Po dvou sprintech by měl tým vidět, zda se zkrátil čas řešení blokujících bugů, zda méně story zůstává otevřených na konci sprintu a zda se snížil stres kolem dokončování.
Otázky do retrospektivy
Pokud chcete téma otevřít na retrospektivě, neptejte se jen „proč jsme bug nevyřešili rychleji“. To může vést k obraně a hledání viníka.
Lepší otázky jsou:
- Které story byly tento sprint blokované bugem?
- Jak dlouho blokace trvala?
- Kdy jsme si poprvé uvědomili, že bug blokuje dodávku?
- Byla blokace viditelná na Daily?
- Začali jsme mezitím novou práci, i když stará nebyla dokončená?
- Co by nám pomohlo odblokovat podobnou situaci rychleji příště?
- Vznikl bug kvůli nejasným acceptance criteria, chybějícím testům, prostředí, datům nebo technickému dluhu?
Tím se konverzace posune od obviňování k učení. A právě to je smysl agilního zlepšování.
Shrnutí: blokující bugy jsou problém flow, ne jen kvality
Dlouhé řešení bugů zjištěných při testech není jen problém kvality. Je to problém toku práce. Pokud bug blokuje story, ale tým ho neřídí jako blokátor, vzniká falešný dojem pokroku. Lidé jsou vytížení, nové tickety se hýbou, ale hodnota se nedokončuje.
Agilní tým by se proto neměl ptát pouze: „Kolik máme bugů?“ Měl by se ptát:
Které bugy nám právě teď brání dokončit práci, kterou jsme se zavázali dodat?
Jakmile tým začne blokující bugy řídit tímto způsobem, často se změní i chování na Daily, práce QA, priority vývojářů a kvalita sprintového dokončování.
Není to velká metodická změna. Je to jednoduchá disciplína: vidět blokátory, řešit je včas a dokončovat práci dříve, než otevřeme další.
Chcete zjistit, proč se vašemu týmu práce zasekává?
Pokud ve vašem týmu opakovaně řešíte spillover, dlouhé dokončování story, narůstající bugy nebo nejasnou odpovědnost za kvalitu, může pomoct krátká diagnostika flow práce.
Podíváme se společně na to, kde se práce zasekává, jak tým pracuje s blokátory a které jednoduché změny mohou zlepšit dokončování bez zbytečné procesní režie.