GeeCON – dzień drugi

Bez zbędnych wstępów i ozdobników przechodzimy do drugiego dnia konferencji GeeCON.

Na początku drugiego dnia Emily Jiang prezentowała OSGi Best Practices. OSGi jest systemem tworzenia dynamicznych modułów, który wypełnia lukę w systemie Java.  Ale ponieważ prezentacja nie zaczęła się zachęcająco, zmieniłem ją na wykład Thomasa Sundberga „How to fail a software project fast and efficient?”. Na tym wykładzie padło wiele konkretnych stwierdzeń – poniżej niektóre z nich. Zacznij od planowania: miej dokładny plan na najbliższe 12 miesięcy i przestrzegaj go dokładnie.  Najlepiej jeżeli ten plan sporządzi najlepszy deweloper, ponieważ ma on największe doświadczenie. Jeżeli coś rzeczywistość odbiega od planu, możesz zawsze nadgonić ten plan nadgodzinami. Ale nie pozwalaj na pracę z domu, ponieważ obniża to produktywność i nie pozwala na kontrolę pracy. Rozwój narzędzi nie jest potrzebny – przecież już rozwijamy system obecnym narzędziami i są one wystarczające. Standardy kodowania są oczywiście potrzebne, ale są tak ważne, że nie można zostawić ich w ręku programistów, musi je ustalić komitet sterujący projektu. Oczywiście musimy mieć 100% pokrycie kodu testami – każda mniejsza liczba jest porażką projektu. Ponieważ kod się zmienia, testy automatyczne muszą powstać po zakończeniu kodowania – pisanie ich wcześniejszej to strata czasu. Sprzęt jest ważny i, co naturalne, najmocniejsze komputery muszą mieć menadżerzy. Ważne jest to, żeby wszyscy deweloperzy używali tych samych narzędzi i tego samego środowiska deweloperskiego. Specyfikacja systemu musi być spisana – najlepiej na papierze. Jeżeli już musimy korzystać z systemu kontroli wersji (bo czasami wystarcza do tego dysk współdzielony), to najlepszym takim systemem enterprise jest Clear Case. I oczywiście w organizacji bardzo ważni są architekci – a najlepsi są „ivory tower architects”, czyli architekci oderwani od bieżącego dewelopmentu (który ich rozprasza) i przebywający w wysokich wieżach z kości słoniowej. Ponieważ ważna jest formalizacja i dokumentacja, architekci powinni komunikować się ze światem za pomocą dokumentacji projektowej, najlepiej napisanej w UML-u.

Morał: jest tyle pięknych sposobów na porażkę projektu – szkoda tylko, że tak wiele z nich jest tak dobrze znane z praktyki…

Paweł Wrzeszcz i „Visibility Shift in Distributed Teams”, czyli o prezentacja na temat pracy zdalnej. Paweł zaczął od rozróżnienia dwóch rzeczy, które nie są tym samym: pracy w rozproszonym zespole oraz pracy zdalnej. Można pracować w rozproszonym zespole (ale nie zdalnie), można pracować zdalnie (ale nie w rozproszonym zespole), można też połączyć obie rzeczy razem. Dlaczego praca zdalna może być atrakcyjna? Dlatego, że oszczędzamy czas (na przykład na dojazdach do pracy…), oszczędzamy przestrzeń biurową, możemy współpracować z ludźmi niezależnie od ich lokalizacji (no cóż, strefy czasowe mogą być tutaj pewnym ograniczeniem…), możemy pracować dla różnych firm niezależnie od ich lokalizacji. Ale pojawiają się też poważne wątpliwości – zarówno pracowników („Czy będę umiał skoncentrować na pracy będąc w domu? Czy będę potrafił rozdzielić  życie prywatne od pracy? A może cały czas będę czuł się w domu jak w pracy?”), jak i pracodawców („Czy pracownicy będą pracować wydajnie? A może będą przeglądać Facebook’a?”).

Co pomaga w pracy zdalnej? Szalenie istotne jest rozdzielenie pracy od domu – rozdzielenie zarówno czasu pracy (i komunikacja rodzinie: „halo, teraz jestem w pracy”, „a teraz wróciłem do domu”), jak i rozdzielenie, jeżeli chodzi o fizyczne miejsce pracy. Warto pamiętać, że praca zdalna nad nudnymi projektami jest dużo trudniejsza od pracy w biurze. Ale z drugiej strony praca zdalna wymaga określenia i tworzenia widocznych rezultatów swojej pracy (commit’y, wpisy do wiki, aktualizacja statusu zadań). Wymaga też dobrego określenia celu naszej pracy i stawia nam trudne pytanie: na ile sobie wzajemnie ufamy…

Kluczowa w pracy zdalnej jest skuteczna komunikacja. Doświadczeniem Pawła jest to, że komunikacja wideo jest dużo efektywniejsza niż połączenia głosowe, a istniejące narzędzia do komunikacji (Skype, Google Hangouts, Mumble) nie są jeszcze doskonałe. Dobrze sprawdzają się krótkie „stand up meetings” – natomiast organizacja innych spotkań jest trudna i rzadko te spotkania są użyteczne. Dobrze sprawdzają się różne chatroom’y do komunikacji osmotycznej – co więcej możemy czasowo wyłączać się z tych kanałów, żeby skupić się nad bieżącą pracą. Czasami w pracy musimy zrobić burzę mózgów – można to zrobić, są narzędzia do wspólnego pisania, rysowania, estymowania i, co więcej, można to zrobić asynchronicznie. Co ciekawe, dużo skuteczniejsza jest komunikacja przez kanał głosowy, dokumentację na wiki, aktualizację zadań niż przez emaile.

Praca zdalna wymaga dobrego określenia kanałów komunikacji, tego w jaki sposób będziemy mogli się ze sobą kontaktować. Ale wymaga też czegoś więcej: ciągłej pracy nad usprawnieniem sposobów i narzędzi komunikacji.

Morał: praca zdalna jest możliwa. Działa. I często pokazuje wyraźnie niektóre aspekty naszej pracy – wymaga zdefiniowania celu pracy, kanałów komunikacji, zwiększa transparentność.

Andrea Provaglio i „Overcoming Self-organization Blocks”. Self-organization – czyli pozwolenie zespołowi na wybór sposobu, w jaki pracuje.  Tworzymy software – czyli tworzymy coś niematerialnego, tworzymy coś zespołowo i tworzymy coś heurystycznie. Często proces tworzenia oprogramowania jest zarządzany tak jak produkcja rzeczy materialnych – czyli chcemy tworzyć oprogramowanie tak jak samochody czy krzesła, w sposób przewidywalny i kontrolowany. Tak naprawdę organizację stają przed wyborem sposobu zarządzania – muszą wybrać między samoorganizacją zespołów a zarządzaniem na zasadzie Command and Control. Tak naprawdę samoorganizację można umożliwić, można stworzyć dla niej dogodne warunki – ale nie można jej wymusić.

Ale często bywa też tak, że samoorganizacja w zespole nie działa – kierownik skarży się, stworzył warunki, ale jego ludzie nie współpracują ze sobą, nie przejawiają inicjatywy, nie zmieniają rzeczywistości. Dlaczego?

W praktyce wielu organizacji mamy często do czynienia z kulturą dzielenia ludzi, tworzenia barier i dystansu – wyraża się to w cieszeniu się z cudzych porażek, wytykaniu pomyłek, przetrzymywaniu ważnych informacji, przyjmowaniu stanowiska przeciw, oskarżaniu. Inną przyczyną, które mogą blokować samoorganizację jest podejście menedżera pt. „ja wiem, co wy powinniście zrobić”. Samoorganizacja nie zadziała też, jeżeli pracownicy nie mają jasno określonych pozycji, odpowiedzialności i obowiązków.

Morał: samoorganizacja zespołu nie polega na posiadaniu tablicy z zadaniami oraz stand-up meeting-ów. Żeby zaistniała, potrzebne jest spełnienie istotnych kilku warunków, zarówno po stronie lidera zespołu, jak i po stronie samego zespołu.

Kolejny wykład ma bardzo obiecujący tytuł „Agile Requirements by Example” i prowadzi go Keith Braithwaite. Wg badań Standish Group brak jasnych wymagań jest najczęstszą przyczyną niepowodzeń projektów – ale jednocześnie napisanie kompletnych i jednoznacznych wymagań dla systemu jest często trudne lub wręcz niemożliwe.

Keith przedstawił dokumentowanie wymagań za pomocą spisywania User Stories, które zawierają rolę, akcję oraz cel. Mając taką historię możemy ją ocenić – czy jest niezależna, czy jest w niej konwersacja, czy dodaje wartość, czy ta się ją oszacować, czy jest krótka, czy jest testowalna (INVEST test). Kolejnym narzędziem jest Checked Examples – czyli wymienienie różnych warunków testów i oczekiwanych wyników. W rzeczywistym przykładzie opisanym przez Keitha stworzenie dużej bazy przykładów testowych i automatyczne ich testowanie spowodowało, że po raz pierwszy aplikacja została dostarczona bez błędów, a zespół który ją wdrażał, po wdrożeniu czuł się nieswojo nie mając nic do poprawienia…

Morał: User Stories i Checked Examples działają w praktyce. W sumie to niezbyt odkrywczy morał, ale z tego wykładu niewiele więcej wynikało…

Na zakończenie Kevlin Henney opowiadał o fascynujących fragmentach kodu oraz o tym dlaczego bycie programistą bywa wyzwaniem i dlaczego bywa ekscytujące. Ten wykład mogę skomentować tylko ulubionym stwierdzeniem dziennikarzy radiowych: „szkoda, że państwo tego nie widzą…”. Treść prezentacji i ekspresja Kevlina jest nie do powtórzenia w relacji…

I na koniec podsumowanie – na pewno prezentacje na GeeCONie były różnorodne, ciekawe i inspirujące. Szkoda tylko tego, że niektóre z nich były na dość wysokim poziomie abstrakcji i nie odwoływały się do konkretnych sytuacji z życia projektów IT (real life stories). Dużo ważniejsze od pokazania, że „coś teoretycznie można zrobić” jest dla mnie pokazanie, że „ten mechanizm dobrze się sprawdza w praktyce, a takie podejście kończy się porażką”.

Zawsze trudno jest określić, co takie konferencje dają i ile wnoszą w życie. Na pewno po powrocie z nich nie zmienia się rewolucyjnie podejście do swojej pracy – ale rozszerzają się horyzonty i pewne sprawy inaczej ustawiają się w głowie. Pokazują też, jak wielki i różnorodny jest świat IT, z jak różnymi problemami mamy do czynienia, a czasami też jak podobne są problemy z różnych domen. GeeCON to bardzo dobra okazja, żeby spojrzeć na wesoły świat IT z nieco innej perspektywy.