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

Dodaj ten wpis do:

wykop del.icio.us