Czym jest retrospektywa code review?
Retrospektywa code review to spotkanie, na którym zespół przygląda się temu, jak przegląda kod, a nie samemu kodowi. Pull requesty czekające całymi dniami, komentarze bez kontekstu, przeglądy sprawdzające wyłącznie styl: takie problemy rzadko wychodzą na zwykłej retrospektywie sprintu, bo są rozłożone na cały tydzień pracy wszystkich osób, a nie związane z jednym zdarzeniem. Tablica ma cztery kolumny. „Co idzie dobrze?” zbiera nawyki warte zachowania, takie jak przydatna checklista czy życzliwy ton. „Co nie idzie dobrze?” obejmuje bolączki, od zbyt dużych pull requestów po niespójne standardy. „Co możemy poprawić?” zamienia je w konkretne zmiany, na przykład limit wielkości zmian albo uzgodniony czas odpowiedzi na przegląd. „Jakie pytania się pojawiły?” to miejsce na otwarte pytania, które zespół musi zbadać, zanim podejmie decyzję. Przeprowadź ją po dużym wydaniu, gdy opóźnienia w przeglądach zaczynają spowalniać dostarczanie, albo gdy dołączają nowe osoby i niepisane standardy przeglądów zespołu trzeba wreszcie spisać. Nie szukajcie winnych: tematem jest proces, a nie czyjeś komentarze do konkretnego pull requesta.
Format retrospektywy code review
Co idzie dobrze?
Co sprawdza się w naszych przeglądach kodu?
Zacznij od tego, co działa. Poproś o konkretne praktyki przeglądowe, które pomogły, i doceń osoby, których przeglądy coś zmieniły.
Co nie idzie dobrze?
Z jakimi trudnościami mierzyliśmy się podczas przeglądów kodu?
Zadbaj o to, by można było mówić o problemach bez obwiniania kogokolwiek. Poproś o konkretne przykłady, np. przegląd, który trwał kilka dni, albo komentarz, z którym trudno było cokolwiek zrobić.
Co możemy poprawić?
Jak możemy usprawnić nasz proces i praktyki code review?
Poproś o konkretne sugestie, które da się wdrożyć. „Lepsze przeglądy” to nie działanie; „dzielimy pull requesty, które dotykają więcej niż jednej funkcjonalności” już tak.
Jakie pytania się pojawiły?
Jakie nowe pytania lub obszary do zbadania się pojawiły?
Zapisz pytania, na które zespół nie potrafi dziś odpowiedzieć, i ustalcie, kto zajmie się każdym z nich przed następną retrospektywą.
Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego
- Gdy przeglądy spowalniają dostarczanie lub wywołują tarcia i chcesz dowiedzieć się dlaczego.
- Gdy chcesz, żeby programiści podzielili się praktykami przeglądowymi, które się u nich sprawdzają.
- Po dużych wydaniach lub projektach, żeby sprawdzić, jak przeglądy wytrzymały presję.
- Gdy dołączają nowe osoby i trzeba uzgodnić standardy przeglądów, oczekiwania oraz czas odpowiedzi.
Proponowane pytania lodołamacze
- Jaki najciekawszy kod przeglądałeś ostatnio?
- Gdybyś mógł dodać jedną funkcję do swojego edytora kodu, co by to było?
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
- Prowadź rozmowę bez szukania winnych, żeby ludzie szczerze mówili o przeglądach, które były dla nich trudne.
- Doceniaj dobre przeglądy, np. jasne komentarze czy szybką odpowiedź, a nie tylko omawiaj problemy.
- Zaproś wszystkich, którzy piszą lub przeglądają kod, w tym testerów.
- Uzgodnijcie jedną lub dwie konkretne zmiany zamiast długiej listy dobrych intencji.
- Wracaj do zadań do wykonania i śledź postępy na kolejnych retrospektywach.
- Zmieniajcie osobę prowadzącą, żeby dyskusję prowadziły różne perspektywy.
Najczęściej zadawane pytania
Czym jest retrospektywa code review?
Kiedy przeprowadzić retrospektywę code review?
Jakie pytania zadać podczas retrospektywy code review?
Ile trwa retrospektywa code review?
Czym różni się od retrospektywy sprintu?
Powiązane szablony
Oderwij się od sprintów i sprawdź, jak tworzycie produkty.
Retrospektywa długu technicznego
Znajdź, uszereguj i zaplanuj spłatę długu technicznego
Retrospektywa naprawy błędów
Dowiedz się, skąd biorą się błędy, i nie dopuść do ich powrotu
Retrospektywa DevOps
Przeanalizujcie wdrożenia, incydenty i przekazywanie pracy między dev a ops.