fbpx

Hierarchia utrudnia rozwój zespołu

Jakiś czas temu napisałem post dotyczący wprowadzenia do zespołu sesji refaktoryzacji kodu. Przez pewien czas zespół był zmotywowany i sesje refaktoryzacji do Czystego Kodu były bardzo popularne. Potem jednak spotkania nagle zniknęły… Jak to możliwe skoro wszyscy z nas bardzo polubili spotkania dotyczące jakości kodu?

Po pewnym czasie temat spotkań dotyczących refaktoryzacji kodu jednak powrócił. W zmienionej formie zadomowił się na stałe w postaci sesji inspektoryzacji kodu (to nasza nazwa własna). I chociaż te sesje nie odbywają każdego dnia ani w każdym tygodniu, to stały się integralną częścią budującą ducha zespołu.

W tym poście chcę napisać o trzech rzeczach

  • Dlaczego sesje refaktoryzacji kodu zniknęły?
  • Czym są nowe sesje inspektoryzacji kodu?
  • Dlaczego sesje inspektoryzacji kodu na dobre “zadomowiły się” w pracy naszego zespołu?

Myślę, że kluczem i tym co łączy odpowiedź na wszystkie trzy powyższe pytania jest motywacja do refaktoryzacji kodu. Sesje refaktoryzacyjne (wg naszej definicji) wymagały aby prowadzący przygotował każde takie spotkanie. Oczekiwaliśmy od prowadzącego gotowego planu refaktoryzacji, poszczególnych kroków oraz definicji końcowego celu. To powodowało, że kiedy rozpoczynała się dyskusja “dlaczego tak a nie inaczej” prowadzący który chciał zaprezentować swój pomysł przyjmował postawę defensywną.

Perfekcjonizm zabija motywację

Przeprowadzenie takiego spotkania wymagało dużo pracy i wysiłku. Co więcej na każde trzeba było się przygotowywać coraz bardziej, coraz lepiej z powodu coraz dłuższych dyskusji. Z tego powodu każdy z nas coraż rzadziej decydował się na przygotowanie i przeprowadzenie takiego spotkania  

Błędne koło perfekcjonizmu

Powyższe podejście nazywane się błędnym kołem perfekcjonizmu. Kiedy chcesz być coraz lepszy każdego dnia, to w końcu boisz się zrobić pierwszy krok. Ostatecznie w obawie przed porażką unikasz nawet początkowych działań.

Vicious Circle of Perfectionism

Nasze sesje refaktoryzacyjne miały właśnie (chociaż nieświadome) takie oczekiwanie sukcesu. Być może zostało ono przeniesione ze szkoleń z refaktoryzacji które prowadziłem. To podczas moich szkoleń zaplanowane refaktoryzacje zawsze kończyły się sukcesem. Wszak było to przygotowane szkolenie więc trudno aby prezentowane refaktoryzacje prowadziły donikąd.

Uczymy się z porażek

Pamiętam, kiedy w jednej z firm manager zachęcał swóh zespół aby raz w tygodniu przeznaczali czas na eksperymenty. Podkreślał że te ekperymenty mają mieć 50% szans na sukces oraz 50% szans na porażkę. I tutaj miał 100% racji. Jeżeli Twój eksperyment nie może się zakończyć porażką to nie nie jest eksperymentem! Najważniejszą konsekwencję eksperymentu powinno być wyciąganie wniosków – zarówno z sukcesu jak i z porażki.


Pobierz bezpłatne materiały z V/Blogów i dołącz do newlettera

Webinary, Artykuły oraz Kursy Online i Stacjonarne

Wysyłaj do mnie newletter (możesz się wypisać w każdej chwili).

Akceptuję Politykę Prywatności i Regulamin


Sesje refaktoryzacji 2.0 🙂

Po kilkunastu tygodniach braku naszych sesji refaktoryzacyjnych jeden z członków mojego zespołu (dziękuję Jakub!) zaproponował inne podejście. Zasugerował zorganizowanie sesji “inspekcji kodu” z którymi miał do czynienia w swoim poprzednim zespole. Formuła tego spotkania definiowała poniższe role

  • Czytelnik Kodu – odpowiedzialny za czytanie i interpretację działania kodu źródłowego na żywo
  • Notariusz – odpowiedzialny za zapisanie poprzewek kodu do wykonania
  • Autor Kodu – odpowiadający na bieżące pytania osoby czytającej kod
  • Moderator – odpowiedzialny za przebieg spotkania

Pomimo bardzo restrykcyjnej formuły spotkanie przebiegło bardzo sprawnie. Ale jak wiadomo nikt nie lubi sztywnych reguł….My chcemy być “agile”. W związku z tym podczas następnych sesji “inspekcji kodu” zaczęliśmy zmieniać reguły spotkania. Eksperymenty doprowadziły do utworzenia nieco luźniejszej formuły spotkań. Dodaliśmy to co nam się podobało podczas sesji refaktoryzacyjnych – czyli czyszczenie kodu w czasie rzeczywistym.

W ten sposób powstały nasze sesje “inspektoryzacji kodu”. Inspektoryzacja = inspekcja + refaktoryzacja. Sesje te mają następujące zasady

  • Każda osoba może prowadzić spotkanie
  • Od prowadzącego nie wymagamy znajomości danego kodu
  • Nie ma obowiązku zakończenia z lepszym kodem
  • Oczekujemy zaangażowania i pomysłów na Czysty Kod poprzez refaktoryzację

Nowy rodzaj motywacji

Powyższe podejście nazywa się “anty-perfekcyjnym kołem myślenia”. Jedynym oczekiwaniem było lepsze zrozumienie danego kodu.

Wspólnie szukamy przyczyn braku czytelności i przeprowadzamy refaktoryzację do Czystego Kodu na żywo. Teraz wszystkie zmiany są wynikiem naszej wspólnej dyskusji. Dzięki temu wymieniamy się doświadczeniem oraz budujemy wspólne zrozumienie jakości naszego kodu.

Celem więc staje się ciągły postęp, a nie perfekcyjnie ustanowiony cel!

Spread the word. Share this post!