Elementy działań retrospektywnych: Przykłady ułatwiające monitorowanie

Element działania retrospektywnego to konkretne usprawnienie, które zespół zgadza się wprowadzić po omówieniu jego działania. Przydatny zapis zawiera nazwę zmiany, osobę odpowiedzialną oraz punkt przeglądu, a także wyjaśnia, jakie dowody pokażą, czy zmiana pomogła.

"Ulepsz code review" zostawia kolejny krok otwarty. "Na następny sprint umieść każde przygotowane do przeglądu pull request w jednej wspólnej kolejce; Maya codziennie sprawdza nieprzypisane zgłoszenia; ocenimy czas oczekiwania i przerwy na kolejnej retrospektywie" - to konkretne działanie, które zespół może wypróbować.

Scrum Guide opisuje retrospektywę jako okazję do poprawy jakości i efektywności oraz wskazuje na potrzebę szybkiego wprowadzania użytecznych usprawnień. Poniższy format zapisów i przykłady to praktyczne sugestie, nie dodatkowe zasady Scrum.

W tym przewodniku

• Sześć przykładów elementów działań
• Wybierz właściciela i znajdź miejsce na pracę
• Zakończone działanie może wymagać kolejnej decyzji
• Skopiuj zapis działania
• Oceń, co się wydarzyło
• Zachowaj kontekst w Agilo

Sześć przykładów elementów działań retrospektywnych

To fikcyjne sytuacje zespołów programistycznych. Osoby, ograniczenia czasowe i kryteria oceny pokazują, jak wyraźnie sformułować decyzję; dostosuj je do możliwości i zasad pracy swojego zespołu. Wybierz przykład odnoszący się do zaobserwowanego problemu, zamiast przyjmować całą listę.

1. Pull requesty czekają, bo nikt nie wie, kto je zrecenzuje

Niejasne działanie: „Przeglądaj kod szybciej.”

Konkretne działanie: Na następny sprint autorzy dodają gotowe do przeglądu pull requesty do jednej wspólnej kolejki. Maya codziennie sprawdza nieprzypisane zgłoszenia i prosi dostępnego recenzenta o ich przejęcie. Autorzy identyfikują wszystko, co blokuje przegląd, np. brak kontekstu lub niedokończony test.

Ocena: Porównaj czas do pierwszego merytorycznego przeglądu z poprzednim sprintem, uwzględniając wielkość zgłoszeń, dostępność recenzentów i przerwy. Samo potwierdzenie nie jest przeglądem. Szybsze reakcje mają sens tylko wtedy, gdy ludzie nadal mają czas na dokładną analizę kodu.

2. Ten sam niestabilny test ciągle opóźnia dostawy

Niejasne działanie: „Napraw CI.”

Konkretne działanie: Przed kolejną sesją planowania Leo bada przerywany test checkout, który blokował ostatnie dwa scalenia, dokumentuje powtarzalną przyczynę lub zawężoną hipotezę oraz proponuje najmniejszą naprawę. Zespół rezerwuje czas na to badanie.

Ocena: Podczas planowania przejrzyj ustalenia i podejmij kolejną decyzję. Po naprawie obserwuj kolejne odpowiednie uruchomienia pod kątem powtórzeń i przedstaw wyniki na następnej retrospektywie. Wyłączenie testu lub pojedynczy sukces nie oznaczają rozwiązania problemu; utrzymuj wymaganą kontrolę.

3. Zmiana API innego zespołu pojawia się zbyt późno

Niejasne działanie: „Lepsza koordynacja z zespołem platformy.”

Konkretne działanie: Przed rozpoczęciem kolejnego elementu integracji Priya prosi odpowiednika z zespołu platformy o ocenę jednego wspólnego przykładowego żądania, odpowiedzi i przypadku błędu. Zapisuje zaakceptowane założenia i nierozstrzygnięte decyzje w zadaniu integracyjnym. Jeśli nie ma odpowiednika, zgłasza tę zależność podczas planowania, nie traktując jej jako uzgodnionej.

Ocena: Na kolejnej retrospektywie sprawdź, czy uzgodniony przykład pozostał ważny podczas wdrożenia oraz jaki nakład pracy spowodowały brakujące lub zmienione założenia. Umówienie spotkania to krok; celem jest rozwiązanie zależności.

4. Poprawka błędu traci instrukcje reprodukcji podczas przekazania

Niejasne działanie: „Pisz lepsze raporty błędów.”

Konkretne działanie: Przy kolejnych trzech poprawkach Sam dodaje kroki reprodukcji, odpowiednie środowisko i oczekiwane zachowanie do zgłoszenia przed przekazaniem. Programista i tester wspólnie ustalają brakujące szczegóły, zanim będą polegać na tych krokach.

Ocena: Po trzeciej poprawce zapytaj, czy osoba odbierająca mogła odtworzyć i zweryfikować każdą poprawkę bez odtwarzania oryginalnej rozmowy. Zapisz brakujące informacje, nie oceniając autorów raportów.

5. Pytania wsparcia wielokrotnie przerywają temu samemu programiście

Niejasne działanie: „Chroń czas skupienia.”

Konkretne działanie: Na jeden sprint zespół wypróbuje rotacyjny pierwszy kontakt do rutynowych pytań wsparcia. Noor publikuje grafik i wspólne miejsce zgłoszeń, zachowując jednocześnie istniejącą ścieżkę eskalacji pilnych incydentów. Zespół zapewnia czas osobie pełniącej tę rolę.

Ocena: Na następnej retrospektywie przeanalizuj przerwy w pracy zespołu i nieodpowiedziane zgłoszenia. Jeśli jedna osoba pochłania większość zakłóceń lub ważne zgłoszenia czekają dłużej, dostosuj układ. Mniejsza liczba wiadomości w skrzynce programisty nie jest sama w sobie wskaźnikiem sukcesu.

6. Tylko jedna osoba zna sposób na przywrócenie nieudanego wdrożenia

Niejasne działanie: „Dzielenie się wiedzą.”

Konkretne działanie: Przed kolejnym wydaniem Alex organizuje próbę procedury przywracania z udziałem innego programisty w zatwierdzonym środowisku nieprodukcyjnym. Druga osoba realizuje procedurę zgodnie z notatkami i zapisuje brakujące kroki; Alex odpowiada za próbę i aktualizuje instrukcje razem z nią.

Ocena: Po próbie sprawdź, czy druga osoba potrafi wyjaśnić decyzję o przywróceniu i wykonać przećwiczoną procedurę bez niewypowiedzianych wskazówek. Sam fakt istnienia dokumentu nie wystarczy. To ćwiczenie nie zastępuje dostępu do produkcji ani zasad zatwierdzania zmian.

Wybierz właściciela i znajdź miejsce na pracę

Jeden właściciel pilnuje widoczności kolejnego kroku, zbiera wsparcie i dostarcza dowody. Nie musi wykonywać wszystkich zadań ani odpowiadać za zachowanie innych. Potwierdź, że akceptuje działanie i może na nie wpłynąć.

Zacznij od jednej lub dwóch zmian, jeśli to jest możliwe dla zespołu. To decyzja o pojemności, a nie uniwersalne ograniczenie. Przed dodaniem działania ustalcie, ile czasu wymaga i gdzie będzie śledzone razem z pracą nad dostawą. Dochodzenie może wymagać odrębnego zadania; zmieniona zasada przekazywania może pasować do istniejącego opisu zadania.

Jeśli zmiana zależy od innego zespołu lub menedżera, wyraźnie określ prośbę i punkt decyzyjny. Właściciel może zobowiązać się do uzyskania decyzji; nie może zagwarantować czyjejś aprobaty.

Użyj szablonu Start Stop Continue gdy dyskusja dotyczy praktyk do zmiany lub zachowania. Nota „Start” jest wciąż propozycją, dopóki zespół nie zaakceptuje działania i nie znajdzie na nie miejsca.

Zakończone działanie nadal może wymagać kolejnej decyzji

Wróć do przykładu kolejki przeglądowej. Zespół rejestruje dwa różne sprawdzenia:

Załóżmy, że zespół korzysta z kolejki przez cały sprint, ale zgłoszenia nadal czekają, gdy jedyna osoba znająca usługę jest niedostępna. To przykład fikcyjny, a nie wynik zgłoszony przez klienta Agilo.

Eksperyment z kolejką został przeprowadzony. Zespół dowiedział się, że sama widoczność nie rozwiązała wąskiego gardła specjalisty. Kolejna decyzja może dotyczyć przydzielenia innego programisty do przeglądów dla tej usługi, pozostawiając kolejkę, jeśli okaże się przydatna. „Zrobione” oznacza ukończenie uzgodnionej pracy, niekoniecznie zniknięcie pierwotnego problemu.

Jeśli wystąpiło tylko kilka podobnych zgłoszeń, uznaj, że dowody są ograniczone. Możesz zdecydować się na obserwację kolejnego sprintu bez twierdzenia, że zmiana się powiodła lub nie.

Skopiuj ten zapis działania z retrospektywy

Użyj tego w istniejącym narzędziu do śledzenia zadań lub notatkach zespołu. Nadaj działaniu tytuł opisujący zmianę, a następnie zachowaj obok uzasadnienie.

Obserwacja i źródło:
Zmiana, którą wypróbujemy:
Właściciel, który ją zaakceptował:
Osoby lub decyzje wymagane:
Pierwszy krok i zarezerwowany czas:
Kiedy dokonamy przeglądu:
Dowody wykonania działania:
Dowody skuteczności, włącznie z możliwymi skutkami ubocznymi:
Decyzja po przeglądzie: zachować / dostosować / przerwać / zebrać więcej dowodów

W przypadku kolejki przeglądu pierwszym krokiem może być ustalenie, gdzie trafiają zgłoszenia przed rozpoczęciem sprintu. Punktem przeglądu może być następna retrospektywa, z krótkim sprawdzeniem podczas sprintu, czy zgłoszenia pozostały nieprzydzielone. Użyj konkretnej daty lub wydarzenia, które zespół będzie mógł odnaleźć, zamiast „później”.

Przejrzyj, co się wydarzyło, zanim dodasz kolejne działania

Podczas ustalonej kontroli poproś właściciela o opisanie pracy i pokazanie dostępnych dowodów. Prowadź dyskusję o warunkach i decyzjach, w tym czy zespół udostępnił obiecany czas.

Kontynuowanie tego samego działania bez zmiany warunków powoduje, że kolejny sprint ma to samo nierozwiązane zobowiązanie. Udostępnij nową decyzję, nawet jeśli jest to decyzja o przerwaniu działania.

Aby uzyskać pełną sekwencję spotkania, włączając przygotowanie i priorytetyzację, skorzystaj z przewodnika po facylitacji retrospektywy sprintu.

Pytania dotyczące zadań z retrospektywy

Czy każda notatka z retrospektywy wymaga działania?

Nie. Notatki mogą zachować coś, co działa, zgłosić pytanie lub dostarczyć kontekst. Wybieraj usprawnienia na podstawie tego, czego zespół się nauczył i co może wpłynąć. Zamienianie każdej notatki w zadanie może ukryć kilka zmian, które zasługują na uwagę.

Czy Scrum Master powinien być właścicielem wszystkich działań?

Wybierz właściciela, który może pchnąć każdą zmianę do przodu. Facylitator może pomagać zespołowi w zawieraniu i przeglądaniu ustaleń, nie będąc przypisanym do każdego usprawnienia. Działanie dotyczące zachowań w budowie może wymagać dewelopera; decyzja dotycząca zależności zewnętrznych może wymagać osoby, która ma dostęp do odpowiedniego zespołu.

Czy dochodzenie może być zadaniem?

Tak, gdy niepewność uniemożliwia rozsądną zmianę. Określ pytanie, dostępny czas oraz decyzję, którą wyniki dochodzenia mają poprzeć. „Zbadać powolne przeglądy” jest niejasne; „zidentyfikuj, gdzie czekały trzy opóźnione zgłoszenia i przynieś proponowaną zmianę do refinementu” ma określony rezultat.

Zachowaj obserwację i działanie razem w Agilo

W Agilo Retrospectives zadanie może mieć tytuł, opis, przypisaną osobę, priorytet i status, a także może być powiązane z kartą źródłową. Umieść w opisie ustalony punkt przeglądu oraz dowody do zebrania; dodaj zaobserwowany rezultat w komentarzu podczas przeglądu.

Dzięki temu zachowujesz powód działania obok postępów. Zespół nadal decyduje, czy zmiana pomogła i co zrobić dalej.

Utwórz retrospektywę i przekształć jedną obserwację w działanie, które zespół jest gotów wykonać.