Retrospektywa naprawy błędów

Dowiedz się, skąd biorą się błędy, i nie dopuść do ich powrotu

Zapraszamy do obejrzenia tej retrospektywy na żywo

Ostatnie błędy

Które błędy sprawiły najwięcej kłopotów w ostatnim sprincie?

W procesie finalizacji zamówienia w koszyku było kilka błędów, przez które zamówienia się nie udawały.
Wyciek pamięci w module przetwarzania danych powodował awarie systemu przy większych zbiorach danych.
Przez kilka błędów w UI aplikacja mobilna była trudna w obsłudze na mniejszych ekranach.
Przyczyny źródłowe

Jakie były prawdziwe przyczyny każdego poważnego błędu?

Brak testów end-to-end dla procesu zamówienia z powodu napiętych terminów.
Problemy z zarządzaniem pamięcią wynikające z nieefektywnych struktur danych i algorytmów.
Niewystarczające testy nowych komponentów UI na różnych przeglądarkach i urządzeniach.
Działania zapobiegawcze

Co możemy zrobić, żeby podobne błędy się nie powtarzały?

Wprowadzić pełne zestawy testów regresyjnych dla kluczowych ścieżek użytkownika.
Regularnie robić code review skupione na zarządzaniu pamięcią i wydajności.
Ustalić testy na różnych przeglądarkach i platformach jako warunek każdej zmiany w UI.
Cele jakościowe

Jakie wskaźniki lub cele pozwolą nam zmierzyć poprawę?

Zmniejszyć liczbę defektów na produkcji o 30% w porównaniu z poprzednim kwartałem.
Utrzymać pokrycie kodu powyżej 80% dzięki automatycznym testom jednostkowym i integracyjnym.
Zero błędów o wysokim priorytecie i luk bezpieczeństwa w buildach produkcyjnych.
Nasze wnioski

Jakie lekcje wynosimy z tej retrospektywy?

Musimy zarezerwować więcej czasu na dokładne testy, zwłaszcza kluczowych ścieżek użytkownika.
Przy każdym code review powinniśmy sprawdzać wydajność i zużycie pamięci.
Jasne wytyczne i checklisty mogą pomóc uniknąć regresji.

Czym jest retrospektywa naprawy błędów?

Retrospektywa naprawy błędów to spotkanie poświęcone przeglądowi błędów z ostatniego sprintu i ustaleniu, skąd się wzięły. Zamiast naprawiać kolejne usterki i iść dalej, zespół śledzi te najważniejsze aż do luk w testach, standardach lub procesie, które je przepuściły, i uzgadnia zmiany, dzięki którym ten sam rodzaj błędu już nie wróci. Tablica ma pięć kolumn. W kolumnie Ostatnie błędy wpisujecie usterki, które miały największe znaczenie, zwłaszcza te o dużym wpływie lub powracające. W kolumnie Przyczyny źródłowe korzystacie z metody 5 Why: pytajcie „dlaczego?” tak długo, aż dojdziecie do przyczyny tkwiącej w sposobie pracy zespołu, a nie w linijce kodu. Działania zapobiegawcze zamieniają te przyczyny w konkretne zmiany. Cele jakościowe to mierzalne założenia, np. mniej defektów na produkcji albo wyższe pokrycie testami, dzięki którym sprawdzicie, czy zmiany zadziałały. W kolumnie Nasze wnioski zapisujecie to, co zespół wynosi ze spotkania. Nie szukajcie winnych. Metoda 5 Why przestaje działać w chwili, gdy odpowiedzią staje się czyjeś nazwisko, dlatego kierujcie każde „dlaczego” w stronę systemu: brakującego testu, niejasnego wymagania albo terminu, przez który zabrakło czasu na code review.

Format retrospektywy naprawy błędów

Ostatnie błędy

Które błędy sprawiły najwięcej kłopotów w ostatnim sprincie?

Wypiszcie usterki, które miały największe znaczenie w sprincie, skupiając się na tych o dużym wpływie lub powracających. Wystarczy jedna linijka na błąd, analiza przyjdzie w następnej kolumnie.

Przyczyny źródłowe

Jakie były prawdziwe przyczyny każdego poważnego błędu?

Użyjcie metody 5 Why, żeby dotrzeć głębiej niż do objawu. Zapytajcie, dlaczego błąd się pojawił, potem dlaczego tak było, i tak dalej, aż dojdziecie do zawodzącego elementu procesu, który zespół może zmienić.

Działania zapobiegawcze

Co możemy zrobić, żeby podobne błędy się nie powtarzały?

Zamieńcie każdą przyczynę źródłową w zmianę w procesie, praktykach lub kontroli jakości. Jeden konkretny krok z przypisaną osobą jest lepszy niż ogólna obietnica, że będziemy więcej testować.

Cele jakościowe

Jakie wskaźniki lub cele pozwolą nam zmierzyć poprawę?

Uzgodnijcie mierzalne cele dotyczące defektów, długu technicznego lub pokrycia testami, żeby na następnej retrospektywie sprawdzić, czy działania zapobiegawcze zadziałały.

Nasze wnioski

Jakie lekcje wynosimy z tej retrospektywy?

Na koniec podsumujcie, czego zespół się nauczył, i potwierdźcie zadania do wykonania, żeby wszyscy wyszli z tą samą listą.

Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego

  • Po sprincie lub etapie projektu, w którym zgłoszono dużo błędów.
  • Gdy dług techniczny lub rosnący backlog defektów obniża produktywność i jakość wydań.
  • Gdy te same rodzaje problemów ciągle wracają i podejrzewacie, że stoi za nimi problem w procesie.
  • Jako ćwiczenie skupione na jakości dla zespołu, który ma kłopoty z jakością kodu.

Proponowane pytania lodołamacze

  • Gdybyś mógł raz na zawsze usunąć ze świata jeden błąd, który by to był i dlaczego?
  • Opowiedz zabawną lub żenującą historię związaną z jakimś błędem, na który trafiłeś.

Czy chciałby Pan/Pani, aby Państwa zespół wykonał ćwiczenie rozgrzewkowe, a nie tylko odpowiadał na pytania na głos? Przejrzyj bezpłatne lodołamacze →

Pomysły i wskazówki dotyczące spotkania retrospektywnego

  • Nie szukajcie winnych. Chodzi o naukę, a nie o ustalenie, kto zawinił.
  • Zaproście nie tylko programistów, ale też QA, DevOps i product ownerów, bo każdy patrzy na błędy z innej perspektywy.
  • Stawiajcie błędy o dużym wpływie lub często powracające przed drobnymi, jednorazowymi problemami.
  • Korzystajcie z metody 5 Why, żeby przejść od objawu do przyczyny źródłowej.
  • Każde działanie zapobiegawcze i każdy cel jakościowy powinny mieć osobę odpowiedzialną i termin.
  • Sprawdzajcie postępy w realizacji tych zobowiązań na kolejnych retrospektywach.

Najczęściej zadawane pytania

Czym jest retrospektywa naprawy błędów?
To retrospektywa, na której zespół przegląda ostatnie błędy, szuka ich przyczyn źródłowych metodą 5 Why i uzgadnia działania zapobiegawcze oraz cele jakościowe.
Kiedy warto przeprowadzić retrospektywę naprawy błędów?
Po sprincie, w którym zgłoszono dużo błędów, gdy dług techniczny spowalnia wydania albo gdy powracające defekty wskazują na problem w procesie.
Jak działa metoda 5 Why w tej retrospektywie?
Weźcie jeden błąd i zapytajcie, dlaczego się pojawił, a potem przy każdej odpowiedzi znów pytajcie „dlaczego?”, łącznie mniej więcej pięć razy. Zwykle dochodzicie do przyczyny w procesie, np. brakującego testu albo zależności, której nikt nie sprawdził, i właśnie to trzeba naprawić.
Ile trwa retrospektywa naprawy błędów?
Zaplanujcie 60–90 minut. Pięć kolumn i metoda 5 Why zajmują więcej czasu niż zwykła retrospektywa, dlatego zamiast omawiać wszystkie błędy, wybierzcie dwa lub trzy najważniejsze i przeanalizujcie je dokładnie.
Czym różni się od retrospektywy Bug Busters?
Obie dotyczą defektów. Retrospektywa naprawy błędów sięga głębiej do przyczyn źródłowych dzięki metodzie 5 Why i wyznacza mierzalne cele jakościowe, a Bug Busters przygląda się też błędom, które udało się wyłapać, i temu, co spowalnia ich naprawę.

Powiązane szablony

Retrospektywa procesu rozwoju produktu

Oderwij się od sprintów i sprawdź, jak tworzycie produkty.

Retrospektywa długu technicznego

Znajdź, uszereguj i zaplanuj spłatę długu technicznego

Retrospektywa code review

Spraw, by przeglądy kodu w zespole były szybsze i bardziej przydatne

Retrospektywa DevOps

Przeanalizujcie wdrożenia, incydenty i przekazywanie pracy między dev a ops.

Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo