# Retrospektywa Sprintu nr 8

• Data: 2026-01-23
• Uczestnicy: Kateryna Lytvyn (Frontend/PM), Kyrylo Riabchenko (Frontend), Mykyta Klymenko (Backend/DevOps), Sebastian Wróblewski (QA/Tester)

• ✓ Udało się utrzymać spójny kierunek rozwoju produktu zgodny z PRD: rozwijaliśmy rekomendacje AI oraz przepływy kluczowe dla użytkownika (podróż → miejsca → sugestie).
• ✓ Zespół szybko identyfikował i opisywał problemy integracyjne (OAuth, maile, konfiguracje prod) oraz dostarczał dane do diagnozy (logi/URL-e żądań/objawy).
• ✓ Współpraca FE↔BE podczas debugowania była efektywna: komunikaty UI, obsługa błędów i poprawki po stronie API były wprowadzane iteracyjnie.
• ✓ QA zebrało materiał do poprawy jakości: testy manualne UI i raporty błędów pozwoliły urealnić listę problemów i priorytetów na następny sprint.

• ✗ Wydania na produkcję ujawniły braki w „release readiness”: różnice konfiguracji dev/prod (OAuth redirect_uri, mail provider) powodowały regresje w krytycznych user-flow.
• ✗ Brak formalnej checklisty wdrożeniowej i smoke testów przed deployem skutkował hotfixami po wdrożeniu oraz większym obciążeniem jednej osoby (Backend/DevOps).
• ✗ Zadania integracyjne nadal bywały zbyt ogólne (brak kontraktu request/response i jednoznacznych kryteriów akceptacji), co zwiększało liczbę poprawek „w trakcie”.
• ✗ Testy nie zawsze miały stabilne, deterministyczne dane wejściowe (seedery / scenariusze), przez co część wyników testów była trudna do odtworzenia.

Główny problem do rozwiązania: Brak procesu „release readiness” (checklista + smoke testy) dla integracji zewnętrznych oraz niedomknięty standard kontraktowania zadań FE↔BE.

Analiza (5 Whys):

Dlaczego na produkcji pojawiały się problemy w logowaniu i mailach? → Bo konfiguracja prod różniła się od dev i nie była walidowana przed wdrożeniem.
Dlaczego nie była walidowana? → Bo nie mieliśmy formalnej checklisty release i krótkich smoke testów „przed deployem”.
Dlaczego nie mieliśmy checklisty i smoke testów? → Bo sprint skupiał się na dowiezieniu funkcji, a „gotowość wydania” nie była częścią Definition of Done.
Dlaczego nie była częścią DoD? → Bo nie przypisaliśmy właściciela procesu release i nie mieliśmy stałego rytuału weryfikacji przed wdrożeniem.
Wniosek: Dodajemy Release Checklist oraz smoke testy jako element DoD dla funkcji zależnych od integracji (OAuth, mailing, mapy) oraz wzmacniamy DoR/DoD dla zadań FE↔BE.

• Co zrobimy? Przygotujemy jednolitą checklistę wdrożeniową dla dev/stage/prod: redirect_uri (Google/Facebook), konfiguracja maili, referery Google Maps, baseURL, CORS, callback routes, zmienne ENV. Checklista będzie wykonywana przed każdym deployem.
• Kto jest odpowiedzialny? Mykyta (Backend/DevOps) i Sebastian (weryfikacja wykonania).
• Jak zmierzymy sukces? Spadek liczby hotfixów po wdrożeniu oraz brak krytycznych regresji w auth/mail/mapach po deployu.

• Co zrobimy? Wprowadzimy stały zestaw smoke testów: rejestracja/logowanie (OAuth), utworzenie podróży, zaproszenie, dodanie miejsca, ustawienie preferencji, rekomendacja AI, wygenerowanie trasy.
• Kto jest odpowiedzialny? Sebastian (QA) i Kyrylo (FE) jako wsparcie w scenariuszach UI.
• Jak zmierzymy sukces? Więcej błędów wykrytych przed produkcją, mniej incydentów po wdrożeniu.

• Co zrobimy? Każde zadanie integracyjne będzie miało: endpointy, przykłady request/response, definicję błędów, kryteria akceptacji oraz mini-checklistę testów (FE/BE/QA). Brak tych elementów równa się nie wchodzeniu zadania do sprintu (DoR).
• Kto jest odpowiedzialny? Kateryna (PM/FE), Mykyta (BE), Sebastian (QA).
• Jak zmierzymy sukces? Mniej doprecyzowań w trakcie sprintu i mniej reworku po integracji.