Podsumowując mijający rok 2017, uznałem że najciekawszą książką „zawodową” którą przeczytałem, była Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja, napisana przez Sandro Mancuso w 2014 roku. Jestem nawet w stanie zaryzykować stwierdzenie, że książka ta w pewien sposób zmieniła moje życie, a co najmniej spojrzenie na pracę którą wykonuję.

Czytając tą książkę, z kolejnymi rozdziałami utwierdzałem się w przekonaniu, że gdybym na podstawie swojej 17-letniej kariery zawodowej miał spisać swoje doświadczenia, przygody, porażki i rady dla współpracowników, to tak właśnie ona powinna wyglądać. Więc po zakończeniu czytania doszedłem do zabawnego wniosku, że nie muszę już tego robić – wystarczy że tylko namówię ich do przeczytania tej pozycji :-).

Skracając część fabularną: autor przedstawia przebieg swojej kariery od początków w małym mieście w Brazylii, gdzie pracował jako młodszy programista, gdy jego marzeniem była praca w dużym banku inwestycyjnym w Londynie, aż do zdobycia tej pracy oraz zawiązania ruchu Software Craftsmanship.

Skąd się wziął ruch Software Craftsmanship?

Również w dużym skrócie: po ogłoszeniu w 2001 roku Manifestu Programowania Zwinnego, firmy informatyczne i zespoły programistyczne sukcesywnie odchodziły od kaskadowej metodyki tworzenia oprogramowania na rzecz: szybszych wydań nowych wersji, lepszego reagowania na oczekiwania klientów, bliższej współpracy z nimi oraz odstąpienie od tworzenia niepotrzebnej dokumentacji:

My, jako programiści, zaczęliśmy odczuwać pozytywne zmiany, ponieważ wyniki naszych prac były szybciej „na produkcji”, mieliśmy szansę zobaczyć i porozmawiać z przedstawicielami klienta i odczuć jego zadowolenie, zebrać pochwały i – niekiedy – gniew (jak coś nie działało). Klient widział zespół który dla niego pracuje i szybciej dostawał „wartość biznesową”, która przynosiła mu konkretne przychody.

Teoretycznie wszyscy powinni być zadowoleni ale nie do końca się tak stało. Autor książki nazwał to zabawnie „kacem” po przejściu na metodykę zwinną. Znowu w największym skrócie: zarówno klient jak i zespół, przymuszony harmonogramem szybkich wydań i realizacji „celów biznesowych”, przestał pamiętać o jakości oprogramowania. Teoretycznie w tym samym okresie popularyzowały się techniki eXtreme programming (np. TDD), więc jakość powinna rosnąć ale tak nie było. Dlaczego? Widziałem to także na przykładzie własnych projektów: żeby szybko wydawać nowe wersje i „zaspokajać” oczekiwania klienta przymykaliśmy często oko na „definition of done”, np. uzupełnianie testów jednostkowych czy akceptując drobne niedoróbki, tworząc sobie tym samym dług technologiczny, który w lepszych czasach spłacaliśmy. Z punktu widzenia biznesowego to miało sens, ponieważ często tworzyliśmy prototypy (które po sukcesie wchodziły na produkcje…), ale także weryfikowaliśmy ryzykowne rozwiązania biznesowe, które często były wycofywane, itp. Jednak z punktu widzenia wielu inżynierów takie podejście było nieprofesjonalne i pozostawał niesmak.

Esencją tego niezrozumienia oczekiwań pracowników technicznych przez klienta, oraz nawet naszych kolegów nietechnicznych w firmie, był moment, gdy w jednym z projektów oddolnie forsowaliśmy migracje na Javę w wersji 8. Wersja ta od kilkunastu miesięcy była gotowa do rozwiązań produkcyjnych i wychwalana przez społeczność programistów jako krok milowy. Sama migracja może nie była kosztowna ale wymagała przygotowania, zmian w serwerach aplikacyjnych oraz zaangażowania klienta w testy, co generowało koszty oraz ryzyko, a z jego punktu widzenia nie przynosiło żadnej wartości biznesowej. I patrząc obiektywnie klient mógł mieć racje, bo zupełnie nie traktował komfortu pracy programistów, więc także kłopotów w kompletowaniu zespołu, jako wartości biznesowej. Migracje oczywiście w końcu udało się przeprowadzić ale okupione to zostało utratą dwóch bardzo dobrych programistów z zespołu :-(. Na szczęście po tym doświadczeniu taka sytuacja już więcej się nie powtórzyła.

Co to jest Software Craftsmanship?

Zasady przyświecające ruchowi Software Craftsmanship, czyli „Rzemieślników Oprogramowania”, zostały spisane w ładnym manifeście w 2008 roku:

Jako że są mi bardzo bliskie, to rozwinę je z własną interpretacją:

• Nie tylko oprogramowanie działające, ale również dobrze wykonane – konieczność spełniania celów biznesowych nie powinna uzasadniać pośpiechu i wynikających z tego niedoróbek, odkładania poprawek do długu technologicznego, ignorowania konieczności większych refaktoringów czy zmian architektury; nasze „definition of done”, czyli np. testy jednostkowe czy błędy wykazane w statycznej analizie kodu powinny być ważniejsze niż „dopchnięcie kolanem historyjek do sprintu”, nawet kosztem tego że coś „spadnie” do kolejnego etapu.
• Nie tylko reagowanie na zmiany, ale również ciągłe dodawanie wartości – członkowie zespołu powinni mieć kontakt z klientem, znać cele biznesowe projektu, mieć możliwość przedstawiania propozycji swoich rozwiązań problemów biznesowych, aby nie być tylko pasywnymi wykonawcami pomysłów przyniesionych „z góry”. Takie podejście zwraca się dużo większym zaangażowaniem zespołu.
• Nie tylko ludzi i interakcje ale również społeczność profesjonalistów – niezależnie od istnienia „exceli” z zestawieniem członków zespołu jako mitycznych man-days umieszczanych na harmonogramach projektów, projekt oraz sami członkowie zespołu muszą uwzględniać aspekty społeczne istnienia zespołów: rozwój osobisty i wzajemny mentoring jego członków (m.in. przez spotkania okresowe i realizacje celów), zdobywanie wiedzy na zewnątrz i przynoszenie jej do wewnątrz (udział w konferencjach, szkoleniach, JUG’ach oraz wewnętrznych spotkaniach jak nasze „Warszawianki”), marketing technologiczny firmy czy zespołu, rekrutacje nowych osób, itp.
• Nie tylko współpracę z klientami ale również efektywne partnerstwo – konieczność partnerskiego traktowania zespołu technologicznego przez klienta i management najprościej wytłumaczyć na powyższym przykładzie konieczności migracji na Javę 8. Partnerstwo jest wtedy gdy raz na 10 sprintów zespół mówi że potrzebuje jeden sprint na „wyprostowanie kwestii technologicznych” i oczekuje za to normalnej zapłaty. Klient, po otrzymaniu rozsądnego uzasadnienia, założeń, analizy ryzyka, scenariuszy testów i kryteriów akceptacji, przystaje na to jak i współpracuje jak przy innym etapie który przynosi „wartość biznesową”.

Powyższe zasady głównie dotyczą miejsca pracy, projektu, zespołu oraz w warunków pracy na co dzień. Ale dotyczą także każdego indywidualnie.

Jak zmieniło moje życie?

Najmocniejszym stwierdzeniem tej książki jest to że profesjonalista „powinien sam, za własne pieniądze, kosztem własnego czasu, zabiegać o podnoszenie swoich kwalifikacji”. Jest to tak dalekie od naszych przyzwyczajeń, rozpieszczenia programistów wysokimi stawkami na rynku oraz mnogością ofert, oczekiwaniem „millenialsów” idealnego work-life balance, że aż nie mogłem wierzyć własnym oczom:

Z mojej osobistej perspektywy otworzyło to dwie ścieżki. Po pierwsze mogę oficjalnie powiedzieć rodzinie, że jako „praktykujący profesjonalista” będę spędzać kilka wieczorów w tygodniu poza domem: czytając książki i robiąc tutoriale w kawiarniach (pozdrawiam baristów Green Cafe Nero…), chodząc na spotkania WJUG i inne meet-upy z okolic inżynierii oprogramowania. Z drugiej strony, mogę zaproponować kolegom i koleżankom w pracy żeby zostać niekiedy dłużej w pracy, czy przyjść w weekend i zająć się jakimś ciekawym zagadnieniem czy projektem, dzięki któremu wspólnie się czegoś nauczymy, nie wchodząc jednocześnie w rozważania czy nie powinniśmy robić tego w godzinach pracy, a firma powinna nam za to płacić. Oczywiście nie wszyscy będą tym zainteresowani, bo na różnych etapach życia ceni się różne wartości (małe dzieci skutecznie „uziemiają” w domu rodzinnym…) ale kilka osób rządnych wyzwań może się znaleźć (przynajmniej w okresie zimowym ;-)).

Powstała Gildia Software Craftsmanship w e-point S.A.

Po moim grudniowym wystąpieniu omawiającym idee Software Craftsmanship na spotkaniu pracowników technicznych e-point udało mi się namówić kilka osób na cykliczne spotkania w ramach firmy. „Gildie” w e-point to rozwiązanie organizacyjne pozwalające na organizowanie grup osób, które są zainteresowane wspólnym tematem i firma pomaga im m.in. przez dofinansowanie z budżetu „socjalnego”. Dotychczas większość gildii było związane z tematyką sportowo-hobbystyczną (zawody rowerowe i biegowe, siatkówka, gry planszowe, itp.), jednak uznałem że rozwój zawodowy mieści się w założeniach Gildii.

Na razie ustaliliśmy założenia organizacyjne, listę pierwszych tematów i harmonogram spotkań i zaczynamy. Zamierzam na łamach bloga dzielić się dalszymi informacjami jak nam idzie.

Podsumowanie

Wracając do książki: jest bardzo ciekawa, dobrze napisana (i przetłumaczona…), dobrze się ją czyta i nie jest przesadnie długa. Zachęcam do jej przeczytania wszystkich „niemłodszych” programistów i programistki (młodsi powinni zacząć od „Pragmatyczny programista”…), w szczególności kierowników zespołów. Książka ta pomoże przemyśleć jak pracować i kierować rozwojem swojej kariery.

Zachęcam do jej przeczytania także managerów i dyrektorów, żeby zrozumieli jakie wartości są ważne dla pracowników technicznych, tak aby pomóc stworzyć warunki pracy w których wszyscy będą dobrze się czuli i projekty będą z sukcesem „dowożone”.