Czym jest retrospektywa zespołu inżynierskiego?
Retrospektywa zespołu inżynierskiego jest przeznaczona dla programistów, testerów QA, specjalistów DevOps i liderów technicznych. Obejmuje techniczną stronę pracy, czyli jakość kodu, testy, pipeline'y i dług techniczny, a także stronę ludzką: jak zespół się komunikował, jak dzielił się wiedzą i jak radził sobie z dyżurami on-call. Tablica ma cztery kolumny, a każda z nich to pytanie. „Co zadziałało dobrze?” zbiera praktyki i sukcesy, które warto utrzymać. „Co nas spowolniło?” gromadzi blokery, tarcia i dług techniczny. „Jak nam się współpracowało?” dotyczy komunikacji i wzajemnego wsparcia w zespole. „Czego spróbujemy następnym razem?” zamienia dyskusję w kilka eksperymentów, z których każdy ma swojego właściciela. W TeamRetro wszyscy dodają pomysły jednocześnie, potem zespół je grupuje, głosuje nad tym, co najważniejsze, i zamienia najważniejsze punkty w śledzone działania. Przeprowadzajcie ją na koniec każdego sprintu, po dużym wydaniu albo jako regularny przegląd. Nie szukajcie winnych, żeby ludzie równie chętnie mówili o niestabilnym teście, który zignorowali, jak o refaktoryzacji, z której są dumni.
Format retrospektywy zespołu inżynierskiego
Co zadziałało dobrze?
Które praktyki inżynierskie lub sukcesy warto utrzymać?
Proś o konkrety: decyzję architektoniczną, która się sprawdziła, bezproblemowe wdrożenie, udane programowanie w parach, solidne pokrycie testami. Nazwanie tego, co zadziałało, ułatwia dalsze robienie tego samego.
Co nas spowolniło?
Jakie blokery, tarcia lub dług techniczny nas hamowały?
Wydobądź na światło dzienne wąskie gardła, dług techniczny, niejasne wymagania i tarcia w procesie. Nie szukajcie winnych i skupcie się na powracających problemach, które zespół realnie może rozwiązać.
Jak nam się współpracowało?
Jak dobrze się komunikowaliśmy i wspieraliśmy nawzajem?
Przyjrzyjcie się, jak przepływały informacje, czy ludzie czuli wsparcie i jak zapadały decyzje. Często pojawiają się tu decyzje podejmowane w prywatnych wiadomościach i przekazywanie pracy między strefami czasowymi.
Czego spróbujemy następnym razem?
Jakie eksperymenty lub usprawnienia chcemy wprowadzić?
Proś o konkretne eksperymenty, drobne zmiany w procesie lub inwestycje techniczne do wypróbowania w kolejnej iteracji. Niech będą małe i mierzalne, a każda ma swojego właściciela, żebyście mogli je sprawdzić następnym razem.
Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego
- Na koniec każdego sprintu lub iteracji, aby przejrzeć praktyki inżynierskie i sposób dostarczania.
- Po dużym wydaniu, incydencie lub problemie na produkcji, aby zebrać wnioski bez szukania winnych.
- Jako regularny przegląd, który pozwala wychwycić dług techniczny, wąskie gardła i tarcia we współpracy, zanim urosną.
- Przy wdrażaniu nowych inżynierów lub zmianie struktury zespołu, aby uzgodnić sposób pracy.
Proponowane pytania lodołamacze
- Gdyby wasz kod był miastem, jakim miejscem byłby teraz?
- Bez jakiej technologii lub narzędzia nie dałbyś sobie rady w tym sprincie?
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
- Nie szukajcie winnych. Rozmawiajcie o systemach, procesach i okolicznościach, a nie o konkretnych osobach.
- Zbierajcie pomysły anonimowo i równolegle przed dyskusją, żeby cichsi inżynierowie mieli tyle samo do powiedzenia co seniorzy.
- Użyjcie głosowania kropkami, aby wybrać tematy o największym wpływie, a resztę zostawcie na inną sesję.
- Ustalcie kilka konkretnych działań z właścicielami i przejrzyjcie je na początku kolejnej retrospektywy.
- Ograniczcie czas na każdą kolumnę, żeby jedna techniczna debata nie zdominowała całej sesji.
- Zmieniajcie facylitatora, żeby cały zespół czuł się współodpowiedzialny, a format nie spowszedniał.