True Solutions

Kolejne zasady XP

W poprzednich wpisach omówiłem podstawowe wartości oraz pierwsze siedem zasad extreme programming – oto kolejne siedem z nich.

Przepływ czyli sprawdźmy czy to razem zadziała

Nierzadko podczas pisania większych aplikacji, praca zostaje podzielona na programistów. Każdy z nich pisze oddzielny moduł (lub w przypadku XP następuje zmiana co określony interwał czasu), który stanowi część większego systemu. Zasada przepływu mówi nam o konieczności ciągłej integracji kodu – im częściej, tym lepiej. Im dłużej będziemy zwlekać z integracją, tym większe problemy możemy napotkać, gdy przyjdzie nam w końcu połączyć poszczególne części aplikacji w jedną całość.

W naszym przypadku dzielimy prace na moduły, ustalamy strukturę odpowiedzialną za wzajemną komunikację i rozpoczynamy pracę. Nie trzymamy się sztywno praktyki pisania parami (o praktykach XP napiszę wkrótce) i stosujemy ją w zależności od potrzeb – proste moduły piszemy osobno, natomiast gdy tworzymy kluczowy element aplikacji, często zasiadamy do jednego laptopa i pracujemy razem. Zaraz, gdy nasze moduły posiadają sensowną funkcjonalność, dokonujemy integracji. Pozwala to na wczesnym etapie rozpoznać problemy i na bieżąco je rozwiązać.

Możliwości czyli problemy stwarzają okazje

Pokonywanie napotkanych problemów wzmacnia zespół, daje świeżą motywację i pozwala mocniej wierzyć w powodzenie projektu. Zamiast chwytać się za głowę, lepiej w problemach odszukać nowych możliwości. Często, gdyby nie problem, nie odkrywalibyśmy nowych, lepszych rozwiązań

W zeszłym tygodniu doszliśmy do wniosku, iż sposób implementacji technologi AJAX w frameworku Prado którego używamy w codziennej pracy, jest zbyt wolny dla naszej aplikacji. Pół dnia byliśmy konkretnie zmartwieni tym faktem, gdyż szybkość działania w naszym przypadku będzie bardzo istotna (piszemy nowoczesnego, webowego klienta pocztowego). Rozwiązanie, które zaproponował Wiktor, okazało się do 10 (słownie: dziesięć) razy szybsze od “chińskiej” implementacji (główny autor frameworka Prado to Qiang Xue). Tym sposobem problem, który miał nas pogrążyć (w najczarniejszym scenariuszu padła propozycja późniejszego przepisania kodu), okazał się kluczowy dla rozwoju naszej aplikacji.

Redundancja czyli sprawdźmy kilka wariantów

Kent Beck dosyć kontrowersyjnie wypowiada się na temat redundancji:

Każdy z trudnych, fundamentalnych problemów w rozwoju oprogramowania powinien być rozwiązany na kilka rozmaitych sposobów.

Trudno w prostszy sposób wytłumaczyć tę zasadę. Czas stracony na redundantną implementacje ma nas ochronić przed klęską projektu, gdy będzie już za późno aby szukać alternatywnych rozwiązań. Z drugiej strony, testowanie alternatywnych rozwiązań poszerza naszą wiedzę i pozwala nam spojrzeć na projekt z różnych perspektyw. Jestem przekonany, iż sprawdzanie różnych rozwiązań odnosi się nie tylko do implementowania funkcjonalności. Na jednym ze spotkań z cyklu Startup-IT, Piotr Długiewicz (szef firmy One-2-One) wymienił podczas swojej prezentacji zasadę “nie bój się eksperymentować” (ang. think out of the box) jako jedną z 10 podstawowych zasad dla startupów. Polecam zapoznać się z prezentacją 10 powerful rules for startups, które przygotował specjalnie na tę okazję.

Porażka, czyli pogłębiajmy swoją wiedzę

Zródło: http://pl.wikipedia.org/wiki/Grafika:Henry_Ford.jpg

Postać, którą zaprezentowałem na powyższym zdjęciu nie miała nic wspólnego z XP. To Henry Ford, który wypowiedział następujące zdanie:

Porażka daje możliwość rozpoczęcia na nowo w sposób lepiej przemyślany.

Nie bójmy się porażek, jeśli tylko niosą w sobie wiedzę. Często taka wiedza jest trudna do zdobycia, dlatego jeśli musimy przyznać się błędu, wyciągnijmy z niego wnioski. Kolejnym razem będziemy mądrzejsi o nasze doświadczenie.

Jakość czyli … jakość ponad wszystko

Nie słyszałem, żeby ktoś zbudował solidny dom z patyków. Tak samo nie słyszałem o projekcie, który byłby słabej jakości i odniósł by wielki sukces. Mógłbym tutaj oczywiście na siłę szukać przykładów, że jednak można wyszarpnąć duży fragment rynku pomimo niedoskonałego produktu (i pewnie na siłę bym znalazł), jednak ogólnie wygrywają Ci, którzy dostarczają produkty wysokiej jakości. Filozofia XP pomaga w utrzymaniu wysokiego standardu projektu – programowanie parami, testy, ciągła integracja – wszystko to wpływa na jakość tworzonego oprogramowania a nas zbliża do zarabiania uczciwych pieniędzy, sprzedając owoce swojej pracy.

Zasada małych kroków czyli powoli i bezpiecznie do celu

Najprościej mówiąc – wykonujmy małe zmiany i czekajmy na feedback. Pozwoli to nie zabrnąć w ślepą uliczkę gdy okaże się, że dodane przez nas modyfikacje wcale nie podobają się użytkownikom. Wycofanie się z małych zmian to nie problem, natomiast “rollback” olbrzymich modyfikacji zazwyczaj sprawia niespodziewane problemy. Drugi, nie mniej ważny aspekt to przyzwyczajenia użytkowników – powolna zmiana ich przyzwyczajeń może okazać się mniej bolesna niż nagły szok i seria stwierdzeń “przecież to zawsze było tutaj”. Wyobrażacie sobie, co by się stało, gdyby z dnia na dzień wyszukiwarka na stronie Allegro nagle zmieniła swoją pozycję na stronie? Nie życzę wtedy nikomu odbierać telefonów i maili od użytkowników.

Akceptowalna odpowiedzialność czyli mniej stresu

Dobrze nam już znany Beck, określił akceptowalną odpowiedzialność.

Odpowiedzialność nie może zostać wymuszona, można ją jedynie zaakceptować.

Trudno się z tą definicją nie zgodzić. Odpowiedzialność za powierzone zadanie musi zostać zaakceptowana. W przeciwnym wypadku, zadanie może zbyt mocno stresować i finalnie nie zostanie poprawnie wykonane. Przykładowym postępowaniem zgodnym z zasadą akceptowalnej odpowiedzialności, jest wymaganie od osoby przyjmującej zadanie określenie czasu jego zakończenia.

Co dalej?

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

(c.d.n.)