Co zadziałało dobrze?

Które praktyki inżynierskie lub sukcesy warto utrzymać?

Nasze automatyczne testy wyłapały dwie regresje, zanim trafiły na produkcję.
Programowanie w parach przy refaktoryzacji modułu autoryzacji poszło naprawdę gładko.
Pipeline CI był szybki i niezawodny przez cały sprint, bez żadnych niestabilnych buildów.
Co nas spowolniło?

Jakie blokery, tarcia lub dług techniczny nas hamowały?

Niestabilne testy integracyjne zmuszały nas do wielokrotnego uruchamiania buildów.
Niejasne kryteria akceptacji spowodowały poprawki pod koniec sprintu.
Za dużo przełączania się między poprawianiem błędów a pracą nad nowymi funkcjami.
Jak nam się współpracowało?

Jak dobrze się komunikowaliśmy i wspieraliśmy nawzajem?

Dzielenie się wiedzą podczas piątkowego tech talku było naprawdę przydatne.
Część decyzji zapadła w prywatnych wiadomościach i reszcie z nas zabrakło kontekstu.
Wdrożenie nowego inżyniera poszło sprawnie dzięki dobrej dokumentacji.
Czego spróbujemy następnym razem?

Jakie eksperymenty lub usprawnienia chcemy wprowadzić?

Wprowadźmy limit WIP, żeby ograniczyć przełączanie kontekstu.
Zaplanujmy w każdym sprincie osobny dzień na dług techniczny.
Przejdźmy na trunk-based development, żeby skrócić cykle review.

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ł.

Najczęściej zadawane pytania

Ile trwa retrospektywa zespołu inżynierskiego?
Większości zespołów zajmuje 45–60 minut. W przypadku większego zespołu lub po dużym wydaniu warto zarezerwować do 90 minut.
Kiedy przeprowadzać retrospektywę zespołu inżynierskiego?
Najlepiej sprawdza się na koniec każdego sprintu lub iteracji, ale można ją też przeprowadzić po ważnym wydaniu lub incydencie albo jako okresowy przegląd.
Czym różni się od standardowej retrospektywy sprintu?
Opiera się na tych samych zasadach, ale pytania dotyczą kwestii inżynierskich, takich jak jakość kodu, dług techniczny, pipeline'y i współpraca programistów.
Kto powinien uczestniczyć w retrospektywie?
Wszyscy zaangażowani w dostarczanie: programiści, QA, DevOps i liderzy techniczni. Ograniczenie składu do głównego zespołu ułatwia szczerą rozmowę.
Jak prowadzić retrospektywę bez szukania winnych?
Ustalcie zasadę, że usprawniacie systemy i procesy, a nie oceniacie ludzi. Anonimowe zbieranie pomysłów w TeamRetro ułatwia szczerość.
Jak zadbać o to, żeby działania naprawdę zostały zrealizowane?
Ograniczcie się do dwóch lub trzech konkretnych działań, przypiszcie każdemu jasnego właściciela i sprawdzajcie postępy na początku kolejnej retrospektywy.
Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo