Bugi (błędy, defekty), to nieodłączna część naszej rzeczywistości. Niestety, raczej ta nieprzyjemna. Większość z nas woli skupić się na dostarczaniu nowej wartości dla klienta – to jest w końcu to co pcha nasze produkty do przodu. W celu oswojenia tej nieprzyjemnej części, nierzadko próbujemy szacować rozmiar błędów. Nie szacujmy bugów 😎 Na ogół nie ma to sensu i będzie to zwykłym marnotrawstwem. Dlaczego?
Przede wszystkim dlatego, że ich rozwiązywanie nie tworzy nowej wartości dla klienta końcowego. Poza tym jest to czasochłonne, trudne i z reguły nie przydaje się za bardzo, a estymaty są takie same lub bardzo zbliżone do siebie.
Bugi nie tworzą wartości produktu
Rozwiązanie błędu nie dostarczy nic nowego dla klienta. Gdy razem z Product Ownerem planujecie przyszłe Sprinty, to chcecie wiedzieć ile nowego dostarczycie. Bugi, z reguły, nie są przedmiotem roadmapy produktowej itp., bo nigdy nie wiadomo jakie “wyprodukujemy” i ile. Ich usuwanie, to czynność “utrzymaniowa” – jak sprzątanie mieszkania czy mycie zębów.
Czy zaliczanie punktów za bugi jest ok? 🤔 To w końcu praca, którą źle wykonaliśmy wcześniej, z takiego czy innego powodu. Lepiej skupić się na liczeniu tego co możemy nowego dać klientom, a błąd usunąć. Bo tylko to interesuje użytkownika – działająca usługa, która rozwiązuje jego problemy.
Jeśli nie będziemy szacowali rozmiaru bugów to nic nie stracimy. Wpływ bugów, ich rozmiar, będzie widoczny w naszej prędkości spalania punktów. Suma ta będzie odzwierciedlała czystą zdolność do produkcji nowej wartości dla klientów, nie będzie zanieczyszczona czynnościami utrzymaniowymi.
“Ale to też praca, którą zrobiliśmy i bez estymat nie będzie tego widać…”
Nierzadko argumentem za szacowaniem rozmiaru bugów jest fakt, że jest to praca, którą deweloperzy wykonują w Sprincie i bez punktów nie będzie wiadomo ile jej było. Tylko czy rzeczywiście ktoś to potrzebuje wiedzieć?
Bywa, że w firmie istnieje system logowania czasu pracy, ale to jest trochę inny temat i opiera się z reguły o zalogowany czas, a nie jednostki relatywne, którymi posługujemy się podczas Planowania czy Doskonalenia Backlogu, czyli Story Points.
Jeśli skupisz się na dostarczaniu nowej wartości dla klientów, to udział bugów będzie widoczny w tym ile jej możesz dostarczyć. Więcej bugów = mniej czasu na dostarczenie nowego, velocity spada. Zatem jeśli zaboli Cię, że usuwasz błędy, a nie dostarczasz nowej wartości dla klienta, to będzie to zrozumiałe. I tak w sumie powinno być. Może zainspiruje to Wasz zespół do podjęcia jakichś technik, które w przyszłości ograniczą liczbę defektów?
Bugi ciężko oszacować…
… i najcześciej, gdy przejrzymy historyczne dane np. z ostatnich dwóch miesięcy, to okaże się, że nasze szacunki są zawsze bardzo zbliżone 😎
W zależności od produktu, jego architektury itd., deweloperzy mają różne problemy w oszacowaniu jak trudna może być naprawa danego błędu. Najczęściej jest tak dlatego, że bug, to pewnego rodzaju niewiadoma – “powinno działać, ale nie działa”. Nasze doświadczenie nam może pomóc i podpowiedzieć “to pewnie coś z xyz”, ale częściej będzie to dużo domyślania się itd.
Zdaje się, że można to rozbić na dwie kategorie:
- albo domyślamy się gdzie leży problem i możemy coś już na starcie o nim powiedzieć,
- albo za cholerę nie wiadomo o co chodzi.
Niezależnie od powyższego, zapewne szybko okaże się, że nasze szacunki dla kolejnych bugów są bardzo często do siebie podobne – mało jest w nich zróżnicowania. Może to przez fakt, że już mamy doświadczenie i znamy nasz projekt? Może kwestia jednak nadal znacznego zakresu niewiadomych? Tak czy owak: jeśli estymaty są zawsze podobne, to czemu nie przypisywać bugom z góry jednej z nich i mieć problem z głowy? Albo jeszcze lepiej – nie robić tego w ogóle :)
Spróbuj zrobić u siebie w zespole doświadczenie i zwrócić uwagę na to jakie estymaty zespół przypisuje. Jeśli potwierdzi się powyższe założenie, zespół będzie poruszał się po zbliżonych wartościach, to czemu z tego całkiem nie zrezygnować? Czy nie jest to zbędny proces?
Priorytety i decyzje
To co uważam, że sprawdza sie zdecydowanie lepiej niż estymowanie bugów, to natychmiastowe decyzje co z nimi robimy. Najczęściej w praktyce przejawiać się to będzie w nadaniu błędowi priorytetu (np. niski, średni, wysoki) i ewentualnym dorzuceniu buga do Sprintu lub Backlogu.
Najlepiej, gdy podczas nadawania takiego priorytetu kierujemy się danymi. Ilu użytkowników dotyczy ten problem? Czy błąd oznacza brak możliwości skonwertowania czy “tylko” jakieś problemy wizualne (bez jednoznacznego wpływu na konwersję)?
Ocena tego jak istotne jest usunięcie buga, oparta na danych, może nam pomóć szybko podjąć decyzję: naprawiamy od razu, odkładamy na potem czy w ogóle nie naprawiamy? Może “w ogóle nie naprawiamy” wyda się kontrowersyjne, ale w przypadku niektórych produktów, eksperymentów itd. będzie to rozsądna decyzja. Musimy pamiętać, że czas poświęcony na naprawę bugów, to czas niepoświęcony na dostarczenie wartości dla klienta.
Jednocześnie niezwykle podoba mi sie jeszcze inna praktyka: bugi, niezależnie od priorytetu, zawsze są zabijane od ręki, w bieżącym sprincie. Dość radykalne działanie, ale… niezwykle proste. I to jest siła tego podejścia. Nie ma w nim miejsca na wątpliwości, planowanie, rozmyślanie. No i nie ryzykujemy ze świadomym budowaniem backlogu bugów na przyszłość.
Podsumowanie
W zależności od produktu i celów jakie stoją przed Waszym zespołem możesz zdecydować się na szacowanie rozmiaru bugów lub nie. Odpowiedz sobie na pytanie: czy rzeczywiście potrzebuję to robić? Jaką mam z tego wartość? Jestem przekonany, że w większości wypadków okaże się, że szacowanie bugów to zbędny proces.
A jaki jest Twój punkt widzenia? Dodaj komentarz
⬇️ ⬇️ ⬇️
2 odpowiedzi na “O szacowaniu rozmiaru bugów”
W moich zespołach najlepiej sprawdzało się zostawienie po prostu pewnego bufora czasowego w sprincie na bugi :)
Bardzo fajny wpis dający do myślenia. Szacowanie bugów jest rzeczywiście dużą trudnością, poza tym obarczone jest ryzykiem niedoszacowania lub przeszacowania. Jestem jednak zwolennikiem ich szacowania, zapewne padnie pytanie: dlaczego?
Po pierwsze szacując bugi „uczymy się” na nich jak je wiarygodnie oszacować. Brzmi nieco pokrętnie, ale sens jest chyba jasny :-) Zdobywamy doświadczenie, po prostu.
Po drugie: Zespół, który pracuje nad Produktem i ma usunąć baga niekoniecznie jest „źródłem” buga. Wielokrotnie spotykałem się z przypadkami bugów w oprogramowaniu Open Source, jak choćby Magento 2 czy Pimcore 5. Co ma zrobić Zespół, gdy odkrywa bug „natywny” blokujący realizację feature a Community frameworka jest w lesie z jego rozwiązaniem? Podobnie, gdy Zespół przejął rozwój i utrzymanie Produktu, sytuacja powszechna w Software House.
Usuwanie problemów i błędów, moim osobistym zdaniem, daje increment Produktu.