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

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

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