True Solutions

Zasady XP

W poprzednim wpisie wyjaśniłem podstawy XP oraz wartości, które stanowią fundament tej metodyki. Dzisiaj omówię zasady, które łączą świat wartości ze światem praktyk.

Zasady są przełożeniem wartości na świat rzeczywisty – zarówno w zasadach jak i praktykach XP, widać wyraźnie fundamenty nadane przez wartości.

Czternaście zasad extreme programming

Ktoś może powiedzieć, że to dużo. Czternaście zasad które trzeba pamiętać? Dodatkowo, może być ich jeszcze więcej. Ich dobór to sprawa indywidualna w zależności od projektu jaki realizujemy.

Na szczęście może się okazać, że część z nich stosujemy nawet nie wiedząc o tym. Przekonajcie się sami, oto one:

• Człowieczeństwo
• Ekonomia
• Wspólna korzyść
• Samopodobieństwo
• Doskonalenie
• Różnorodność
• Przepływ
• Możliwości
• Redundancja
• Porażka
• Jakość
• Zasada małych kroków
• Akceptowalna odpowiedzialność

Ze względu na rozległy temat, zdecydowałem się podzielić zasady na dwa wpisy – dziś pierwsze 7 zasad, kolejne 7 w następnym wpisie.

Człowieczeństwo czyli oprogramowanie tworzą ludzie

Jestem przekonany, że atmosfera w pracy i relacje wewnątrz grupy osób pracujących nad wspólnym zadaniem jest w firmach ważniejsza niż kawalifikacje. Oczywiście, nie należy schodzić poniżej pewnego poziomu wiedzy, jednak w teamie zamiast siejącego ferment geniusza wolałbym przeciętną osobę, która doskonale potrafi współpracować z ludźmi. Zazwyczaj jest tak, że wiedzę można uzupełnić, natomiast zmienić charakter jest trudno.

Ekonomia czyli myślmy jak zarobić pieniądze

Zasada jest prosta – najpierw rozwiązujemy problemy, które mają największy wpływ na komercyjny sukces naszego oprogramowania. Często można zagubić się w gąszczu proponowanych usprawnień, które faktycznie podnoszą wartość programu, jednak zanim zdążymy wszystkie zrealizować i sprzedamy w końcu nasz genialny program, umrzemy z głodu. Można na różny sposób szacować wartość oprogramowania, jednak Kent Beck w swojej książce podaje najtrafniejszą definicję:

Oprogramowanie jest tym cenniejsze, im szybciej przynosi zysk.

Przykładów nie trzeba daleko szukać: nasza-klasa.pl z 2 milionami użytkowników nie powala grafiką ani funkcjonalnością, jednak to właśnie autor tego portalu (a nie zwycięzca 100 olimpiad informatycznych) stał się (lub wkrótce się stanie) milionerem – gratulacje. Grafikę i funkcjonalność zawsze można poprawić, jednak wykorzystać nadarzającą się okazję nie będzie już tak łatwo.

Guru dla wielu tych, którzy rozpoczynają swój własny startup, jeden z autorów sukcesu pierwszego Macintosha – Guy Kawasaki – ma bardzo podobne zdanie na temat czasu, w którym trzeba zacząć myśleć o pieniądzach: jak najwcześniej. Pisze o tym zarówno w kontekście czasu uruchomienia sprzedaży, jak i terminu wypuszczenia na rynek produktu, choćby nie do końca idealnie dopracowanego. Zainteresowanym polecam książkę, którą osobiście umieszczam w swoim “top 5″ książek dla rozpoczynających biznes – “Sztuka rozpoczynania“.

Wspólna korzyść czyli nie jesteśmy tutaj sami

Każda wykonywana przez nas czynność powinna mieć na względzie interesy wszystkich powiązanych z nami osób. Beck uważa tę zasadę za jedną z trudniejszych zasad XP.

Sam wiem, że czasem ciężko jest napisać działający i zrozumiały kod. Zdaję sobie sprawę, że większość używa “swojej” notacji w pisanym przez siebie kodzie. I jestem też w stanie zrozumieć, że dla wielu pisanie testów do kodu to strata czasu. Na szczęście nie muszę się z tym wszystkim zgadzać. Kod zbytecznie złożony staje się trudny w interpretacji oraz nieczytelny, miks wszystkich możliwych notacji pomaga wyłącznie w zgubieniu się podczas analizy kodu, natomiast brak testów wyjdzie dopiero, gdy poprawiając błąd, zepsujemy przypadkowo inna funkcjonalność. Musimy pamiętać, że w zespole nie jesteśmy sami, a programowanie to dziedzina w której bardzo często musimy korzystać z cudzego kodu (biblioteki, frameworki, itp.)

Samopodobieństwo czyli korzystajmy z tego co już mamy

Jednym zdaniem – stosujmy sprawdzone rozwiązania (pomysły, struktury) w kontekstach o zróżnicowanych skalach. Jeżeli mamy rytm pracy określony na tydzień, spróbujmy przełożyć go na cały miesiąc. Przykładowo, dzień rozpoczyna się od określenia zadań (w XP nazywamy je scenariuszami) a następnie każdy wykonuje wybrane (lub przydzielone) dla siebie zadania.

Uwaga: XP sugeruje ciągłą rotację programistów w stosunku do modułów systemu, tak aby każdy miał styczność z każdą częścią systemu – dzięki temu programiści uzyskują pełniejszy oraz bardziej czytelny obraz całego systemu. Czasem jednak bardziej efektywne może być przydzielenie programistów do zadań zgodnie z ich umiejętnościami (znawca javascriptu niech pisze skrypty, bazodanowiec niech projektuje ERD)

Tygodniowy układ można przełożyć na miesiąc – określamy scenariusze na nadchodzący miesiąc i planujemy ich podział oraz czas realizacji. Wbrew pozorom planowanie nie jest łatwe i sam się o tym przekonuję planując swoje zadania – często plan na tydzień realizuje się szybciej niż można się spodziewać, innym razem pozornie proste zadanie “na godzinkę” potrafi zając pół dnia. Warto jednak zmieniać perspektywę dla swoich działań – pozwala to lepiej wyczuć projekt oraz stopień jego zrealizowania na osi czasu.

Doskonalenie czyli nie ma rzeczy idealnych

Nie ma doskonałych projektów ani doskonałego kodu – zarówno jedno i drugie możemy ciągle poprawiać, jednak trudno ocenić moment, w którym osiągniemy perfekcję. Zasada ta zachęca do jak najszybszego rozpoczęcia pracy kosztem filozofowania nad problemami, które faktycznie mogą się w ogóle nie pojawić. Nie oznacza to, że powinniśmy w chaosie i kompletnie bez planu zasiąść do klawiatury – jednak tracenie czasu na drobiazgi implementacyjne (podkreślam – drobiazgi) to zazwyczaj strata czasu, ponieważ to użytkownicy końcowi (bądź już beta-testerzy) najczęściej podsuwają najlepsze pomysły. W XP projektuje oraz koduje się przyrostowo, pracuje z prototypem i słucha użytkowników, w ten sposób dążąc do doskonałości.

Różnorodność czyli dobrze że masz inne zdanie

Nie ma nic bardziej kreatywnego niż burza mózgów – najlepiej, gdy ścierają się skrajnie różne podejścia do tematu. Tylko w taki sposób możemy poznać prawdziwe “za” i “przeciw” dla każdego problemu. Jeżeli zespół to grupa ludzi, którzy mają wspólny cel oraz misję, ryzyko kłótni przy okazji wymiany poglądów właściwie nie istnieje.

Refleksja czyli nauczmy się wyciągać wnioski

W codziennej pracy często nie ma czasu aby zatrzymać się i spojrzeć w tył – “kod został już napisany i to jest najważniejsze, więc szybko realizujmy kolejną funkcjonalność”. Nic bardziej mylnego – okresowa analiza kodu, refaktoryzacja, przyznanie się do błędów koncepcyjnych – wszystko to jest bardzo ważnym elementem cyklu tworzenia oprogramowania. Często trzeba się przyznać do błędu czy przeoczenia, jednak w prawidłowo funkcjonujących zespołach (czyli takich, w których ludzie respektują wartości XP) jest to normalna, niestresująca procedura. Beck przypomina:

Pamiętajmy więc: refleksja powinna następować po działaniu i stanowić jego przedłużenie. W metodologii XP cykle refleksji są przemieszane z cyklami pracy.

Co dalej?

W kolejnej części opiszę następne 7 zasad extreme programming.

(c.d.n.)

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.)