Ile otwartych błędów macie w backlogu? 100? 1000?
A ile czasu tam leżą? Tydzień? Miesiąc? Lata?
A dlaczego tak się dzieje? Brak czasu? Trzeba robić bardziej priorytetowe zadania? „Teraz zrealizujemy wszystkie pilne funkcje, a potem na pewno znajdzie się czas na ogarnięcie błędów”?

… Niektórzy stosują politykę Zero Bug Policy, u innych dobrze rozwinięta jest kultura pracy z błędami (na bieżąco aktualizują backlog, przeglądają błędy przy zmianie funkcjonalności itd.), a niektórzy hodują czarodziejów, którzy piszą całkowicie bez błędów (mało prawdopodobne, ale może się to zdarza).

Dziś opowiem Wam o naszym rozwiązaniu dotyczącego oczyszczania backlogu błędów — projekt „Buglandia”.

Od czego to wszystko się zaczęło?

Przy kolejnej próbie przeglądania coraz większego backlogu otwartych błędów doszliśmy do punktu krytycznego. Nie dało się tak dalej żyć, postanowiliśmy, że musimy go skrócić za wszelką cenę. Pomysł oczywisty, ale jak to zrobić? Uznaliśmy, że najbardziej efektywnym sposobem będzie zorganizowanie wydarzenia przypominającego hackathon: oderwanie zespołów od codziennych zadań i poświęcenie 1 dni roboczego tylko na błędy.

Sporządziliśmy regulamin, ogłosiliśmy i czekaliśmy. Mieliśmy obawy, że chętnych będzie mało, bardzo mało, ale wynik przeszedł nasze oczekiwania — zapisało się aż 8 zespołów (co prawda, w ostatniej chwili 3 się wycofały). Na wydarzenie przeznaczyliśmy cały roboczy dzień w piątek, zarezerwowaliśmy dużą salę konferencyjną. Obiad zorganizowaliśmy w oparciu o biurową stołówkę, a do przekąsek dołożyliśmy ciasteczka.

Realizacja

Rano w dniu X zebraliśmy wszystkich chętnych w sali konferencyjnej i przeprowadziliśmy krótkie wprowadzenie.

Główne zasady:

• w jednej drużynie walczy od 2 do 5 osób, przynajmniej jedna z nich to QA;
• błędy muszą być zamykane przez członka drużyny zgodnie ze wszystkimi wewnętrznymi standardami produkcyjnymi;
• każda drużyna musi mieć przynajmniej jednego zamkniętego błędu, wymagającego poprawek w kodzie;
• można poprawiać tylko stare błędy (data utworzenia błędu < data rozpoczęcia Buglandii — 1 miesiąc);
• za naprawione błędy przyznawane są punkty (od 3 do 10) w zależności od krytyczności (żeby nie było oszustw, nie można zmieniać krytyczności po ogłoszeniu daty przeprowadzenia Buglandii);
• za zamknięcie przestarzałych, niewykrywalnych błędów przyznawany jest 1 punkt;
• za przestrzeganiem wszystkich zasad czuwa zespół audytorów, który anuluje punkty za ponownie otwarte błędy.

Inne szczegóły

• Nie ograniczaliśmy nikogo w wyborze lokalizacji: można było zostać w swoim miejscu pracy lub usiąść ze wszystkimi w sali konferencyjnej, w której nikt nie przeszkadzał, a atmosfera była napięta.

• Aby podtrzymać ducha rywalizacji, na dużym ekranie wyświetlona została tabela rankingowa, a w kanale slackowym przez cały czas trwała tekstowa relacja z walki. Do obliczania punktów używano leaderboardu, który był aktualizowany za pomocą webhooków.

Leaderboard

• Nadzór nad przestrzeganiem wszystkich zasad sprawowała zespół audytowy (na podstawie doświadczenia, wystarczy 1-2 osoby).
• Godzinę po zakończeniu Bałaganów ogłoszono zweryfikowane wyniki.
  Zwycięzcy otrzymali voucher do baru, a wszyscy uczestnicy – pamiątki (breloki z 'błędami').

Wyniki

W ciągu ostatnich sześciu miesięcy zorganizowaliśmy już trzy Bałagany. Co zatem osiągnęliśmy?

• Średnia liczba zespołów – 5.
• Średnia liczba przezwyciężonych błędów – 103.
• Średnia liczba błędów nieaktualnych/niemożliwych do odtworzenia – 57% (a ten bałagan stale rzucał się w oczy swoim bezmiarem).

Moment ogłoszenia wyników

A teraz odpowiedź na najtrudniejsze pytanie, które wszyscy lubią zadawać: 'Ile nowych błędów wprowadziliście?'.
Odpowiedź: nie więcej niż 2% ze wszystkich przetworzonych.

Opinie

Po przeprowadzeniu Bałaganów zbieraliśmy opinie od uczestników. Oto odpowiedzi na pytanie 'Co najbardziej podobało się w procesie uczestnictwa?':

• Naprawdę fajnie przeglądać backlog z taką motywacją! Zwykle to bardzo nudny proces, warto to robić okresowo).
• Zapał, ciastka.
• To długo oczekiwana okazja, by naprawić drobne szczegóły, które nie są krytyczne, ale chciałoby się je poprawić.
• Podobało się, że można w końcu naprawić stare, nieprzyjemne błędy poza sprintem, bo na takie nigdy nie ma czasu, ponieważ zawsze będą zadania o wyższym priorytecie. Udało się zgromadzić w jednym miejscu wszystkich potrzebnych ludzi (w naszym zespole był DBA, na przykład), wspólnie omówiliśmy aktualność zgłoszonych błędów i techniczne możliwości ich naprawy.

Podsumowanie

Bałagan – to nie panaceum, ale całkiem wykonalna opcja na zmniejszenie backlogu błędów (w różnych zespołach od 10 do 50%) w zaledwie jeden dzień. Nasze wydarzenie rozwinęło się tylko dzięki zmotywowanym ludziom, którzy pasjonują się produktem i dbają o zadowolenie naszych użytkowników.

Wszystkiego dobrego i mniej błędów!

Źródło: habr.com