Zasady dobrego “code review”

Zrzędzenia na tłumaczenia
Jako, że pojęcie code review pochodzi z czasów, kiedy programowaniem w naszym kraju zajmowali się nieliczni pasjonaci i wysokiej klasy specjaliści, do tego pochodzący z pokolenia, które dbało o swój rodzimy język, jest to nieliczne ze sformułowań z kręgu IT, dla których mamy swój rodzimy językowy odpowiednik, który nie razi – inspekcja kodu. I wszystko fajnie – tylko, że chyba nikt już o nim nie pamięta. Raz, że inspekcja to słowo niekoniecznie istniejące w słowniku współczesnych, znających więcej słów w języku angielskim, niż rodzimym. Dwa, że jednak kojarzy się negatywnie – z nadzorem, z kontrolą celem znalezienia uchybień. I z jednej strony – słusznie, bo wszak chodzi tutaj o dodatkowy poziom zabezpieczenia, upewnienia się, że wszystko zadziała “jak należy”. Z drugiej jednak, przy pracy zwinnej (“agile”), przy odchodzeniu od hierarchicznych systemów zarządzania, nie do końca to oddaje ducha tej czynności, aż prosi się o prostsze – przegląd kodu. I tego sformułowania będę się trzymał w dalszym wywodzie, posiłkując się jednakże anglosaską nazwą jako synonimem.

• • •

Istota retrospektywy

Na jednej z ostatnich konferencji agile’owych natrafiłem na grupkę (jak się okazało – w większości Scrum Masterów) żywo dyskutującą o retrospektywach. Jako, że konwersacja była prowadzona publicznie, w trybie otwartym, przyłączyłem się w roli słuchacza. Rzecz była o pomysłach na ciekawe retrospektywy w formie, jak to określono, “psychozabawy” (a słysząc to słowo moje myśli skierowały się ku “Uśmiechowi Numeru” czy innym kultowym nastoletnim gazetkom z lat 90.). Oczywiście od razu padły gorące nazwy: Retromat, Retrospective Wiki czy TastyCupCakes. Uczestnicy przekrzykiwali się w profitach jakie uzyskują dzięki różnym zabawom: padały mądre akronimy, jak  EMIC czy CCP, jedni mówili o kongitywistyce, eneagramach i rozgwiazdach, z kolei inni wymieniali nazwiska takie jak Belbin, Downey, Avery, Tuckman, Oldham, Michno czy Wilmiński. No dobra, te dwa ostatnie chyba brzmiało nieco inaczej. Opuściłem rozgrzane do czerwoności grono w czasie dyskusji nad różnym podziałem ludzkich osobowości, a konkretnie nad tym, który z licznych modeli tego typu najlepiej oddaje charaktery deweloperów w zespole Scrumowym pracującym nad wytwarzaniem oprogramowania.

• • •

Niepokorny deweloper

Scrum to gra zespołowa, działa dobrze, jeżeli wszyscy przykładają się na równym poziomie, bo oczywistym jest, że na efekt pracy zespołu składają się ludzie go tworzący. Co jeśli jeden z członków zespołu deweloperskiego zaczyna przysparzać problemów, psując atmosferę? Nie chciałbym się w tym momencie rozpisywać nad przyczynami takiej sytuacji, może być ich bardzo wiele –  od znużenia projektem, wypalenie zawodowe, po kwestie relacji panujących między członkami zespołu czy też kwestie ich charakterów. Skupmy się na samej sytuacji, gdzie problemem staje się komunikacja oraz egzekwowanie zobowiązań od takiej osoby.

• • •

“Nietechniczny” Scrum Master

Czy nietechniczna osoba ma szansę odnieść sukces jako Scrum Master? Na początek, doprecyzujmy, co mam na myśli używając słowa “nietechniczny”. Mówiąc wprost, odnoszę je do siebie, sam czuje się bowiem taką osobą, pracując na co dzień w zespole tworzącym oprogramowanie. Mimo, że poruszam się sprawnie w tym obszarze, to nigdy nie potrzebowałem poznawać szczegółowych rozwiązań implementacyjnych. Czy to wpływa w jakiś sposób na moją pracę? Z pewnością.

• • •