Jistě jste během vaší kariéry narazili na mnoho různých přístupů, jak se postavit k bugům.
Pamatuji si, že v Systinetu jsme měli na té naší komponentě stovky reportovaných bugů. Releasovalo se tehdy těch sedm či osm let dozadu jednou za pár měsíců. Tehdy jsme se vypořádávali s bugy prioritou. Release šel ven jen tehdy, když nebyly reportované žádné P1 — urgent či critical ani P2 — užaninevimcotobylo :-)
Na Service Virtualization jsme těch bugů v QC měli také hromadu, ale nebylo to tak kritické. Mimochodem, na Quality center jsme měli tehdy lightweight Bugzilla interface, protože tehdejší QC moloch stahoval stovky megabajtů do browseru při spuštění, aby se vůbec načetla celá stránka. Díky Mafry. Člověk si to už ani nedokáže představit.
V Liftagu je nás trošku méně, releasujeme do produkce několikrát týdně. Představa stovek červených bugů v Jiře nás nelákala. Také se musíme otáčet. Nějaké simple silver-bullet pravidlo by se nám hodilo. Vyříkávat si neustále s PM či někým dalším, zda to opravdu je bug, či není, je zdlouhavé.
Bylo nutné oddělit zrno od plev. Říct si ano či ne velmi rychle. Vždy je málo času, a tak prioritizovat bugy vůči featurám je cesta do pekel.
Co nám pomohlo?
Zero bug policy?
Je to jednoduché flow, jak se vypořádat s bugy. Mým zdrojem celé realizace byl tehdy tento článek.
Přístup má vlastně pouze dvě pravidla:
- Bugy fixujete hned, a nebo maximálně příští sprint. Nedávát je nikdy dál.
- Bug je něco, s čím nedokážete dále žít a je nutné jej opravit.
Někteří z vás se určitě od začátku smějí, že mít nula reportovaných bugů není možné. Máte jich přece stovky.
Zásadní je zvládnout dobře druhé pravidlo. Je reportované issue opravdu bug hodný fixnutí a nebo je pouze nějaká nice-to-have nová featura, kterou někdo z XYZ považuje za nutnou?
Pomohl nám rozhodovací strom z obrázku:
- Nejde spustit appku v produkci? Zákazník nemůže na platební bráně zaplatit? Nejde vyhledávat v mapách? Pokud leží překážka na kritické cestě appkou, všeho necháváme a celý team se soustředí na fix produkční issue. Ztrácíme totiž peníze, zákaznickou loajalitu.
- Něco nefunguje? Neexistuje workaround? Nedokážeme s tím issue dál žít? Oukej, je to bug, fixujeme příští sprint.
- Něco nefunguje? Jo ono to nefunguje už tři roky? Je to něco, s čím dokážeme žít, protože existuje snadný workaround? Bug v Jiře přehazujeme na user story a dále normálně prioritizujeme jako featuru s produktem. Pokud totiž dokážeme žít se současným řešením, issue je ve skutečnosti improvement současného chování, ne chyba.
- Bylo by lepší, kdyby to takhle fungovalo? Napadá mě, že by to takhle bylo lepší? Tak to je nová featura. Chováme se k ní jako v bodu tři.
Jak jsme postupovali ve třech krocích
Na začátku jsme udělali experiment. Řekli si, že do toho jdeme a uvidíme. Přinejhorším to zase zrušíme.
1. Triage bugů
Pokud máte hromadu bugů, nejprve je potřeba je projít a přehodit ne-bugy na user-stories nebo cokoliv, co používáte. Chce to pár hodin času, pevnou ruku a nebát se přehazovat či dokonce zavírat.
Následující obrázek je historie našich bugů v Jiře. Je tam vidět ten prvotní náběh v červnu 2016. V lednu 2017 jsme se rozhodli, že žádné bugy a tak to žuchlo na zhruba polovinu.
2. Zvládnutí zbylé kupy bugů
Pokud jste jich měli opravdu hodně, hodně vám také zbyde. Důležité je udělat plán, jak se dostanete k nule. Je vše třeba vysvětlit managementu, vzít si na to čas. Málokdy se vám stane, že můžete zastavit vývoj nových věcí, abyste pár týdnů pouze fixovali.
Důležité je dostat se během rozumné doby na nulu.
Na našem grafu je vidět, že správná implementace zero bug policy nám trvala zhruba od půlky roku 2017 do prosince.
Jsou tam také vidět dva peaky. To je čas, kdy si vzal Honza Android a pak iOS appku do pucu. Na začátku nareportoval hromadu issues. Ve druhém případě iOS jsme si s Honzou domluvili plán, že se do pár měsíců zbavíme iOS bugů. Tenhle plán jsme probrali i s produktem, aby také počítali s tím, že nedokážeme udělat tolik nových věcí v appce.
Buďme realističtí.
3. Udržení pozitivní nuly
Celý princip funguje jen tehdy, pokud se někdy dostanete shora k nule a tu nulu udržíte.
Lidská mentalita funguje tak, že když pošlete jeden, dva či tři bugy dál s tím, že je ofixujete později, je to jako kdybyste jich tam poslali hned padesát.
Team vám pak nebude věřit váš záměr a systematicky začnou všichni toto pravidlo porušovat.
Na grafu je to ta pila. Tu chcete. Ukazuje, že reportované bugy stíháte fixovat. U nás se držíme zhruba kolem 10 či 15 bugů, které se nám daří další sprint zavřít.
Jak se nám to daří?
Ve své podstatě stačí projít úspěšně třemi popsanými kroky a na konci držet pilu. Jira sama vám umí zobrazit graf created/resolved issues, takže to můžete sledovat na jakékoliv časové úrovni velmi snadno.
Tohle pravidlo nám pomohlo zjednodušit přístup a rozhodování s bugy, kdy výjimečně probíráme prioritu déle než bychom si všichni přáli.
Od té doby se cítí všichni na poli bugů dobře, protože máme pravidlo, které je jasné a deterministické, a zároveň vede k udržitelnému provozování platformy 24/7.