Złote reguły Extreme Programming

Na początku lat 90-tych dwaj programiści: Kent Beck i Ward Cunnigham zdefiniowali kilka praktycznych reguł, które miały za zadanie uprościć proces wytwórczy oprogramowania. Tak powstała jedna z najbardziej kontrowersyjnych metodyk: Extreme Programming (XP)

Dla wszystkich zainteresowanych zamieszczam 12 praktyk XP wg Kenta Becka:

1. Planowanie. Tworzenie oprogramowania w XP odbywa się przyrostowo przez wdrażanie kolejnych wydań produktu. Planowanie wydania odbywa się przed rozpoczęciem każdej nowej iteracji. Podstawowym celem jest oszacowanie każdej pojedynczej historii użytkownika, powstałej w wyniku gry planistycznej z klientem. Do szacowania używa się jednostek zwanych idealnymi osobo-tygodniami. Idealny osobo-tydzień to tydzień pracy wyłącznie nad programem, bez dodatkowych zajęć, ale wliczający czas testowania programu.
2. Małe wydania. Małe kroki to częste łączenie kodu napisanego przez programistów. Osiąga się je przez podział zadania na małe historie użytkownika. Dzięki temu pojedynczy fragment kodu może być łatwo i szybko wykonany, przetestowany i złączony z reszta systemu. Małe wydania to częste akceptacje powstałego systemu przez klienta. Dzięki ciągłym testom i łączeniu zawsze istnieje sprawnie działająca wersja, a klient nie musi długo czekać na kolejną.
3. Metafora systemu. Każdy zespół programistyczny musi kontaktować się z klientem. Aby możliwe było wzajemne porozumienie potrzebne jest opracowanie wspólnego słownika używanych pojęć. Aby uniknąć problemów z komunikacja oraz ze słownikiem XP stosuje metaforę systemu. Jest to nic innego jak analogiczne do projektowanego oprogramowania pojęcie, które jest w sposób oczywisty zrozumiałe na klienta i dla programisty.
4. Prosty projekt. XP zakłada, ze wymagania klienta, rynku i sytuacja w branży ciągle się zmieniają. Nie ma wiec sensu planować rozwiązań, o których nie wiadomo, czy zostaną wykorzystane w przyszłości. Celem XP jest jak najszybsze i najprostsze osiągnięcie satysfakcji klienta przez dostarczenie oprogramowania, spełniającego postawione wymagania.
5. Ciągłe testowanie. Ciągłe testowanie to podstawowe działanie podczas pisania programu w metodzie XP. Programista jeszcze przed napisaniem danej procedury tworzy kod, który ma ją testować. W ten sposób wcześniej musi pomyśleć o wszystkich rzeczach, które mogą ?pójść źle?. Dzięki temu podczas pisania właściwego kodu procedury zabezpieczy ja przed tymi możliwościami. Pisanie procedury testowej nie powinno jednak trwać zbyt długo i nie powinna być ona zbyt rozbudowana. Zespół dąży do automatyzowania procedur testowych, które są uruchamiane po każdorazowym łączeniu kodu oraz po przerabianiu.
6. Przerabianie. Przerabianie (ang. refactoring) jest konieczne zaraz po przetestowaniu działającej procedury. Przerabianie to według autora sformułowania ?poprawianie projektu istniejącego kodu?. Należy pamiętać, że przerabianie nie może zmieniać zewnętrznego zachowania programu .
7. Programowanie w parach. Jednym z bardziej krytykowanych aspektów XP. Jednakże diametralnie zmienia ono sposób pisania kodu. Podczas gdy jedna osoba (trzymająca klawiaturę) pisze kod, druga na bieżąco go sprawdza, sugeruje możliwe rozwiązania, może służyć pomocą i zwraca uwagę na błędy syntaktyczne. Tak powstały kod jest nie tylko lepszy ale i łatwiej oraz szybciej się kompiluje. Według Kenta pary powinny się miedzy sobą mieszać. Również programiści wewnątrz pary powinni co jakiś czas zamieniać się miejscami.
8. Standard kodowania. XP narzuca wszystkim programistom wspólny standard kodowania i dokumentowania. Standard taki powinien być ustalony i zaakceptowany przez cała grupę. Standard powinien jednoznacznie określać wygląd kodu, ale nie powinien być zbyt długi i szczegółowy. Polecane są opracowania jednostronicowe. Standard dokumentowania zakłada, ze samych komentarzy w kodzie jest jak najmniej. Klasy powinny być tak zaprojektowane by przeznaczenie poszczególnych metod było jasne, a samo działanie oczywiste.
9. Wspólna odpowiedzialność. Dzięki standardom kodowania każdy programista czuje się jak ?u siebie? w każdym fragmencie systemu, nawet jeśli go nie pisał. Zbiorowa praca nad kodem, to jednak nie tylko wspólne pisanie go, ale i wspólna odpowiedzialność za niego. Jeśli trzeba cos zmodyfikować nie ma problemu, bo poprawki może zrobić każdy. XP preferuje umieszczenie całej grupy programistów w jednym pomieszczeniu, co ma pomagać w komunikacji i rozwijaniu życia grupy. Zostawia jednak dla każdego jego prywatną przestrzeń. Do pracy w parach powinny być wyznaczone oddzielne komputery.
10. Ciągłe łączenie. Ciągłe łączenie to integracja programu tak często, jak to tylko możliwe. Programista po wykonaniu każdego nowego fragmentu programu łączy go z systemem. Najczęściej stosuje się jedna maszynę, na której w danej chwili może pracować jedna osoba zajmująca się łączeniem kodu. Ciągłe łączenie jest ułatwione w XP dzięki prostym projektom, ciągłym testom i wspólnej odpowiedzialności za kod.
11. 40-godzinny tydzień pracy. Swego rodzaju symbolem, znakiem rozpoznawczym XP, stało się wymaganie 40-to godzinnego tygodnia pracy. Zespoły programistów powinny być przyzwyczajone do stałej wydajności i stałego obciążenia .
12. Ciągły kontakt z klientem. Aby zadowolić wymagania klienta należy bezwzględnie podążać za jego życzeniami. Co jednak zrobić, gdy klient zapomniał nas o czymś poinformować lub mamy problem który wymaga przekonsultowania? Potrzebny jest kontakt z klientem. Często jest on jednak nieosiągalny, co doprowadza do opóźnień w realizacji projektu. XP zakłada ciągłą możliwość konsultacji z klientem ?na żywo?. W praktyce oznacza to codzienna obecność klienta w zespole programistów. Niektórzy twierdzą, że klient nie jest poważny, jeśli nie może poświęcić wystarczająco dużo czasu dla nowego systemu.

Czy spełnienie tych zaleceń pomoże wykonać w czasie i terminie? Raczej nie, ale ja jestem zwolennikiem bardziej sformalizowanego podejścia Agile.

Reklama