Co poszło dobrze?

Z czego jesteśmy zadowoleni?

Dostarczyliśmy wszystkie zaplanowane historyjki i osiągnęliśmy cel sprintu.
Nasze daily były sprawne i pomogły nam się koordynować.
Nowe podejście do programowania w parach poprawiło jakość kodu.
Co poszło gorzej?

Co powinniśmy poprawić?

Mieliśmy problem z niejasnymi wymaganiami i musieliśmy przyjmować założenia.
Testy robiliśmy w pośpiechu pod koniec, bo wcześniej w sprincie rozrósł się zakres.
Luki w komunikacji między zespołami frontendu i backendu spowodowały opóźnienia.
Co chcemy wypróbować?

Co powinniśmy robić inaczej?

Zapraszać eksperta dziedzinowego na planowanie i refinement.
Przed implementacją złożonych funkcji robić spike projektowy.
Ograniczać zadania czasowo, żeby nie grzęznąć w szczegółach.
Co nas zastanawia?

Na jakie pytania wciąż nie mamy odpowiedzi?

Jak możemy ulepszyć praktyki DevOps i proces wdrożeń?
Jakie umiejętności musimy rozwinąć jako zespół przed nadchodzącym projektem?
Czy powinniśmy przyjrzeć się nowym frameworkom lub narzędziom do testów?

Czym jest retrospektywa agile?

Retrospektywa agile opiera się na czterech prostych pytaniach: co poszło dobrze, co poszło gorzej, co chcecie wypróbować w następnej kolejności i co wciąż was zastanawia. Razem skłaniają zespół do rozmowy o tym, jak minął ostatni sprint i na jakich działaniach skupić się w kolejnym. Ten format jest celowo prosty. Prowadząc go, pokazujesz zespołowi, że go słuchasz i zamierzasz działać na podstawie tego, co mówi. Samą praktykę retrospektyw opisują Esther Derby i Diana Larsen w książce Agile Retrospectives (ze wstępem Kena Schwabera). Działa ona jak regularny przegląd techniczny, dzięki któremu zespół pracuje sprawnie. Retrospektywa prowadzona w każdym sprincie wydobywa problemy w sposobie tworzenia i dostarczania oprogramowania, zanim zdążą urosnąć, i daje zespołowi stały czas na wspólne ich rozwiązanie. Krótkie, regularne retrospektywy z zapisanymi działaniami pozwalają zmienić kurs, zanim będzie za późno. Podobnie jest ze sterowaniem dużym statkiem: drobne korekty po drodze są łatwiejsze niż odkrycie na końcu rejsu, że zawinęło się do niewłaściwego portu. Post-mortem to jednorazowe spojrzenie wstecz po zakończeniu projektu. Retrospektywa agile patrzy w przód, na kolejny sprint, dzięki czemu rozmowa pozostaje pozytywna i praktyczna.

Format retrospektywy agile

Co poszło dobrze?

Z czego jesteśmy zadowoleni?

Zachęć zespół do dzielenia się konkretnymi przykładami sukcesów, dużych i małych. Doceńcie osiągnięcia zespołu i wkład poszczególnych osób.

Co poszło gorzej?

Co powinniśmy poprawić?

Stwórz atmosferę bez szukania winnych, sprzyjającą otwartej i szczerej rozmowie. Skupcie się na procesach, a nie na ludziach. Szukajcie przyczyn źródłowych.

Co chcemy wypróbować?

Co powinniśmy robić inaczej?

Zachęcaj do kreatywnego myślenia i bądź otwarty na niekonwencjonalne pomysły. Szukajcie małych, praktycznych eksperymentów do przeprowadzenia w następnym sprincie.

Co nas zastanawia?

Na jakie pytania wciąż nie mamy odpowiedzi?

To okazja, by wydobyć niewiadome i obszary wymagające dalszego zbadania. Zapisz je do omówienia w przyszłości.

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

  • Na koniec każdego sprintu lub iteracji, aby przemyśleć miniony cykl.
  • Gdy zespół chce wskazać konkretne rzeczy do poprawy.
  • Po ważnym kamieniu milowym lub wydaniu, aby omówić wyciągnięte wnioski.
  • Zawsze, gdy zespół czuje, że utknął, i musi wrócić na właściwe tory.
  • W trakcie transformacji agile, aby regularna refleksja stała się nawykiem każdego zespołu.

Proponowane pytania lodołamacze

  • Gdybyś mógł dodać jedno narzędzie lub proces, który pomógłby naszemu zespołowi, co by to było?
  • Jaka jedna drobna rzecz mogłaby mieć duży, pozytywny wpływ na nasz zespół?

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

  • Na początku ustal zasadę, że nie szukamy winnych, żeby ludzie mówili otwarcie.
  • Ogranicz czas na każdą część, żeby retrospektywa nie traciła skupienia.
  • Zbierz głosy wszystkich, nie tylko kilku najbardziej rozmownych osób. Pomaga kilka minut cichej burzy mózgów.
  • Zapisuj działania do wykonania i przypisz do każdego osobę odpowiedzialną za jego dopilnowanie.
  • Nie próbuj rozwiązać wszystkich problemów naraz. Wybierz jeden lub dwa najważniejsze i przeprowadź małe eksperymenty.
  • Zmieniajcie osobę prowadzącą, żeby zyskać świeże spojrzenie.

Najczęściej zadawane pytania

Czym jest retrospektywa agile?
Retrospektywa agile to spotkanie na koniec sprintu, na którym zespół przygląda się temu, jak przebiegała praca, i ustala, co zmienić. Ten szablon wykorzystuje cztery pytania: co poszło dobrze, co poszło gorzej, co chcemy wypróbować i co nas zastanawia.
Jak często przeprowadzać retrospektywę agile?
Większość zespołów robi ją na koniec każdego sprintu. Można ją też przeprowadzić po ważnym wydaniu lub kamieniu milowym albo zawsze, gdy zespół czuje, że utknął.
Ile trwa retrospektywa agile?
Scrum Guide ogranicza retrospektywę sprintu do trzech godzin przy sprincie miesięcznym, a przy krótszych sprintach retrospektywa jest krótsza. Przy sprincie dwutygodniowym typowo trwa 45–90 minut.
Czym różni się retrospektywa agile od post-mortem?
Post-mortem odbywa się raz, po zakończeniu projektu, i analizuje, co poszło nie tak. Retrospektywa agile odbywa się w każdym sprincie, więc zespół może naprawiać drobne problemy, póki jest jeszcze czas na działanie.
Czy zespoły zdalne mogą przeprowadzić retrospektywę agile?
Tak. W TeamRetro rozproszone zespoły dodają pomysły, grupują je, głosują i wspólnie ustalają działania w czasie rzeczywistym, niezależnie od miejsca.
Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo