Jedním z častých dotazů, které dostávám, je jak řešit ve Scrumu chyby. Je lepší mít separátní tým na chyby a separátní tým na nový development, nebo cross-functional týmy co pracují na tom, co je zrovna potřeba, tedy chybách i nových funkcionalitách. Odpověď je snadná. Scrum optimalizuje business value. Definuje proto týmy jako cross-functional, které dokáží udělat jakoukoli změnu produktu, co přináší business value. Tedy chceme tým (týmy) co pracují na tom, co je zrovna v produktu potřeba. Ať už je to chyba, nebo nová feature.
První, co je třeba si uvědomit je, že chyba je zase jen změna funkcionality, takže není sebemenší důvod, proč by chyby nemohly jít do Backlogu jako jakékoli jiné věci, které chcete ve vašem produktu změnit. Jsou to prostě obyčejné položky Backlogu, které by měl Product Owner prioritizovat podle business value. Když dám příklad, představte si, že máte hru, kde si hráči můžou nastavovat vlastní avatary. A jedním z možných nastavení je i barva vlasů. A co čert nechtěl, pokaždé když se odhlásíte, váš avatar barvu vlasů ztratí a je zase blond. Otrava, že? Jasná chyba, řekli byste. Takže ji musíme dát do Backlogu a opravit. Dokonce na to klidně můžete použít formát User Story a napsat:
Jako hráč,
chci, aby si můj avatar pamatoval barvu vlasů,
abych ji nemusel nastavovat pokaždé znova.
Když to uděláte, stane se zajímavá věc. Z něčeho co se musí opravit, se stane něco, co má business value (abych ji nemusel nastavovat pokaždé znova) a lze prioritizovat relativně vzhledem k ostatním položkám Product Backlogu. V tomto konkrétním případě nás to donutí zjistit, kolik hráčů tuto funkcionalitu s chybou kdy použilo, ale hlavně kolika z nich vadilo, že se přes noc stali blond. A když zjistíte, že existuje jediný hráč, kterému vadí, že nemá barevné vlasy, tak možná položka do Backlogu bude úplně jiná a bude naopak znamenat odstranění funkcionality jako takové.
Co když ale chyba není takhle nedůležitá, ale je kritická? Stojí vám produkce, uživatelé nemůžou produkt používat? No tak ji opravte. Že vám to narušuje Sprint? Je to výjimečná situace, a výjimky se dějí. Když celý tým onemocní, taky to berete jako výjimku a moc to neřešíte. Je třeba si uvědomit, na co klademe důraz. V tradičním světě waterfallu bylo hlavní chybu co nejrychleji opravit. Tím jsme problém považovali za vyřešený. V Agilním světě ji opravíme, a klidně i hned jestli je tak kritická, že nepočká do dalšího Sprintu. Pak si odpočineme, a zamyslíme se, co uděláme příště pro to, aby se nám to už nestalo. Najdeme rootcause, změníme své procesy, refactorujeme, prostě uděláme cokoli, aby se takovéhle kritické chyby neobjevovaly, a ty, které nám přeci jen utečou, jsme mohli v pohodě považovat za výjimky. Protože výjimečné věci se dějí výjimečně, moc nám nevadí. Dokážeme se z toho otřepat. Stejně jako když celý tým onemocní. Naopak obvyklé věci se dějí obvykle a mohou být pěkně vyčerpávající.
