Przyjrzyjmy się temu, jak Tomek działa w nowej firmie. Został liderem technicznym w niewielkiej organizacji. Mają fajny produkt i dobry kontakt z biznesem, ale kompetencje zespołu deweloperskiego pozostawiają sporo do życzenia.
Na początek Tomek zajął się testami jednostkowymi. Po tym, jak przejrzał kod, włosy mu się zjeżyły. Zaczął rozmawiać z zespołem i doszedł do kilku wniosków:
- nie umieją pisać testów,
- nie widzą w tym sensu i nigdy nie pracowali w firmach, gdzie testy były standardem,
- z powodu dużej liczby błędów ciągle gaszą pożary, więc tempo developmentu jest słabe,
- biznes nie widzi potrzeby testów — „przecież to kod działa na produkcji, a nie testy.
Po dłuższej analizie (i kilku wieczorach przegadanych Pawłem) Tomek zdecydował, że zacznie od dwóch rzeczy: pokazania sensu testów i zbudowania podstawowych kompetencji.
Miesiąc pierwszy
Tomek regularnie dopisuje testy do miejsc w kodzie, które wkrótce mają być modyfikowane. Gdy ktoś go o to pyta, tłumaczy, dlaczego to robi i co mu to daje. Razem przygotowali tablicę, na której śledzą liczbę błędów, incydentów oraz obszary kodu, których one dotyczą. Tomek wyjaśnił, że to po to, by móc zapobiegać awariom — widzi, jak często zespół musi zmieniać kontekst i chciałby to zmienić, żeby im się lepiej pracowało.
Miesiąc drugi
Zaczęli liczyć, ile ticketów wraca od testera do dewelopera. Okazało się, że taski Tomka prawie nigdy nie wracają. Członkowie zespołu chętnie robią mu code review i zaczynają pytać, dlaczego pewne rzeczy zrobił tak, a nie inaczej. Tomek za każdym razem stara się zadzwonić i wyjaśnić — mówi, że i tak potrzebuje czasem przerwy od pisania kodu i przy okazji może pogadać przy kawie.
Miesiąc trzeci
W obszarach, gdzie Tomek dopisał testy, jest wyraźnie mniej awarii. Podczas rozmów zespół przyznaje, że chętnie by pisał testy, ale nie wie jak. Umawiają się więc, że przy każdej awarii — po naprawie — Tomek siada z daną osobą i wspólnie planują, jakie testy są potrzebne. Część piszą oni, część Tomek.
Powstała wiki z przykładami dobrych testów. Jeden z deweloperów dodał stronę z linkami do materiałów — nawet Tomek niektórych z nich nie znał, więc szczerze mu podziękował.
Miesiąc czwarty
Na każdym review Tomek pokazuje, że dopisują testy i wyjaśnia dlaczego. Opowiada też o tym biznesowi: „W zeszłym miesiącu Julia to porządnie otestowała. Włożyła w to dużo pracy. I zobaczcie — zero błędów na produkcji. Julia, dziękujemy”.
Zespół ustalił, że proste testy dopisują zawsze. Na refinementach zaczynają rozmawiać o sposobach testowani nowych ficzerów. Bardziej złożone testy często pisze Tomek, ale coraz częściej bierze je też Mateusz. Zespół przejmuje wiki i dodaje przykłady oraz dobre praktyki. Proszą Tomka, by dopisał uzasadnienia w niektórych miejscach.
Wprowadzają „Godzinę Testów” — raz w tygodniu biorą fragment kodu i wspólnie dopisują testy, tłumacząc sobie co i jak. Ostatnio nawet Łukasz powiedział, że chce napisać te najprostsze. Był wyraźnie z siebie dumny. Tomek stara się nic nie mówić, dopóki go nie spytają. Docenia tylko wszytkie dobre pomysły albo tłumaczy, dlaczego coś uważa za ryzykowne.
Miesiąc piąty
Podsumowanie: liczba awarii spadła o 18%. Niektóre moduły są już w pełni otestowane.
Pewnego dnia Tomek słyszał, jak jeden z deweloperów rozmawiał przez telefon i rzucił:
„Weźcie napiszcie porządne testy, po co tak marnować czas?”
Tomek uśmiechnął się do niego i pokazał kciuk w górę.
Miesiąc szósty
Tomek powiedział, że chciałby wspólnie ustalić standardy dotyczące testów. Wyjaśnia, o co chce zadbać i dlaczego. Prosi zespół, by zaproponowali, jak to zrobić.
Okazuje się, że są jeszcze moduły w innej technologii, o których nie wiedział. Ustalają, że w bieżącym systemie testy dopisują zawsze, gdy coś zmieniają. A jeśli ktoś miałby problem, to OK, będą sobie wzajemnie pomagali. W końcu najważniejsze jest, żeby iść z tym do przodu i uczyć się nowych rzeczy.
… i miesiąc dwunasty
Liczba incydentów spadła do poziomu, którego firma wcześniej nie widziała — awarie praktycznie nie występują.
Mateusz przygotowuje prezentację, bo chce na lokalnej społeczności opowiedzieć o ich „drodze od zera do bohatera”.
Łukasz opowiedział przy piwie Tomkowi, że jak go zatrudnili jako tech-leada, to zespół był przerażony. Bali się, że ich wywali albo będzie na każdym kroku pokazywał swoją wyższość jako “piewca jakości”. Okazało się, że znaleźli w sieci nagranie, na którym Tomek mówił o swoim stosunku do pisania testów.
Julia powiedziała, że nie spodziewała się, że będzie o nich tak dbał i traktował ich z szacunkiem. I że jeszcze nigdy nie miała takiego lidera, dzięki któremu tak bardzo się rozwinęła. Szkoda, że idzie do innej firmy, ale wiadomo – będą mieli bliżej do dziadków, a planują dziecko. Tomek napisał jej szczere referencje.
Wczoraj Tomek poszedł na piwo z Pawłem. Odkąd nie pracują razem zaczęli się częściej spotykać. Tomek chciał podziękować Pawłowi, że dzięki niemu zrozumiał, jak się stawia wymagania i wspiera ludzi jednocześnie.
To oczywiście jest tylko opowieść, chociaż pokazuje dokładnie realne działania, jakie liderzy podejmują budując motywację zespołu do poprawy jakości. Na naszych warsztatach wyjaśniamy dokładnie, dlaczego Tomek robił to w takiej, a nie innej kolejności. I co tak, naprawdę robił. Pamiętajcie tylko o tym, że w innych kontekstach (korporacja, zróżnicowana wiedza zespołu, konflikt, brak wpływu) praca Tomka wyglądałaby zupełnie inaczej.
Dobra wiadomość jest taka, że można łatwo zdiagnozować w jakim stanie jest obecnie zespół i wykorzystać proste wytyczne do przygotowania strategii pracy z nim. Warto też znać sposoby pracy nad konkretnymi rzeczami – narzekaniem, biernym oporem, konfliktem albo brakiem wiedzy. Przyjdź do nas na warsztaty, wyjaśnimy Ci wszystko, podzielimy się swoim doświadczeniem i pomożemy w zaplanowaniu pracy.
Dodaj komentarz