Wybija godzina 9:00, a my odpalamy komputer i zaczynamy pracę. I co takiego właściwie robimy? Jak wygląda nasz dzień? Jakie są nasze zadania i obowiązki?
Zawsze mówię, że jedną z zalet pracy programisty jest to, że każdy dzień wygląda inaczej, a tutaj już w tytule sugeruję istnienie typowego dnia programisty. To jak z tym w końcu jest? Oczywiście mocno różnią się zadania, nad którymi pracujemy, a każdy dzień to nowe problemy do rozwiązania. Możemy nawet nieco górnolotnie powiedzieć, że każdy dzień to zupełnie nowa przygoda 🙂 Zmieniają się zadania, zmieniają się problemy, zmieniają się technologie, które wykorzystujemy, także nudy nie ma. Z drugiej strony te zmiany są oczywiście częścią większej całości, a w niej zdecydowanie możemy wyróżnić wiele wspólnych elementów. I to jest dobra informacja, bo gdyby faktycznie każdy dzień w projekcie wyglądałby zupełnie inaczej, zamiast ciekawej pracy mielibyśmy jedynie straszny chaos.
Jak zaczynamy dzień?
Krótka odpowiedź na pytanie “Od czego zaczynamy dzień?” brzmi: albo zabieramy się za kontynuację tego, nad czym pracowaliśmy dzień wcześniej albo bierzemy się za nowe zadanie. Pierwsza opcja jest dość oczywista, pytanie jak to wygląda z drugą – skąd bierzemy nowe zadanie, kto nam mówi co mamy robić i jak, a może sami o tym decydujemy, ale kto wtedy nadaje projektowi kierunek?
Zazwyczaj wygląda to tak, że projekt ma kogoś, kto pełni funkcję jego właściciela – taką osobę nazywamy Product Ownerem. To termin z metodyki Scrum, która jest obecnie najpopularniejszą metodyką zarządzania projektami w IT.
Zarządzanie projektami w IT to w ogóle obszerny temat na osobny artykuł – od początku istnienia branży, ludzie szukają coraz lepszych sposobów na zarządzanie projektami, a to nie jest łatwe. Przy tradycyjnych projektach, na przykład budując drogę, oczywiście też może zdarzyć się coś nieprzewidzianego, ale jednak jesteśmy w stanie dość trafnie oszacować, że jeżeli weźmiemy tylu i tylu robotników, to w takim i takim czasie – jeżeli tylko nie trafi się zima stulecia – zbudujemy tyle i tyle kilometrów drogi. W IT jest o tyle trudno, że wymagania często się zmieniają, a same zadania też trudno z dużą dokładnością oszacować, stąd nieustanne poszukiwanie najlepszych sposobów na zarządzanie projektami.
Potrzeby biznesowe klienta a zadania programisty
Wracając do tematu – Product Owner to osoba odpowiedzialna za biznesowy aspekt produktu. Tak nazywamy go w Scrumie, ale nawet jeżeli nie pracujemy w tej metodyce, zazwyczaj tego typu funkcja będzie, bo po prostu musi być. Załóżmy, że do naszej firmy zgłasza się nowa sieć przychodni i chce, abyśmy zrealizowali projekt systemu do rezerwacji wizyt. I to Product Owner – będący przedstawicielem klienta – ustala z osobami odpowiedzialnymi za projekt po stronie naszej firmy, jakie dokładnie funkcjonalności ma mieć tworzona przez nas aplikacja. Tutaj istotne jest zrozumienie potrzeb biznesowych i właściwe przetłumaczenie jej na konkretne funkcjonalności do zaimplementowania. Tym po stronie firmy zajmują się na przykład analityk biznesowy, architekt systemu czy project manager. W każdej firmie te funkcje mogą trochę się różnić, mogą też się wzajemnie ze sobą przenikać, dlatego zamiast myśleć o jakichś sztywnych ramach i podziałach, lepiej jest po prostu rozumieć ogólną ideę – jak to się dzieje, że ktoś chce jakiś produkt i skąd programiści wiedzą, co mają zaprogramować.
Skąd bierzemy zadania do pracy?
Gdy siadamy rano i chcemy zająć się nowym zadaniem, patrzymy na tablicę aktualnego sprintu. To też termin ze Scruma, ale podobnie jak z Product Ownerem – w innych metodykach może się to nazywać inaczej, ale idea będzie podobna. Sprint to okres, w którym pracujemy nad nowym zestawem funkcjonalności. Chodzi o to, żeby na bieżąco weryfikować efekty naszej pracy, sprawdzać postępy i w razie potrzeby korygować nasz długofalowy plan. Sprint nie może być ani za krótki ani za długi – większość zespołów pracuje w sprintach 2 lub 3-tygodniowych, ja preferuję sprinty 2-tygodniowe.
Do zarządzania zadaniami w IT najczęściej wykorzystuje się do narzędzie o nazwie Jira, ale darmowe rozwiązania takie jak Trello też są jak najbardziej ok, zwłaszcza do mniejszych projektów. Bierzemy zadanie z tablicy i nad nim pracujemy 🙂 I tutaj też pamiętamy, że nad projektem nie pracujemy sami, pracujemy w zespole, a kluczem do sukcesu jest właściwa komunikacja. I czasem wszystko będzie jasne, nie będziemy mieć żadnych wątpliwości i po prostu usiądziemy do danego zadania i zaczniemy pisać kod, ale czasem będziemy chcieli o pewne rzeczy kogoś dopytać – Project Managera, Scrum Mastera czy Product Ownera. Czasem będziemy też chcieli pewne rzeczy skonsultować z innymi osobami z zespołu, tak żeby wybrać najlepsze możliwe rozwiązanie. O tym przede wszystkim powinniśmy pamiętać – o otwartej komunikacji.
Jak wygląda praca nad zadaniem?
Przede wszystkim musimy zastanowić się, jak daną rzecz chcemy zaimplementować.
Czasem pracujemy w dobrze już nam znanej części systemu, czasem musimy poznać pewne elementy albo przypomnieć je sobie – szacuje się, że podczas dodawania nowej funkcjonalności pisanie nowego kodu zajmuje 10% czasu, reszta czyli 90% to czytanie już istniejącego kodu. Dlatego tak ważne jest, żeby zawsze dbać o jakość i czytelność kodu, bo to bardzo ułatwia pracę w przyszłości.
Budujemy sobie powoli w głowie rozwiązanie, a potem przechodzimy do pisania kodu – zazwyczaj zaczynamy od jak najprostszych przypadków, pomijając tak zwane przypadki graniczne – naszym celem jest napisanie kodu, który po prostu działa. Gdy już ta podstawowa wersja kodu działa, rozwijamy go, zastanawiamy się, czy na pewno wzięliśmy wszystko pod uwagę, czy obsłużyliśmy wszystkie możliwe błędy i refaktoryzujemy kod, czyli zmieniamy go tak, żeby był czytelny, przejrzysty, pozbawiony zbędnych elementów i zduplikowanych fragmentów. Dokładnie go przeglądamy, czytamy, zastanawiamy się, czy dobraliśmy właściwe nazwy.
Korzystanie z Google to nie wstyd
Oczywiście nie wszystko piszemy z głowy – nikt nie pamięta 100% możliwości danej biblioteki czy frameworku. Jeżeli wiemy co chcemy osiągnąć, ale nie do końca wiemy jak, bo nigdy tego nie robiliśmy albo tego nie pamiętamy, wpisujemy odpowiednie zapytanie w Google i zazwyczaj znajdujemy co najmniej kilka bardzo konkretnych odpowiedzi. Korzystanie z Google to żaden wstyd, a wręcz przeciwnie – to kolejna istotna umiejętność w arsenale programisty. I tutaj musimy pamiętać o tym, co powiedziałem przed chwilą – musimy wiedzieć, co chcemy osiągnąć i o co chcemy zapytać. Na pewno nie jest tak, że napiszemy w Google “chcę stworzyć drugiego Facebooka” i pojawi się gotowy kod. Ale jak już napiszemy “autentykacja użytkownika z użyciem protokołu OAuth2 Java” dostaniemy bardzo konkretne wyniki.
Komunikacja raz jeszcze
Pracując nad zadaniem cały czas pamiętamy o właściwej komunikacji. Czasem nie będziemy potrzebować niczyjej pomocy ani opinii, czasem będziemy potrzebowali coś konsultować, a innym razem konieczne będzie usiąść z drugą osobą i wspólnie napisać kod. Jeżeli pracujemy w obszarze systemu, gdzie ktoś inny też wprowadza zmiany, musimy to odpowiednio dograć, tak, żeby sobie wzajemnie nie przeszkodzić i zarówno sobie jak i drugiej osobie oszczędzić zbędnej pracy. Tak więc ta wspominana kilkukrotnie komunikacja jest tutaj kluczem.
Code Review i testowanie
Gdy zakończymy pracę nad zadaniem albo – to bardziej trafne określenie – wydaje nam się, że zakończyliśmy nad nim pracę, przychodzi czas na jego weryfikację. I tutaj mamy dwa etapy – pierwszy to Code Review czyli weryfikacja ze strony innych programistów w zespole. Technicznie wygląda to tak, że przed mergem zmian z naszego brancha do głównego brancha (obejrzyj odcinek o Gicie), tworzymy tak zwany Pull Request i inne osoby z zespołu mogą przejrzeć nasz kod, podzielić się uwagami, zwrócić na uwagę na coś, czego my nie zauważyliśmy i zasugerować poprawki. W ten sposób wspólnie dbamy o jakość i czytelność kodu. Gdy nasz Pull Request zostanie zaakceptowany i zmergujemy już zmiany do głównego brancha, do gry wchodzi tester, który sprawdza, czy nowa funkcjonalność działa tak jak powinna. I bardzo często zdarza się, że tak nie jest 🙂 Dobry tester ma niesamowitą zdolność znajdywania błędów tam, gdzie byśmy się tego nie spodziewali. Sprawdza przypadki graniczne, stara się robić w systemie rzeczy, na które byśmy nie wpadli i nagle okazuje się, że nasze rozwiązanie zawiera luki, które trzeba poprawić. Poprawiamy, tester znowu sprawdza i gdy wszystko jest już ok, cykl życia zadania się kończy, a my z uczuciem satysfakcji możemy zabrać się za kolejne.
Sprint Review
Po określonym czasie – najczęściej 2 lub 3 tygodniach – kończy się sprint i następuje jego podsumowanie w postaci spotkania nazwanego Sprint Review. Na tym spotkaniu obecny jest zespół oraz przedstawiciel klienta czyli Product Owner. Po kolei przechodzimy przez listę wszystkich zadań zaplanowanych na sprint i pokazujemy efekty naszej pracy. Podsumowujemy, co udało nam się zrealizować, a na co nie starczyło nam czasu, bo oczywiście nie jest tak, że zawsze uda się skończyć wszystkie zadania. Im dłużej pracujemy jako zespół, im bardziej znamy projekt, tym lepiej potrafimy oszacować czas potrzebny na wykonanie zaplanowanych zadań i zazwyczaj im późniejsza faza projektu, tym tych zaskoczeń i niewiadomych jest mniej, ale raz na jakiś czas się zdarzają. I jest to sytuacja całkowicie normalna.
Planowanie pracy na kolejny sprint
Mieliśmy codzienną pracę w sprincie, mieliśmy sprint review, to jeszcze pora na spotkanie, od którego zaczyna się sprint czyli sprint planning. Jak sama nazwa wskazuje, podczas tego spotkania planujemy rozpoczynający się sprint, wybieramy wraz z Product Ownerem, Project Managerem i Scrum Masterem zadania i estymujemy (czyli szacujemy) ich złożoność, dzięki czemu – mając już doświadczenie ze wcześniejszych sprintów – jesteśmy w stanie mniej więcej przewidzieć, ile uda nam się zrealizować. To jest proces, podczas którego cały czas się uczymy, ze sprintu na sprint i przy dobrze prowadzonym projekcie, nasze estymaty ze sprintu na sprint stają się coraz bardziej dokładne.
Retrospekcja
Mówiąc o nauce ze sprintu na sprint, można wspomnieć również o jeszcze jednym spotkaniu, które niektórzy wprowadzają do harmonogramu – Sprint Retrospective. Podczas tego spotkania dyskutuje się o tym, co w sprincie było dobre, co nie zagrało, co warto kontynuować, a czego nie. Celem tego spotkania jest ciągłe ulepszanie sposobu i kultury pracy w kolejnych sprintach, ale osobiście nie jestem zwolennikiem tego spotkania. Po pierwsze, uważam, że osobne spotkanie nie jest potrzebne, ponieważ tego typu uwagami w dobrze funkcjonującym zespole można dzielić się na bieżąco i natychmiast wprowadzać potrzebne zmiany, po drugie z czasem – jeżeli zespół komunikuje się dobrze – praca przebiega coraz lepiej i coraz sprawniej i nie ma sensu siedzieć godzinę na spotkaniu i wymyślać rzeczy na siłę (a wiele takich spotkań przeżyłem), po trzecie jestem osobą, która zamiast dyskutować, analizować i dywagować, po prostu woli pracować. Oczywiście pewna doza analizowania i planowania jest ważna, bo nie można robić wszystkiego na żywioł, ale w zdecydowanej większości przypadków im szybciej zaczniemy pracę tym lepiej. Szybciej zauważamy potencjalne problemy, szybciej popełnimy błędy, które i tak byśmy popełnili bez względu na to, jak długo byśmy planowali. Dzięki temu szybciej te problemy rozwiążemy, a błędy naprawimy.
Mniej gadania, więcej pracy
Dlatego tym bardziej cieszę się, że w dobrze prowadzonym projekcie tych spotkań jest naprawdę minimalna ilość. Sprint Planning i Sprint Review są, bo być muszą i są bardzo ważne, ale poza tym nie tracimy czasu na dyskusjach, które w 99% sytuacji i tak niczego nie wnoszą.
Jak powiedział Elon Musk w wystąpieniu skierowanym do prezesów firm:
Spędzajcie mniej czasu w salach konferencyjnych, mniej czasu w Power Poincie, a zamiast tego po prostu poświęćcie więcej czasu na pracę nad produktem, tak aby był on tak dobry jak to tylko możliwe.
I to samo dotyczy nie tylko prezesów, ale też architektów, Scrum Masterów, Project Managerów oraz tworzących rozwiązania programistów. Mniej gadania, mniej zastanawiania się, więcej konkretnej pracy, bo to ona przynosi konkretne efekty.
Powyższy materiał jest też dostępny w formie filmu:
