True Solutions

Praktyki XP

Dzisiejszy wpis zakończy omawianie podstawowych praktyk stosowanych w extreme programming. Celowo na ten wpis rozstawiłem praktyki, które są silnie związane z kodem naszej aplikacji i często budzą mieszane uczucia wśród programistów.

Kompilacje dziesięciominutowe

Większość wiedzy na temat tej praktyki zawarta jest w jej nazwie – automatyczna kompilacja całego kodu połączona z uruchomieniem wszystkich testów nie powinna trwać dłużej niż 10 minut. Zdaniem Kent Beck’a dłuższe kompilacje ograniczają sprzężenie zwrotne, krótsze nie pozwalają bez stresu wypić kawy.

Jeżeli nie jesteśmy w stanie skompilować i przetestować całego systemu w podanym czasie, spróbujmy zrobić to dla fragmentu kodu – lepiej wykonać część testów niż nie wykonać ich wcale. Brak automatyzacji wraz z rozwojem aplikacji powoduje skomplikowanie procesu kompilacji i może zwiększać ryzyko błędu a także stres programistów. Czy nie prościej jest codziennie wciskać jeden guzik zamiast męczyć się z ręczną kompilacją od zera?

Ciągła integracja

Trudno sobie wyobrazić, by proces produkcji samolotu wyglądał następująco: dziesiątki producentów tworzy podzespoły, które później są na szybko łączone, a samolot po zespoleniu w jedną całość jest gotowy do startu.

Nie jestem ekspertem w dziedzinie lotnictwa, jednak kilka programów obejrzanych na Discovery Channel pozwoliło mi wyrobić sobie pogląd, jak skomplikowany jest taki proces. Dodatkowo, biorąc pod uwagę, że ryzyko uczestnictwa w wypadku lotniczym wynosi 1 na 11 milionów (dla samochodu 1 na 5000) a zazwyczaj głównym problemem jest czynnik ludzki, możemy być pewni, iż cały proces jest dobrze przemyślany.

Podobnie musimy myśleć o oprogramowaniu – aplikacje powinny być co najmniej tak samo niezawodne, jak samoloty. Nie osiągniemy takiej niezawodności, jeśli naszym pierwszym testem integracji będzie finalny deployment aplikacji na serwer docelowy w dzień oddania klientowi finalnego produktu. Należy integrować moduły co najmniej raz dziennie, chyba że są to mniejsze fragmenty, wtedy możemy wykonać integrację częściej.

Potwierdza się tutaj zasada płynąca z programowania opartego o model kaskadowy mówiąca, iż im później wykryjemy błąd, tym jest on bardziej kosztowny – doskonale odnosi się to do procesu integracji. Szybciej poprawimy bład na etapie programowania, niż dzień przed premierą, kiedy okaże się, że nasz “nie-integrujący-się” moduł jest silnie skorelowany z resztą systemu.

Rozpoczynanie programowania od testów

Jest to jedna z trudniejszych praktyk XP, wymagająca od programisty zmiany sposobu myślenia podczas projektowania. Kolejnośc działania w tym przypadku wygląda następująco:

• testowanie
• kodowanie
• refaktoring

Jeżeli pisanie testu przychodzi nam z trudnością, najprawdopodobniej oznacza to, że architektura została źle przemyślana. Łatwiej bowiem testować krótkie, precyzyjnie określone pod względem funkcjonalności funkcje niż długie, robiące kilka rzeczy naraz.

Zaletą pisania testów zanim zaczniemy pisać kod jest konieczność zawarcia w testach przypadków, które ocenią, czy nasz kod działa zgodnie z oczekiwaniem. Gdy pracy jest dużo, łatwo zapomnieć o fragmencie funkcjonalności – w tym przypadku uruchomienie wcześniej napisanego testu przypomni nam, które fragmenty nie zostały napisane, lub zostały napisane błędnie.

Patrząc na programowanie bardziej od strony ludzkiej, napisanie testów i poprawne ich wykonanie daje nam pewność i spokój ducha – kod który napisaliśmy działa zgodnie z oczekiwaniami. Spokój psychiczny pozwala programiście na lepsze skupienie się nad aktualnymi zadaniami, zamiast rozmyślać czy kod napisany tydzień temu przypadkowo nie “rozsypie się”.

Projektowanie przyrostowe

Trudno jest przed rozpoczęciem kodowania wyobrazić sobie większy projekt informatyczny w najdrobniejszych szczegółach. To, co wydaje się istotne dla nas (czy dla klienta, ba – nawet dla grup dobieranych dla potrzeb badań marketingowych), w zderzeniu z rzeczywistością może okazać się nie intuicyjne lub zupełnie nie potrzebne.

Wspomniany już wyżej model kaskadowy zakłada, iż doskonale zaprojektujemy system na kartce, następnie go napiszemy, przetestujemy i wdrożymy. Każdy, kto miał styczność z programowaniem wie, że jest to tylko pobożne życzenie. Klient zmienia zdanie, a do głowy przychodzą nowe pomysły, które mogą uatrakcyjnić produkt.

Rozsądniej jest zbudować prototyp i jak najwcześniej pokazać go grupie docelowej, która lepiej wie, w jakim kierunku aplikacja powinna się rozwijać. Oczywiście, taki sposób pisania wymaga rozsądnego projektowania architektury tak, aby wprowadzanie zmian nie pociągało za sobą drastycznych zmian w powiązanych modułach. Źle napisane oprogramowanie podlegające modyfikacją może okazać się niekończącym się horrorem, który nawet z najlepszego zespołu wyciągnie całą motywację i zaangażowanie.

Co dalej?

W kolejnej części opiszę praktyki uzupełniające extreme programming.

(c.d.n.)

Na polskiej grupie dotyczącej lekkich metodyk Piotr Gabryanczyk w swoim wpisie umieścił ciekawą ankietę. Warto ją wypełnić, aby rozeznać się, jak wygląda sytuacja m.in. XP w Polsce.

UPDATE (19.03.2008)

Na stronie Pawła dostępne są już wyniki (pdf) ankiety oraz słowo komentarza.

Praktyki XP

W poprzednim wpisie przedstawiłem część podstawowych praktyk XP. Poniżej ciąg dalszy.

Scenariusze

Trudno napisać duża aplikację, nie rozbijając jej na mniejsze moduły. Najlepiej mieć przygotowany plan działania, który przypomina z jak dużym zadaniem mamy do czynienia, ile pozostało nam czasu oraz pomoże określić, która funkcjonalność jest naprawdę konieczna, a która może zostać zaimplementowana w późniejszym czasie. (w praktyce okazuje się, iż często wyłącznie programistom/projektantom wydaję się, że dana funkcjonalność jest niezbędna – z drugiej strony łatwo pominąć coś, co może mieć kluczowe znaczenia dla klienta).

Metodyka XP sugeruje podział zadań na scenariusze, które zawierają treść zadania, nadany tytuł oraz szacowany czas wykonania. Tak przygotowane zadania można pokazać zarówno szefowi programistów jak i klientowi, pozwalając im wybrać te scenariusze, które z ich punktu widzenia wydają się najbardziej istotne. Co ciekawe, jak twierdzi Kent Beck:

… umieszczenie opisów (scenariuszy – przyp. autora) w komputerze zamiast na ścianie w znaczący sposób ogranicza ich użyteczność.

Cykl tygodniowy

Kiedy na pierwszym roku studiów pracowałem w ZUSie (wytrzymałem tam rok i kilka dni, jednak pozwoliło mi to w przyszłości docenić fakt, że można pracować robiąc to co się lubi), nie czułem potrzeby cotygodniowych zebrań informacyjnych w miejscu pracy. Jednak od momentu, kiedy zacząłem pracować z Wiktorem jako True Solutions, potrzeba cotygodniowego określenia aktualnej i przyszłej pozycji projektu okazuje się nieodzowna i wręcz źle się czuję, gdy raz na tydzień nie zadam pytania “jak wygląda aktualnie nasz plan”.

Początkowo Beck proponował, aby cykl trwał dwa lub trzy tygodnie. Jednak doświadczenie pokazało, iż najbardziej naturalnym cyklem pracy jest praca od poniedziałku do piątku. Cotygodniowe zebranie (zazwyczaj w poniedziałek) powinno zająć się następującymi sprawami:

• podsumowaniem poprzedniego tygodnia i określenie, czy wywiązaliśmy się z zaplanowanych na poprzedni tydzień zadań,
• wybranie kolejnych scenariuszy do implementacji,
• podział scenariuszy na konkretne zadania i szacowanie ich kosztu.

Pomimo, iż planowanie nie generuje bezpośrednio kodu i może się wydawać straconym czasem, pozwala lepiej “czuć” projekt. Należy jednak pamiętać, iż planowanie to tylko kierunek w którym działamy, a nie faktyczne działania. Trafnie skomentował to nieżyjący już guru współczesnych metod zarządzania, Peter F. Drucker:

Plany to tylko dobre chęci, chyba że natychmiast przekształcają się w ciężką pracę.

Cykl kwartalny

Cykl ten pozwala spojrzeć na projekt z dalszej perspektywy i ocenić, czy suma pojedynczych cykli tygodniowych daje pożądany przez nas efekt. Cykl kwartalny związany jest z:

• identyfikacją wąskich gardeł,
• usuwaniem błędów,
• planowaniem tematów (bardziej ogólnych scenariuszy) na najbliższy kwartał,
• wyborem scenariuszy do realizacji oraz
• określaniem ogólnego stanu projektu w kontekście całej firmy.

Między cyklem tygodniowym a kwartalnym występuje zależność, która jest wyrażana przez jedną z zasad XP, o której pisałem wcześniej – zasada samopodobieństwa. Jak więc łatwo zauważyć, reguły opisujące XP są spójne i wzajemnie się przenikają.

Opcjonalność

Planowanie pozwala nam określić, jak wybrany projekt będzie się rozwijał. Opcjonalność można określić jako parametr, pozwalający nam na pewien margines manewru. Pozwala on nam w przypadku braku czasu przesunąć mniej istotne zadania na kolejny cykl tygodniowy (bądź kwartalny, oczywiście jeżeli projekt powstaje pod konkretne zamówienie, po konsultacjach z klientem).

Opcjonalność może przybierać różne formy – doskonałym przykładem jest firma Google, która pozwala pracownikom 20% czasu pracy poświęcić na dowolny projekt, którym są zainteresowani. Jest to tak zwana “zasada 20 procent“, która pozwoliła powstać takim aplikacjom jak GMail, Google News czy AdSense

Co dalej?

W kolejnej części opiszę resztę podstawowych praktyk extreme programming.

(c.d.n.)

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

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