Jak sprzątasz? O bugach i Backlogach

Bugi to naturalna sprawa. Niestety, nie da się ich całkowicie uniknąć. Czasami możemy mieć proces pierwszej klasy i produkować ich ledwie ociupinkę, ale najczęściej jednak produkujemy ich trochę więcej 😎 Każdy zespół ma swoje podejście do tego jak radzić sobie z błędami, gdy zostaną odkryte. Najczęściej nie ekscytują one programistów. Product Ownera czy Project Managera też nie. Raczej lądują w grupie “katorga”. Dużo rzadziej ktoś powie “ale wspaniały błąd, chcę to naprawiać” 🤪 Od tego już mały krok, aby zacząć je skrupulatnie kolekcjonować w backlogu i… zaczyna nam rosnąć niezły bałagan 😮

Bugi są trochę jak bałagan w naszych Backlogach właśnie – coś co trzeba posprzątać, prędzej czy później. Możemy działać tak, aby nasz backlog był schludny, czysty, poukładany i wolny od bugów. Po co? Abyśmy mogli skupić się na rzeczach nowych, nie przejmując się tym, że rośnie nam jakiś problem. Wystarczy… codziennie go sprzątać. To najlepsze podejście. Już wyjaśniam czemu i co mam konkretnie na myśli :) 

Bugi w backlogu, niby z priorytetem, ale…

Wyobraź sobie taką sytuację… Intencje zespół ma dobre – chce zdecydować czy dany bug ma duże znaczenie i wybrać świadomie co lepsze: jego naprawienie czy tworzenie nowego projektu, funkcji. Czas jest ograniczony, trzeba zdecydować co lepsze dla klientów, bo dwóch rzeczy się nie da zrobić. Nie rozdwoimy się. Z tego tytułu zespół decyduje “zostawmy to na później, wrócimy do tego w następnym Sprincie”. Początkowo każdy w to wierzy, że rzeczywiście wrócimy do tematu w następnym Sprincie. Jednak na kolejnym planowaniu, sytuacja się powtarza. Bo ciągle jest pełno fajnych, nowych rzeczy – o wyższym priorytecie. Backlog zaczyna zarastać bugami “na potem”. Liczba bugów zaczyna przytłaczać zespół i rośnie poczucie, że “nigdy tego wszystkie nie naprawimy”.  Błąd poczyniono, gdy pierwsze bugi odkładano na potem. 

W takich sytuacjach nierzadko słyszałem komentarz w stylu:“w sumie to naprawianie bugów nie ma sensu, bo przecież mamy ich już 112 w backlogu i nikt i tak o nie nie pyta”. A ilu klientów porzuciło stronę w wyniku takiego buga? Ciężko oszacować. Skoro można produkować tyle bugów, to po co w ogóle dbać o jakość? Jedziemy w dół z naszymi standardami. Może nawet przez to jesteśmy szybsi i z dumą mówimy “my szybko dostarczamy nowe projekty”. Tylko jakim kosztem?

Niektórzy mają tego dość i podejmują z werwą działania, które mają rozwiązać ten problem. Widzimy np. Product Ownera, który chce się zmierzyć z zabałaganionym Backlogiem – ocenia wszystkie bugi, poświęcając na to kilka godzin, decyduje o tym co powinno być naprawione, a co może niedziałające pozostać na produkcji. Priorytetyzuje te bugi, proponuje je na sprinty. No i zespół zaczyna z nich schodzić. Backlog wygląda lepiej. Czy jednak starczy tchu? Jeśli do tej pory bugi przyrastały w tempie X, to ile jesteśmy w stanie poświęcić na schodzenie ze starych + naprawiać nowe na bieżąco? X wystarczy tylko na pokrycie części.

Może rzucimy się na naprawianie bugów przez kolejne kilka sprintów, aby je wyzerować? „Zero nowości, tylko fixy”. I zaczniemy wszystko “od nowa”… 

A może w ogóle przepiszemy ten projekt…

A może po prostu wywalić wszystkie bugi z backlogu i “od jutra się przyłożymy?”. 

Czy za rok nie będziemy w podobnym miejscu? Bo procesy na co dzień nie działają. Bo nie sprzątamy regularnie. 

Najlepiej – naprawiać bugi przed produkcją, na jak najwcześniejszym etapie. Im później, tym więcej Cię to będzie kosztowało. Nawet 30 razy więcej – wg tego źródła. Niestety nie zawsze się da i bugi na produkcji się znajdą i wiele miesięcy po tym jak je stworzyliśmy. Co wtedy? Sprzątać codziennie. 

Zespół, u którego po raz pierwszy zobaczyłem jak naprawdę to można robić i jak dobre daje to skutki, w ramach każdego Daily przeglądał stan backlogu pod kątem ewentualnych błędów i innych rzeczy “niechcianych”. I każdego razu decydował co robić dalej ze sprawą – w 95% wciągał taki defekt do aktualnego Sprintu. W 5% przypadku zostawiał to na kolejny Sprint. Efekt? Czysto. Jeśli można mówić o jakimś bałaganie, to tylko o takim, który był akceptowany i wiedzieliśmy, że w ciągu kilku dni go usuniemy.

🤔 Co można zrobić, gdy jednak pozwoliliśmy sobie na to, aby nasz Backlog zarósł już błędami? 

Zanim zdecydujemy się na “zaczęcie od nowa” lub przejrzenie Backlogu, ustalmy najpierw reguły gry i standardy postępowania z bugami. Bo inaczej nasz wysiłek pójdzie na marne. Gdy będziemy mieli ustalone, że sprzątamy codziennie i kilka innych procesów, to decyzja o tym “co ze starymi bugami?” będzie już kwestią drugorzędną. Najważniejsze jest zdecydowane działanie i konsekwencja.  

Takie podejście – czyszczenie backlogu codziennie – ma jeszcze jedną korzyść. Powoduje, że ciężar tych wszelkich niechcianych rzeczy jest dużo mniejszy. Gdy sprzątamy codziennie, to mamy dużo mniej do ogarnięcia na raz. Koszty zarządzania takimi backlogiem są mniejsze. Konsekwencje dla klientów także 🤓 

Reguły i wyjątki

Od wszystkich reguł są wyjątki. Od tej także 🤫 Przykładem niech będzie inny zespół, który każdy błąd rozważał pod kilkoma kątami:

• Jak uciążliwe jest to dla naszych klientów?
• Jak wielu z nich może to dotyczyć?
• Czy pozostawienie tego w takim stanie ma duże konsekwencje techniczne (dług)?’
• Jaki jest koszt naprawy teraz, a jaki może być później?

Każdy defekt rozpatrywano pod tymi kątami i decydowano co dalej. Bardzo często trafiał do jednego z najbliższych Sprintów. Nierzadko jednak  był usuwany po prostu z backlogu. Nie chodziło o to, żeby rzecz “schować pod dywan”. Chodziło o to, że świadomie decydowano o tym, że błąd nie będzie naprawiany.

Jak widzisz, zespół ten miał trochę bardziej pokręcone podejście do sprawy niż ten z pierwszego przykładu, ale bardzo rzetelne i świadome. Świadome zaciąganie długu 😎 Ryzykowne niekiedy, owszem. Dlatego nie każdemu poleciłbym tę ścieżkę. W przypadku tego zespołu i produktu, sprawdzało się bardzo dobrze, ale przyznaję, że było to ryzykowne podejście.  

Podsumowanie

Pisałem przede wszystkim o bugach, ale tak naprawdę to podejście można zastosować do wszystkich rzeczy, które znajdziesz w backlogu (np. nowe funkcje, zadania techniczne, aktualizacja wersji biblioteki). Zachęcam Cię do codziennego sprzątania Backlogu. To kwestia higieny – zęby szorujemy codziennie, m.in. po to, aby nie musieć instalować nowych 😉 Dlaczego nie moglibyśmy tak samo potraktować naszych produktów? 

Dodatkowa lektura

Polecam Ci także te dwa artykuły na temat dbania o swój kod, które mogą Cię zainspirować do zgłębiania tematu defektów jeszcze bardziej:

1: The ONE chart every developer MUST understand

2: Exponential cost of fixing bugs

Więcej dobrych treści – do Twojej skrzynki @

Zapisz się na newsletter, korzystając z poniższego formularza

Znam Politykę Prywatności i zgadzam się na jej warunki

Leave this field empty if you’re human: