Retrospektywa Sprintu odbywa się po Przegląd Sprintu i przed następnym Planowanie Sprintu. To jest maksymalnie trzygodzinne spotkanie dla miesięcznych Sprintów. Sesja retrospektywna to zasadniczo spotkanie „poprawy”, które ma na celu znalezienie sposobów i środków do zidentyfikowania potencjalnych pułapek, przeszłych błędów oraz poszukiwania nowych sposobów unikania tych błędów, w którym uczestniczą wszyscy — właściciel produktu, scrum master, członkowie zespołu deweloperskiego oraz opcjonalnie interesariusze.
Czas trwania spotkania retrospektywnego Sprintu
Zasada ogólna dotycząca długości spotkania retrospektywnego sprintu mówi, że zazwyczaj nie powinno ono trwać dłużej niż 45 minut na tydzień trwania sprintu. Poniższa tabela ilustruje tę zasadę:
Ogólny format nieco się różni, ale zazwyczaj robimy to w ten sposób:
- Możemy ustalić czas trwania spotkania proporcjonalnie do długości Sprintu.
- Uczestnicy: właściciel produktu, cały zespół i ja.
- Przechodzimy do zamkniętego pomieszczenia lub przytulnego kąta na sofie, aby móc prowadzić niezakłóconą dyskusję.
- Ktoś jest wyznaczony na sekretarza.
- Scrum master pokazuje backlog sprintu i, z pomocą zespołu, podsumowuje sprint. Ważne wydarzenia i decyzje itp.
- Robimy „rundy”. Każda osoba ma szansę powiedzieć, bez przerywania, Co poszło dobrze w Sprincie? Co poszło źle w Sprincie? Czego się nauczyliśmy w Sprincie? Co powinniśmy zrobić inaczej w następnym sprincie?
- Patrzymy na szacowaną a rzeczywistą prędkość. Jeśli jest duża różnica, staramy się przeanalizować dlaczego.
- Gdy czas się kończy, Scrum master stara się podsumować konkretne sugestie dotyczące tego, co możemy zrobić lepiej w następnym sprincie.
Nasze retrospektywy zazwyczaj nie są zbyt strukturalne. Temat przewodni jest zawsze ten sam: „Co możemy zrobić lepiej w następnym sprincie?”
Szczegóły dotyczące pytań retrospektywnych
1. Co poszło dobrze w Sprincie?
Możliwe pytania, które można zadać, aby zrozumieć powód sukcesu w iteracji, pytając siebie, co poszło dobrze, aby uznać wszystkie dobre rzeczy, które się wydarzyły.
- Co nas zmotywowało do zrobienia tego?
- Co zrobiliśmy inaczej, aby to odniosło sukces?
- Jakie szkolenie, umiejętność lub wiedza przyczyniły się do różnicy?
- Jaka mocna strona w Tobie sprawia, że to się dzieje?
- Jakie mocne strony Twojego zespołu sprawiły, że to się wydarzyło?
- Jaki jest wkład członka zespołu, który pomógł Ci to osiągnąć?
- Jak to osiągnęliśmy?
2. Co poszło źle w Sprincie?
Pytania w tej sekcji nie powinny być zadawane w celu oceny wydajności jednostki ani karania, ale w celu zebrania informacji i zidentyfikowania sposobów rozwiązania problemu w nadchodzącym Sprincie. Gdzie lepiej szukać poprawy niż tam, gdzie rzeczy nie idą dobrze? W rzeczywistości to pytanie ujawnia trudności, problemy i niezadowolenie, z którymi zespół obecnie się boryka.
- Jak to poszło źle?
- Co zrobiłeś, co poszło źle?
- Ilu jest odpowiedzialnych za to, że to poszło źle?
- Czy byłeś świadomy, że to pójdzie źle?
- Czy źle to zrozumiałeś i dlatego wdrożyłeś to źle?
- Czy zrozumiałeś dobrze, ale mimo to poszło źle?
- Co zrobiliśmy dobrze?
3. Czego się nauczyliśmy w Sprincie?
Jakie są wnioski z tego Sprintu? Te pytania są pomocne w identyfikacji tego, co poszło dobrze, a co źle. Zachęca nas do spojrzenia na to, czego się nauczyliśmy o sposobie naszej pracy. Niektóre przykłady mogą być:
- Jak ten sprint został zrealizowany?
- Gdzie poszło źle w tym sprincie?
- Kiedy to poszło źle?
- Jak to poszło źle?
- Które techniki były przydatne?
- Które techniki nie były przydatne?
- Co przebiegło gładko podczas tej iteracji?
- Co nie poszło gładko podczas tej iteracji?
- Czego nauczyliśmy się podczas tej iteracji, co może nas edukować na nadchodzącą iterację?
4. Co powinniśmy zrobić inaczej w następnej iteracji?
Ta sekcja koncentruje się na identyfikacji możliwych działań korygujących na podstawie przeszłych sukcesów, porażek i nauki.
- Jak można wykorzystać siłę jednostki do rozwiązania problemu?
- Co należy robić często, aby zapobiec ponownemu wystąpieniu problemu?
- Jakie działania muszą być wdrożone natychmiast, na które masz zasoby i możliwości?
- Zidentyfikuj jedną rzecz, którą należy zmienić, i wyjaśnij, jak możesz to zmienić?
- Jakie strategie będą skuteczne w zakończeniu pracy?
Działania korygujące
- Co zrobisz w nadchodzącej iteracji, aby zakończyć to działanie?
- Jak to zrobisz, aby odniosło sukces?
- Kiedy to zrobisz podczas iteracji?
- Czy potrzebujesz pomocy, aby to zakończyć?
- Jakiego dodatkowego wsparcia potrzebujesz?
- Jak mnie poinformujesz, że to zakończyłeś?
- Co zrobisz następnie po zakończeniu tego podczas iteracji?
Problemy, które często pojawiają się podczas retrospektyw
„Powinniśmy byli poświęcić więcej czasu na rozbicie historii na podpunkty i zadania”
„Zbyt wiele zewnętrznych zakłóceń”
„Przesadziliśmy z obietnicami i zrobiliśmy tylko połowę rzeczy”
„Nasze środowisko biurowe jest zbyt głośne i chaotyczne”
Podsumowanie
Spotkanie retrospektywne Scrum można traktować jako spotkanie „nauczonych lekcji”. Odpowiednie pytania retrospektywne pozwalają zespołowi myśleć, a jednocześnie dają poczucie odpowiedzialności każdemu członkowi zespołu, co czyni je naprawdęZwinne.
Skorzystaj z powyższych pytań w oparciu o scenariusz i zmotywuj swój zespół oraz siebie do wykazania poprawy w przyszłych iteracjach. Chociaż te przykładowe pytania są wskazujące, możesz je dostosować do swoich potrzeb.
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文