Retrospektywa sprintu 14 — zespół procesu zakupowego
Migracja do nowego operatora płatności weszła na czas, ale potem potrzebne były dwie poprawki, bo dane na środowisku testowym różniły się od produkcji. Zespół ustalił cotygodniowe odświeżanie danych testowych, dzielenie dużych zadań przed planowaniem i próbę codziennego dyżuru do review.
Podsumowanie
Sylwia zaczęła od sprawdzenia działań z poprzedniej retrospektywy: dwa z trzech zostały wykonane. Zespół był zadowolony, że migracja do nowego operatora płatności weszła zgodnie z planem, a praca w parach pomogła przy najtrudniejszych zadaniach. Po wydaniu potrzebne były dwie poprawki, bo dane na środowisku testowym nie odpowiadały już produkcji. Proces zwrotów, wyceniony na 8 punktów, zajął mniej więcej trzy razy więcej czasu, niż planowano, a pull requesty czekały na review średnio ponad dobę. Zespół wybrał trzy usprawnienia, a dyżur do review przetestuje przez dwa sprinty, zanim zdecyduje, czy go zostawić.
Uczestnicy
- Sylwia Kaczmarek — scrum master, prowadzi
- Tomasz Rudnicki — programista
- Maja Czerwińska — programistka
- Jonasz Adamczyk — programista
- Weronika Zając — QA
Agenda
- Działania z poprzedniej retrospektywy
- Co poszło dobrze
- Co nie poszło dobrze
- Usprawnienia na sprint 15
Decyzje
- Przez dwa sprinty testujemy codzienny dyżur do review, potem decydujemy, czy go zostawić.
- Zadania wycenione na więcej niż 5 punktów dzielimy przed planowaniem sprintu.
Zadania
| Odpowiedzialny | Zadanie | Termin |
|---|---|---|
| Maja Czerwińska | Przygotować skrypt cotygodniowego odświeżania danych testowych z zanonimizowanych danych produkcyjnych | Do końca sprintu 15 |
| Jonasz Adamczyk | Ustawić codzienny dyżur do review w kalendarzu zespołu | Poniedziałek |
| Sylwia Kaczmarek | Dodać do listy kontrolnej planowania punkt „dziel zadania powyżej 5 punktów” | — |
Co poszło dobrze
- Migracja do nowego operatora płatności weszła zgodnie z planem.
- Praca w parach przy dwóch najtrudniejszych zadaniach oszczędziła czas i rozłożyła wiedzę.
- Rezygnacja z czwartkowej synchronizacji dała godzinę tygodniowo, a nikt nie stracił informacji.
Co nie poszło dobrze
- Dwie poprawki po wydaniu: dane na środowisku testowym nie odpowiadały już produkcji.
- Proces zwrotów wyceniono na 8 punktów, a zajął mniej więcej trzy razy więcej.
- Pull requesty czekały na review średnio ponad dobę.
Pomysły na usprawnienia
- Odświeżać dane na środowisku testowym co tydzień.
- Dzielić każde zadanie powyżej 5 punktów przed planowaniem.
- Codziennie jedna osoba dyżuruje przy review, rotacyjnie w całym zespole.
Następne spotkanie
Retrospektywa sprintu 15 za dwa tygodnie, o tej samej godzinie — zaczynamy od sprawdzenia tych trzech działań.