Podstawowe praktyki extreme programming (XP) – cz. 4
Komentarze (4) Praktyki XP
Po przerwie świąteczno-noworocznej i uporządkowaniu kilku prywatnych i zawodowych spraw czas na kolejny wpis dotyczący extreme programming. Tym razem opiszę praktyki XP, czyli to, co jest najczęściej wymienianie gdy wspominamy o XP. Oczywiście wiemy już, że praktyki nie mają głębszego sensu bez znajomości wartości oraz zasad. Nie ma też konieczności stosowania wszystkich z nich, jednak autorzy XP zalecają ich wzajemne łączenie celem spotęgowania pozytywnego efektu.
Wspólne środowisko pracy
Zgodnie z tą praktyką, cały zespół powinien się znajdować w jednym pomieszczeniu, tak aby nie istniał problem braku komunikacji wewnątrz zespołu. Najlepiej, jeśli osoby ze stanowisk kierowniczych również znajdują się w tym pomieszczeniu – oszczędzi to nam wycieczek po pokojach w przypadku gdy mamy jakieś wątpliwości dotyczące projektu. Praktyka ta jest wcieleniem w życie takich wartości jak komunikacja czy sprzężenie zwrotne – łatwo będzie zauważyć, iż każda praktyka odzwierciedla wybrane wartości i zasady. Z własnego doświadczenia wiem, iż praca zdalna (samodzielna) w wielu przypadkach jest mniej efektywna niż praca w grupie. Czasem wystarczy jedno spojrzenie w nasz kod osoby “z zewnątrz” aby zlokalizować prosty błąd, który dla nas – po kilku godzinach pracy z kodem – jest kompletnie niewidoczny. Sztuką jest zapewnić odpowiedni poziom prywatności programistów wraz z utrzymaniem wysokiej komunikatywności w zespole.
Samowystarczalny zespół
Zespół w danej chwili powinien się składać z wszystkich osób, które są niezbędne do realizacji danego zadania. Jeśli w pewnym momencie projektu potrzebujemy specjalisty od sztucznej inteligencji – powinien on dołączyć do zespołu na czas wystarczający do zaimplementowania kodu, który bez jego wsparcia powstawałby bardzo długo, lub w ogóle by nie powstał. Każdorazowa wycieczka w inną część budynku firmy aby otrzymać potrzebne nam informacje to zbędna strata czasu i niepotrzebne oderwanie się od projektu, które jak wiemy jak bardzo kosztowne. Ciekawostką są dwie graniczne wartości w rozmiarze zespołów – 12 oraz 150 osób. Dwanaście osób to maksymalna liczba osób w jednym zespole, aby móc prowadzić skuteczny dialog i interakcję w codziennej pracy. 150 to maksymalna liczba osób w zespole, w którym rozpoznajemy ludzi po twarzach.
Przejrzyste środowisko pracy
Po wizualnej ocenie miejsca, w którym rozwija się projekt, osoba z zewnątrz powinna mieć obraz aktualnego stanu projektu. Moim zdaniem, nie tylko postronne osoby, ale głównie Ci którzy zaangażowani się w projekt, powinni na bieżąco widzieć roadmap oraz bardziej szczegółowe informacje, czyli w naszym przypadku scenariusze. Zauważyłem, że jeśli na ścianie nie wisi aktualna lista zadań oraz nie są wyszczególnione zadania na najbliższe dni, tygodnie oraz miesiące, traci się “czucie” projektu, a wtedy zaczyna brakować odpowiedzi na pytania “kiedy” zadawane przez osoby zainteresowane projektem.
Miejsce pracy powinno też spełniać rozmaite potrzeby ludzkie – nie mówię tutaj o atrakcjach jakie ma przygotowane Google dla swoich pracowników, ale o tak podstawowych rzeczach jak ekspres do kawy czy woda mineralna dla pracowników. Posprzątane pomieszczenie również wpływa pozytywnie na atmosferę pracy – słyszałem niesamowite historie od moich znajomych, jak brudno może być w miejscu pracy…
Energiczna praca
Najciekawszy wniosek jaki wypływa z praktyki energicznej pracy jest taki, iż większa ilość godzina spędzona w pracy niekoniecznie przekłada się na jej efektywność. Pracować należy wyłącznie tak długo, jak długo pozostajemy kreatywni. Oczywiście, w przypadku pracy biurowej, na przykład w okienku pocztowym, nie potrzebujemy aż tak dużej kreatywności i świeżości umysłu, jaka potrzebna nam jest do wymyślenia skomplikowanego algorytmu. Dłuższe pozostawanie w pracy zazwyczaj daje wyłącznie większy komfort psychiczny (”przecież pracuję po 10h dziennie”) i bardzo rzadko przekłada się na realne efekty. Warto również oddzielić życie prywatne od pracy – przenikanie się tych dwóch światów najczęściej przynosi zgubne skutki.
Programowanie w parach
Zdjęcie pochodzi z agilefaq.net
Jest to zazwyczaj pierwsze skojarzenie ludzi, kiedy pada hasło “XP”. Jak mieliście się okazje przekonać czytając poprzednie wpisy, jest to wyłącznie jedna z proponowanych praktyk, a nie filar XP. Często słyszy się stwierdzenia w stylu “to XP nie jest dla mnie bo nie chcę programować w parach” – pozwolę sobie nie komentować takich i podobnych twierdzeń, skupię się natomiast na faktycznych korzyściach płynących z tej kontrowersyjnej praktyki.
Jak to wygląda w praktyce? Bierzemy jeden komputer, stawiamy dwa krzesła i umieszczamy na nich dwóch programistów. Jeden pisze kod, drugi obserwuje, zadaje pytania, wyłapuje błędy lub po prostu się dokształca.
Korzyści płynące z programowania w parach:
- większa skuteczność wyłapywania błędów,
- łatwiej coś wytłumaczyć na przykładzie,
- programiści mają większe pojęcie całościowe o projekcie,
- programiści uczą się od siebie nawzajem,
- jest to okazja do nawiązania kontaktu między członkami zespołu.
Nie twierdzę, iż programowanie parami to rozwiązanie wszystkich problemów – osobiście stosujemy je w zależności od aktualnych potrzeb. W przypadku nauki nowych technologi czy frameworków, programowanie parami może okazać się strzałem w dziesiątkę – wspólna nauka i poznawanie nowego środowiska może przebiegać efektywniej, niż samodzielna nauka. Należy zdać sobie sprawę, iż przypisanie dwóch programistów do jednego zadania wcale nie przyspiesza rozwiązania go o 100%. Oto jakie wnioski wypłynęły po zakończeniu eksperymentu poznańskiego:
Programowanie parami wydaje się mniej efektywne niż to wynika z eksperymentów J.T. Noska i L. Williams.
oraz
Programowanie parami jest bardziej przewidywalne, zarówno z punktu widzenia czasu, jaki i rozmiaru kodu.
(O eksperymencie Noska i Williams’a przeczytacie w załączonym “eksperymencie poznańskim”)
Co dalej?
W kolejnej części opiszę kolejne praktyki XP.
(c.d.n.)
