True Solutions

Co to jest XP?

Pewnie każdy, kto choć trochę interesuje się rykiem komputerowym, spotykał się z pojęciem “XP”. Pierwsze skojarzenie może okazać się dosyć oczywiste, jednak gdy rozwiniemy skrót – eXtreme Programing – całość nabiera nowego znaczenia i okazuje się, że “XP” ma tyle wspólnego z systemem operacyjnym, co klub piłkarski z Amsterdamu ze znanym wszystkim AJAX’em.

Gdy słyszy się lub czyta o XP zazwyczaj padają hasła: “programowanie w parach”, “brak dokumentacji”, “brak projektu systemu”. Owszem, hasła te są prawdziwe, ale muszą być zastosowane w odpowiednim kontekscie oraz przygotowanych warunkach. Często właśnie powyższe slogany budują mylny obraz tej metodyki, która może wydawać się niechlujna, zbyt luźna czy nieodpowiednia do budowania poważnych aplikacji. Częściej kojarzona jest z doświadczeniami w środowisku studenckim (eksperyment poznański) niż z dużymi, profesjonalnymi projektami. Wynikać to może z konserwatyzmu osób związanych z branża informatyczną, zamiłowania do klasycznego modelu kaskadowego oraz pewnej obawy “jak to chaotyczne XP w ogóle może zadziałać w naszej firmie”. Również sformułowanie “ekstremalne” może rodzić niepokój w firmach gdzie od lat wszystko jest poukładane a inicjatorzy zmian nie mają siły przebicia, aby dotrzeć do osób odpowiedzialnych za zatwierdzenie zmiany sposobu ich pracy.

Jak więc można zdefiniować XP? Istnieje dosyć dużo definicji i zazwyczaj – pomimo, iż mogą się one lekko różnić – zazwyczaj mniej lub bardziej oddają ducha tej metodyki. Sam autor w książce “Wydajne programowanie. Extreme programming” dosyć szeroko rozpisuje się na temat definicji XP, jednak jedno z jego zdań krótko i trafnie precyzuje o co tak naprawdę chodzi:

XP to styl tworzenia oprogramowania, który zakłada maksymalizację zysków wynikających z zastosowania zaawansowanych technik programistycznych, komunikacji i pracy w zespole”

Historia XP

Autorem filozofii XP jest Kent Beck, który wraz z Wardem Cunninghamem bazując na swoim doświadczeniu stworzył fundamenty extreme programming. Obydwaj panowie to zasłużone postacie w branży – Kent jest jednym z twórców Manifestu Zwinnego Oprogramowania, Ward – pomysłodawcą Wikipedii. Tak więc jasne jest, iż swoje teorie opierają na faktycznej styczności z cyklem rozwoju oprogramowania, aniżeli na akademickich teoriach prezentowanych na wykresach i wzorach z niezrozumiałymi symbolami. Warto dodać, iż pierwsze wdrożenie XP miało miejsce w fabryce DaimlerChrysler (od 2007 roku pozostał wyłączanie człon Daimler) i tam właśnie było modyfikowane i nabierało kształtu.

Filary XP

Pełne poznanie XP to znajomość trzech pojęć oraz zrozumienie ich wzajemnych relacji. Te pojęcia to:

• wartości,
• zasady,
• praktyki.

Wymienione na początku hasła (”programowanie w parach” itd.) to właśnie praktyki – jak widać są trzecim, ostatnim elementem w tym zestawieniu. Pozbawione powiązania z wartościami oraz zasadami stają się sloganami bez wyrazu, które bezmyślnie zastosowane mogą doprowadzić każdy projekt informatyczny do ruiny. Pojęcia te mogą wprawdzie wydawać się nieco dziwne, nie informatyczne. Stwierdzenia wartości czy zasady potrafią mocniej kojarzyć się z kampanią polityczną niż z biznesem informatycznym. Niektórzy dopatrzyć się tu mogą nadmiernej filozofii oraz zbędnej nadbudowy teoretycznej – jednak osobiście sugeruję zapoznanie się z wszystkimi trzema filarami. Poniżej przedstawiłem pierwszy z nich.

Wartości

Podstawowe wartości, bez których XP nie ma szans na powodzenie, to:

• Komunikacja
• Prostota
• Sprzężenie zwrotne
• Odwaga
• Szacunek

Osobiście uważam, iż zasady te powinny odnosić się do każdego zespołu deweloperskiego, bez względu na stosowaną metodologię. Programiści, kierownicy projektu, szefostwo, inwestorzy, klienci – wszyscy są ludźmi i bez względu na zajmowaną pozycję powinni respektować wyżej wymienione zasady. Co więcej, nie dotyczą one wyłącznie projektów informatycznych – są uniwersalne. Jeżeli pracowałeś w zespole, w którym kontakty osobiste są na niskim poziomie, pracownikom brakuje wzajemnego zaufania, ludzie unikają dialogu – wiesz jakie może mieć to przełożenie na wyniki pracy.

Przyjrzyjmy się z bliska wartościom które wymieniłem.

Komunikacja

Jest niezbędna w każdym zespole – w tym przypadku nie ma znaczenia, jaki jest profil działalności firmy. Jeżeli sam nie doświadczyłeś pracy w zespole w którym brak dialogu, zapytaj swoich znajomych – zawsze znajdziesz kogoś, kto doświadczył tej niekomfortowej sytuacji. Brak komunikacji lub komunikacja na niewłaściwym poziomie opóźnia projekty informatyczne, powoduje zwiększenie czasu lokalizowania oraz naprawiania błędów a także wydłuża czas rozwiązywania problemów z codziennego życia programisty. Może mieć także wpływ na brak zrozumienia na całym etapie tworzenia oprogramowania. Brak komunikacji najtrafniej oddaje rysunek (jest stary jak świat, występował w wielu wersjach, wybrałem jedną z nich – spolonizowaną)

Prostota

Albert Einstein nie miał nic wspólnego z XP, jednak jego słowa idealnie komentują potrzebę prostoty:

Wszystko trzeba robić tak prosto, jak to tylko jest możliwe, ale nie prościej.

W podobnym duchu napisana jest książka “Getting real” napisana przez 37 Signals.

Innymi słowy, eliminujemy zbyteczną złożoność, która nie przekłada się na rozwiązanie problemu, a staje się tylko zbędnym balastem. Silny związek wartości XP – w tym przypadku prostoty oraz komunikacji – wykazuje Beck pisząc:

Usprawnienie komunikacja ułatwia osiągniecię prostoty poprzez eliminowanie zbędnych lub nadmiernie złożonych wymagań. Z drugiej strony – uproszczenie systemu ogranicza ilość komunikacji niezbędnej do jego tworzenia.

Doskonałe podsumowanie.

Sprzężenie zwrotne

Musimy zaakceptować fakt, iż nie stworzymy od razu idealnego systemu. Oczywiście, model kaskadowy zna odpowiedz na ten problem – planowanie, analiza wymagań, projekt, implementacja – jednak częściej wygląda to tak prosto wyłącznie na slajdach. W rzeczywistości – zgodnie z rysunkiem zamieszczonym przy okazji opisywania wartości komunikacji – może się okazać, iż nasz projekt powędrował z złym kierunku. I mogło się to wydarzyć nie z powodu błędnej oceny wymagań klienta, a z faktu, iż klient zwyczajnie nie wie czego potrzebuje. Około rok temu pisałem aplikację do zarządzania zleceniami wewnętrznymi dla poznańskiej firmy. Pomimo, iż klient wiedział czego potrzebuje, kolejne moje iteracje dodawania funkcjonalności pobudzały fantazję zleceniodawcy, który (w przenośni) zamówił ZX Spectrum, natomiast oczekiwał wydajności Pentium 4. Teraz wiem, że gdybym zwiększył sprzężenie zwrotne między mną a zleceniodawcą, system powstał by szybciej i byłby lepiej dopasowany do potrzeb. Dowiedziałbym się w porę, iż klient potrzebuje tak naprawdę Pentium II, tylko po prostu tego nie wiedział.

Musimy wykonać ruch, żeby zobaczyć jego wynik. Musimy zapytać, aby poznać odpowiedz. Musimy zaimplementować rożne rozwiązania, jeśli nie wiemy (i nie możemy się dowiedzieć) które z nich jest dla nas lepsze. To właśnie w moim odczuciu jest sprzężenie zwrotne.

Odwaga

Zawsze myślałem, że odważny może być strażak, a nie członek zespołu programistów. Jednak to właśnie umiejętność działania w niekomfortowych warunkach (deadline, brak funduszy, błędy w oprogramowaniu) wymaga odwagi. To sztuka mówienia prawdy, nawet kiedy jest nieprzyjemna. To sztuka przyznania się do błędu, a także umiejętność powiedzenia tego samego współpracownikowi. I znów cytat Becka, który jest spoiną wartości XP:

Odważne odrzucanie błędnych rozwiązań umożliwia dążenie do prostoty. Odważne poszukiwanie jasnych i przejrzystych odpowiedzi ułatwia uzyskiwanie sprzężenia zwrotnego.

Szacunek

Cały zespół musi darzyć siebie nawzajem szacunkiem, dbać o wspólne rezultaty i wiedzieć, dlaczego realizują projekt. Nie ma tutaj miejsca na rozgrywki w stylu “ja mam wyższą pozycję”. Nie można zrobić z ludzi robotów, które wykonują swoją pracę. Ludzie potrzebują dobrego kontaktu, wypicia wspólnie kawy, dialogu. Szacunek wg. Becka opiera się na fundamencie wcześniej wymienionych wartości.

Co dalej?

W kolejnej części opiszę zasady extreme programming.

(c.d.n.)