De-bug-ize! Ako plánovať opravu chyby v Scrum

Trápia vás chyby produktu? V článku sa dozviete aké praktické možnosti máte v agilnych tímoch pri manažovaní opráv chýb. 

Jednou z prvých otázok pri zavádzaní agile je ako pracovať s chybami. Až príliš často počujem vzápätí aj odpoveď.

„Agile je pre opravu chýb nevhodné, nezmysel, nedá sa, nechce sa“.

V skutočnosti možností je viac než dosť.  Len pre poriadok, budeme sa baviť o chybách, ktoré prišli z predchádzajúcich dodávok produktu. Chyby nájdené v aktuálnom sprinte sa majú opraviť okamžite. V tomto prípade je to podúloha User story v danom sprinte.

A: Bugs Backlog

Produktový​ vlastník eviduje business požiadavky v produktovom backlogu a chyby ostávajú na inej kope. V backlogu bugov, napr. Bugzilla, Mantis, alebo iný bug tracking tool.

Výhodou pre klientov je možnosť pokračovať s existujúcimi nástrojmi a možnosť oddelenej priorizácie chýb.

Nevýhodou je práve práca s viacerými backlogmi. Produktový vlastník stráca prehľad o prioritách.

Takto opravu chýb nikdy neriešte!

B: Reakcia

Keď sa objaví chyba, produktový vlastník ju zaradí do sprintu. Má mať snahu je najskôr odložiť ďalej, nie do aktuálneho sprintu. Ak sa nedá, tak sa nedá. Zaradí ju ale iba s vedomím tímu.

Najlepšie bude ak sa tím pokúsi ohodnotiť náročnosť opravy, aby produktový vlastník mal predstavu a vedel podľa toho meniť priority.

Tímy najčastejšie začínajú s tzv. fast lane, teda oblasťou na kanban board vyhradenou pre neplánované aktivity. Na začiatku je fast lane typicky 20% kapacity tímu. Hodnota sa mení v závislosti od aktuálnej situácie, napr. po deploy novej verzie to môže byť aj viac ak tím očakáva viacero chýb.

Takýchto riadkov na tabuli (swimlanes) môže byť aj viacero. Kanban to definuje ako Class of work. A taká Expedite sa rieši okamžite, zatiaľ čo iné, napr. s fixným dátumom v nižšej priorite.

Pozn. Poriadny fail keď očakávame chyby po deploy :(.

Nevýhodou tohto prístupu je, že nastáva často potreba zodpovedať otázku či sme ešte vo fast lane, alebo sme ju prekročili. Často scrummaster vedie ďalšiu ideálnu  čiaru na burndown grafe. Jednu pre celkovú kapacitu, jednu pre kapacitu bez fast lane. Reálna čiara by mala lietať medzi nimi. Scrum project management nástroje takéto niečo nepodporujú.

Ďalšou nevýhodou je, že zákazníci, stakeholderi,  majú pocit, že bude dodané všetko, čo v prípade mnohých chýb nemusí byť pravdou.

Výhodou je rýchly štart so Scrum v novom tíme, možnosť reakcie na chyby, prehľad o množstve pridávaných chýb, ľahké meranie počtu a prispôsobenie sa v ďalších sprintoch.

C: Naplnená fľaša

Druhou možnosťou, ktorú osobne preferujem, je naplánovať sprint naplno. Na kapacitu tímu, ktorú je tím schopný dokončiť. Podľa velocity.

Keď sa ako Product owner rozhodnem pre opravu, prídem za tímom a spýtam sa ich či je možné chybu opraviť v aktuálnom šprinte. Ak áno, tím skúsi odhadnúť opravu. Na základe odhadu potom ako produktový vlastník odoberiem rovnakú komplexnosť zo sprintu. Od konca šprint backlogu, najmenej dôležité.

Výhodou je, že to bolí. Ak niečo pridávam, nebudem niečo iné mať. Musím priorizovať, čo je oveľa dôležitejšie a čo nie. V tomto svetle už často chyba nie je tak prioritná. Tím sa musí nad ňou tiež zamyslieť, pri tomto sa tiež často ukáže skutočná dôležitosť. Aby som ich nerusil zakaždým, často ich prinášam na daily stand-up. Pokiaľ nehorí, nedýcha, nefunguje.

Ďalšou výhodou je, že chybu dávam do poradia v porovnaní s kartami, ktoré už sú v šprinte. Priorizujem.

Výhoda. Burndown graf zobrazuje neustále aktuálnu zostávajúcu prácu. Stačí mi jedna čiara a viem kde sme.

Nevýhodou je, že na konci sprintu mám iný scope ako som si plánoval. Ale keďže to robím ja ako PO, presne viem prečo a čo bolo odsunut.

D: Bugy kanbanéro

Nuž niekedy nastane aj kríza a vám neostáva nič iné iba zrušiť obsah sprintu a v šprinte prejsť do Kanban režimu. Produktový vlastník denne pridáva a priorizuje, tím opravuje iba podľa poradia. Neplánujeme šprint, ale meriame a vyhodnocujeme stav. Či už s burn down grafom, alebo cumulative flow chart.

Ako riešime chyby v ScrumDesku?

ScrumDesk, náš scrum project management nástroj, napr. vyvíjame spôsobom č. 1 a 2. Skombinovali sme viaceré, pretože u nás je sprint oveľa dynamickejší než sa možno zdá. V podstate už fungujeme Kanbanom, kedy priority na 3 týždne vopred sa síce dajú určiť, ale často sa menia kvôli obchodu. Snažíme sa mať statický aspoň týždenný interval.

V prípade chýb náš proces je takýto:

• Important Bugs je riadok, v ktorom máme všetky dôležité a urgentné chyby. Tie, ktoré ovplyvňujú viacerých klientov a navyše sú kritické, bránia používaniu produktu.
• Ďalší riadok Bugs#26 obsahuje chyby, ktorých oprava bola naplánová pre Sprint č. 26.

Chyby u nás už nerozbíjame na menšie podúlohy, oprava je väčšinou rýchla, max. 1 deň. A preto nám stačí jedna karta. Ale pozor, sú v nej zahrnuté aj testy, atď.

Princípy

Proaktívne namiesto reaktívne

Najdôležitejšie je prejsť z režimu reakcie na objavenie sa chyby na plánovanie opráv chýb.

Začnite tým, že zmažete/uzavriete všetky chyby staršie ako 1-3 mesiace. Vážne! Nebojte sa, sú tí staré chyby, ktoré užz možno ani chybami nie sú, keďže kód sa medzitým už zmenil, alebo človek už nie je v práci, alebo si to málokto pamätá. Ak to je stále chybou, objaví sa opäť.

Hľadajte korene problémov

Prečo máte chyby v kóde? V ktorej časti? Koľko? Aké sú dôležité? Aké majú finančné dopady? Aké náklady môžu ušetriť?

Možno budete musieť kvôli tomu zapnúť meranie kód coverage, ak máte testy. Ak nemáte, tak analyzujte.

V ScrumDesk to robíme s RCADesk, ktorý umožní zmapovať problém, rozbiť ho na menšie, identifikovať príčiny a zaevidovať akčné kroky čo forme grafu, modifikovanej mind mapy.

Urgentné neznamená dôležité

Keď sa objaví chyba, snažím sa ju odložiť na neskôr. Často klient môže počkať, stačí len komunikovať.

Berieme do úvahy viac dôležitosť než urgentnosť​ chyby.

1. Dôležité a urgentné chyby opraviť ako prvé.
2. Dôležité a neurgentné ako druhé.
3. Nedoležité a urgentné ako tretie.
4. Nedoležité a neurgentné. Neopravovať?

Nerobiť chyby

Sci-fi? Určite to nebude na 100%, ale za pokus a investíciu to stojí.

Už len možnosť, že sa zaoberám chybami však môže vytvárať pocit, že to „nejak“ poriešime keď to nastane.

Byť Scrummaster, pozorujeme takéto správanie sa tímu. Signály.

Ako teda znížiť riziko chybovosti? Agile poskytuje veľmi veľa nástrojov a praktik:

• Definition of Ready, aby poziadavky mali všetky potrebné informácie a tím dodal to čo je potrebné.
• Readiness indikátor pre každú požiadavku, aby Product owner vedel či spravil dobrú robotu pri príprave a skoro boli indikovane prípadné nezrovnalosti a stále mal čas ich doplniť.
• Pravidelný sprint preplannig, kde sa to dozvie.
• Code review, povinný. Vždy a všade a zakaždým. Striedať sa pri review, nepripomienkovat stále rovnaké oblasti kódu.
• Párove programovanie. Špeciálne v najkomplexnejších častiach.
• Automatizované testovanie. Bodka.
• Poriadne regresné testy. Rýchle aj podrobné, rôzne test suites.
• Pravidlá písania kódu. Staré, ale dobré.
• Statická analýza kódu. Do trunku bez warningu!

Čo na záver?

Chyby nájdené v sprinte opraviť hneď. Iné chyby zhodnotiť s porovnaním dôležitosti a urgentnosti. Dôležité je dôležitejšie. Porovnať prioritu chyby s obsahom aktuálneho sprintu. Snažiť sa ju radšej plánovať do ďalšieho sprintu. Nerušiť scope sprintu.

Ak sa nedá, tak prekonzultovat ju s tímom, odhadnúť opravu a zaradiť na správne miesto v sprinte. V ScrumDesk ju dávame vždy do prvého riadku tabule, aby sme ju vyriešili čo najskôr a mali tak priestor pre pôvodne plánované požiadavky.

A či to máte robiť rovnako? Je toto najlepší postup? Neviem či pre vás. Tak si to premyslite, pretože agilne znamená prispôsobivo.