Programowanie ekstremalne

Wstęp

W dziedzinie tworzenia oprogramowania, w latach 80-90 nasilił się syndrom LOOP. Powstające oprogramowanie stawało się coraz bardziej złożone, a ludzie nie mieli sposobu na poradzenie sobie z tą złożonością. W związku z tym powszechne stawało się przekraczanie terminów, nadwyrężanie budżetu, programiści wypracowywali wiele nadgodzin, a w rezultacie system miał niższą jakość.

Odpowiedzią na te problemy były standardy i wymagania dotyczące procesów wytwarzania oprogramowania. Wszystkie one zakładały, że należy stworzyć procedury wykonywania poszczególnych czynności w projektach informatycznych, a następnie zmusić programistów do ich przestrzegania.

Jednym z najbardziej znanych standardów dotyczących jakości (nie tylko w projektach informatycznych) jest standard ISO 9000. Pierwsza wersja tego standardu powstała już w 1987 roku, kolejne w 1994 i 2000. Standard ten wymagał, aby firma udokumentowała wszystkie swoje procedury związane z wytwarzaniem oprogramowania. Następnie specjalny audytor sprawdzał te procedury i firma otrzymywała certyfikat ISO 9000. Dojrzałość firmy badano jedynie przez pryzmat tych zdefiniowanych procedur i jeżeli firma takowych nie posiadała była uważana za gorszą, mimo że mogła produkować świetne oprogramowanie.

Model CMM (Capability Maturity Model)

Innym sposobem na ocenę procesów wytwarzania oprogramowania w przedsiębiorstwie jest model dojrzałości CMM, opracowany przez Software Engineering Institute z Carnegie-Mellon University. Model był rozwijany w latach 1987-1997. Od 1997 roku zaczęto pracować nad nowszą wersją nazwaną CMMI, która była pozbawiona wielu wad modelu CMM.

Model CMM dzieli firmy na 5 poziomów, w zależności od ich potencjalnych możliwości wyprodukowania oprogramowania wysokiej jakości. Z każdym poziomem związany jest zbiór standardów (procedur), które muszą być przestrzegane w firmie.

Poziom pierwszy - nie nakłada żadnych wymagań. Każda firma wytwarzająca oprogramowanie znajduje się początkowo na tym poziomie.

Pomiędzy poziomem pierwszym, a drugim obserwujemy ogromną różnicę. Poziom pierwszy nie nakłada żadnych wymagań, natomiast na poziomie drugim należy mieć opracowane dosyć dojrzałe procesy wytwórcze. Wybrane procedury dla poziomu 2 przedstawione są na slajdzie. Dotyczą one podstaw zarządzania projektem, w celu śledzenia kosztu i harmonogramu. Przy każdym kamieniu milowym następuje zbadanie postępów projektu.

Niestety, podejścia zorientowane na procedury i dyscyplinę mają poważne wady. Niektórzy zarzucają, iż dużo czasu trzeba poświęcić na administrację, zamiast na pisanie oprogramowania. Inni mówią o papierowej fikcji - dokumenty często powstają sztucznie, tylko dlatego, że są wymagane, ale nic z nich nie wynika. Kolejny argument to opinia, iż nie zawsze skupienie się na jakości procesu skutkuje wysoką jakością produktu. Jedną z największych wad jednak są sztywne procedury. Po opracowaniu procedur i otrzymaniu certyfikatu (kosztownego zresztą) nie można dowolnie ich zmieniać, nawet wtedy, gdy zmiana ta skutkowałaby oczywistą poprawą procesu. Po każdej zmianie wymagany jest ponowny audyt, na co nie wszystkie organizacje stać.

Ostatni argument przeciwko zorientowaniu na dyscyplinę - opracowane procedury zabijają inicjatywę i elastyczność. Dobrze obrazuje to rysunek na slajdzie. Podsumowując: W podejściu zorientowanym na procedury i dyscyplinę starano się poprawić jakość wytwarzanego oprogramowania. Niestety poprawiając jedną rzecz, zaniedbano inną, jaką jest fakt, iż praca programisty to praca twórca. Tego rodzaju pracy nie można dobrze opisać za pomocą zbioru procedur, a następnie rygorystycznie ich przestrzegać.

Extreme Programming (XP):

  • lekka (ang. agile) metodyka rozwoju oprogramowania
  • 1999
  • Kent Beck

Dlatego też, pod koniec lat 90-tych zaczęto obserwować irytację podejściami nastawionymi na kontrolowanie procedur i dyscyplinę. Ludzie zastanawiali się, w jaki sposób można "odchudzić" procesy wytwarzania oprogramowania, przy zachowaniu wysokiej jakości (lub czasem wręcz jej poprawieniu). W ten sposób powstały "lekkie" metodyki rozwoju oprogramowania, których dobrym przykładem jest Programowanie Ekstremalne, po angielsku zwane również "XP". XP zostało wymyślone przez Kenta Becka w latach 1996-1999, kiedy to pracował w firmie Chrysler nad oprogramowaniem przetwarzającym listy płac dla 87000 pracowników.

Manifest zwinności

  • Luty 2001, Snowbird, Utah, 17 osób:
  • Kent Beck
  • Alistair Cockburn
  • Martin Fowler
  • Jim Highsmith

W 2001 roku w kurorcie narciarskim Snowbird w stanie Utah w USA spotkało się 17 osób związanych ze zwinnymi metodykami. Ważniejsze osobistości to:

  • wspomniany już Kent Beck - twórca metody kart CRC stosowanej podczas analizy obiektowej, autor narzędzi xUnit - wspomagających testowanie jednostkowe oraz twórca XP
  • Alistair Cockburn - autor rodziny zwinnych metodyk Crystal, oraz książek poświęconych inżynierii wymagań (głównie przypadkom użycia)
  • Martin Fowler - twórca pomysłu refaktoryzacji, autor świetnej książki "UML Distilled" (UML w kropelce)
  • Jim Highsmith - autor metodyki Adaptive Software Development

Osoby te miały już pewne doświadczenia związane ze zwinnymi metodykami wytwarzania oprogramowania, a spotkały się w celu przedyskutowania wspólnych zasad tych metodyk.

W wyniku tego spotkania powstał tzw. manifest zwinności, czyli zbiór 4 podstawowych zasad zwinnych metodyk wytwarzania oprogramowania.

Postulują oni, iż ważniejsze:

  1. Jednostki i interakcje niż procesy i narzędzia, czyli ewidentnie sprzeciwiają się podejściom zorientowanym na procedury i dyscyplinę
  2. Działające oprogramowanie niż obszerna dokumentacja - stawiają na jakość produktu końcowego
  3. Współpraca klienta niż negocjacja kontraktu
  4. Nadążanie za zmianami niż trzymanie się planu

Wartości XP

Są to po kolei: komunikacja, prostota, sprzężenie zwrotne, odwaga, szacunek.
Jak widać, są one bardzo ogólne, można by powiedzieć, że aż dziwne, że dotyczą one podejścia do wytwarzania systemów informatycznych. Kent Beck stawia jednak bardzo mocno na dobre relacje pomiędzy firmą informatyczną, a klientem, stara się zbudować atmosferę zaufania - wtedy dużo łatwiej się porozumieć, zwłaszcza w sprawach spornych.

Komunikacja

Pierwszą wartością XP jest komunikacja. Budowanie systemów informatycznych wymaga przekazania wymagań od klienta do programistów. W tradycyjnych metodykach wykorzystuje się w tym celu dokumenty (specyfikację wymagań). XP posługuje się komunikacją werbalną, dzięki czemu wiedza o systemie bardzo szybko rozprzestrzenia się w zespole. Dzięki komunikacji wszyscy członkowie zespołu mają takie samo wyobrażenie przyszłego systemu i wiedzą w jakim kierunku projekt dąży.

Prostota

Drugą wartością jest prostota. XP zachęca do rozpoczęcia najprostszym możliwym rozwiązaniem problemu (minimalnym, spełniającym pewne początkowe wymagania). Dopiero kiedy się upewnimy że idziemy w prawidłowym kierunku, na tej podstawie dobudowujemy resztę. XP radzi sobie za pomocą refaktoryzacji. Refaktoryzacja, to metoda poprawiania architektury obecnego rozwiązania za pomocą małych przekształceń, zamiast tworzenia wszystkiego od nowa. Tak więc dzięki refaktoryzacji jakość produktu jest stale na najwyższym poziomie. Dzięki prostocie programiści skupiają się na projektowaniu i kodowaniu na potrzeby bieżącego dnia, a nie robią nic na wyrost. Ta wartość jest powiązana z "komunikacją", gdyż prostota architektury i kodu ułatwia zrozumienie, przez co komunikacja staje się łatwiejsza.

sprzężenie zwrotne

Kolejna wartość to sprzężenie zwrotne. W programowaniu ekstremalnym sprzężenie zwrotne dotyczy różnych wymiarów:

  • systemu - ważna jest odpowiedź systemu, otrzymywana w procesie testowania jednostkowego. Dzięki testom programiści mogą bardzo szybko sprawdzić poprawność odpowiedzi systemu w momencie wprowadzania zmian.
  • klienta - w postaci testów akceptacyjnych. Klient przygotowuje takie testy wraz z testerem, gdyż sam nie ma niezbędnej wiedzy informatycznej. Dzięki takim testom można sprawdzić w jakim stanie znajduje się aktualnie budowany system
  • zespołu - w momencie kiedy klient proponuje nowe wymagania podczas gry planistycznej, zespół podaje szacunki ile czasu zajmie ich zaimplementowanie. Dzięki temu klient może podjąć decyzję, czy dane wymaganie będzie realizowane od razu, w przyszłości, a może w ogóle.

Odwaga

Odwaga jest również postrzegana w wielu wymiarach. Po pierwsze, odwaga jest potrzebna, aby przestrzegać zasady projektowania i kodowania wg aktualnych potrzeb, bez zastanawiania się co będzie potrzebne w przyszłości.
Po drugie, odwaga, aby nie angażować się za bardzo w projektowanie i od razu przejść do kodowania.
Po trzecie, odwaga jest potrzebna, aby zrefaktoryzować kod, wtedy kiedy to jest potrzebne, aby nie bać się refaktoryzacji.
Po czwarte, jeżeli okaże się, że pewien fragment kodu jest już nieprzydatny, lub musi zostać zmieniony, do podjęcia decyzji o wyrzuceniu takiego kodu potrzeba dużo odwagi.

Szacunek

Ostatnia wartość to szacunek. Szacunek do pracy i czasu innych osób w zespole:

  • nie można wysyłać do repozytorium zmian, które nie dają się skompilować lub powodują błędy w testach jednostkowych, gdyż przez to praca innych osób będzie utrudniona, lub niemożliwa i stracą one dużo czasu.
  • poprzez dążenie do najwyższej jakości i szukanie najlepszych rozwiązań projektowych (dzięki refaktoryzacji). Dzięki temu innym osobom będzie dużo łatwiej wykorzystać kod napisany przez nas.

Główne reguły i praktyki XP

Struktura zespołu XP

XP wymienia 2 najważniejsze role osób z zespołu: programiści i klient. Zauważmy, że klient uważany jest za członka zespołu, więc musi przez cały czas pracować razem z informatykami (w jednym pomieszczeniu). Czasem nie występuje w tej roli osobiście, lecz za pośrednictwem przedstawiciela klienta.

Oprócz tego mamy jeszcze kilka ról pomocniczych:

  • tester, którego zadaniem jest napisanie skryptów testowych na podstawie rozmów z klientem
  • coach, to osoba, która pomaga rozwiązywać napotkane problemy
  • tracker natomiast zbiera statystyki dotyczące wykonanych zadań, czasu pracy i tworzy podsumowania postępów projektu

Hydrodynamiczny model projektu

Jest jedna bardzo ważna prawidłowość wszystkich projektów informatycznych. Aby dobrze zrozumieć podejście programowania ekstremalnego, musimy tą prawidłowość poznać. Dobrze ją obrazuje "Hydrodynamiczny model projektu". Istotne jest, aby każdy klient oraz informatyk znał ten model podczas rozmów o wymaganiach systemu. Bez niego może bowiem dojść do wielu nieporozumień i problemów. Projekt informatyczny można zobrazować jako szczelny system hydrodynamiczny 4 zmiennych: daty dostarczenia, kosztu, defektów oraz niekompletności funkcji.

Cykl życia projektu

Kolejny element Programowania Ekstremalnego to cykl życia projektu. W tradycyjnym modelu kaskadowym wytwarzania oprogramowania, na początku mamy rozległą fazę zbierania wymagań, analizy, projektowania, kodowania, a na końcu testowania - zanim klient otrzyma kompletną wersję systemu.

Niestety, w takim podejściu często okazuje się, że gdzieś w początkowych fazach nie zrozumieliśmy się do końca z klientem i wymagania były błędne. W związku z tym końcowy system może się zupełnie rozminąć z potrzebami klienta.

Programowanie Ekstremalne stara się zaradzić temu problemowi poprzez częste wydania systemu, czyli zbudowanie wersji, która jest pokazywana klientowi (a często nawet wdrażana). Dzięki temu klient jest w stanie skonfrontować rezultat ze swoimi oczekiwaniami. W ten sposób kolejne wersje systemu są coraz bliższe wizji klienta.

Cykl życia w XP wygląda zatem następująco: mamy wydania podzielone na przyrosty.

Stosuj częste, krótkie wydania

Każde wydanie ma wartość użytkową i trafia do użytkowników końcowych, dzięki czemu programiści dostają sprzężenie zwrotne.

Wydanie podziel na przyrosty

Przyrosty mają jedynie charakter wewnętrzny. Pośrednie przyrosty niekoniecznie stanowią produkt, z którego klient byłby w stanie skorzystać. Każdy przyrost powinien trwać 2-3 tygodnie, oraz zawierać kilka opowieści użytkownika.

Znajdź metaforę dla systemu

Metafora: wyjaśnia działanie systemu w terminach zrozumiałych dla klienta

Kolejne zalecenie metodyki XP, to wyjaśnienie działania systemu za pomocą metafory, czyli w terminach zrozumiałych dla klienta. Przykładowo możemy powiedzieć, że sterowiec to taka łódka, która pływa w powietrzu. Jeżeli klient znał pojęcie łódki, a nie znał sterowca, to na tej podstawie będzie w stanie przybliżyć sobie obraz systemu. Metafora przydaje się zwłaszcza do ukrycia terminów technicznych, np. zamiast mówić relacja w bazie danych przechowująca dane faktur, można powiedzieć: komputerowy segregator z fakturami.

Klient sam wybiera, w jakiej kolejności funkcje będą implementowane. Robi to podczas gry planistycznej. Na początku, podczas rozmów dot. wymagań systemu spisuje on opowieści użytkownika. Informatycy szacują rozmiar opowieści, podając liczbę osobo-dni potrzebnych do jej zrealizowania. Jeżeli okazuje się, że opowieść jest za duża (np. wykracza poza jeden przyrost), wówczas dzieli się ją na 2 mniejsze. Czasem dana opowieść jest też zbyt mała (np. jej realizacja zajęłaby kilkanaście minut) - wtedy łączy się ją z inną opowieścią.

W momencie kiedy mamy już spisane wstępne opowieści i oszacowane przez informatyków, klient wybiera zakres kolejnych przyrostów. On zna koszt każdej opowieści i może zadecydować czy będzie ona realizowana czy też nie, oraz kiedy będzie realizowana, czyli do którego dwutygodniowego przyrostu należy ją przypisać.

CMM & Zarządzanie zmianą

Kolejna praktyka, która różni się znacznie w stosunku do metodyk nastawionych na dyscyplinę to podejście do zmian. Przykładowo, CMM proponuje następujący proces zarządzania zmianą. Najpierw użytkownik zapisuje żądanie zmiany, następnie kierownik zarządzania konfiguracją wysyła je do programisty, który analizuje zmianę i przygotowuje odpowiedni raport. Na tej podstawie kierownictwo wydaje decyzję, czy zmiana jest dopuszczalna, czy też nie. Jak widać, proces ten jest skomplikowany, więc przetwarzanie zmian w tym modelu jest bardzo kosztowne i czasochłonne.

XP proponuje zupełnie inne podejście bazujące na dobrej współpracy z klientem. Po prostu zakłada, że klient w dowolnym momencie może zmienić zdanie i zaproponować zmianę wymagań. Nie mieliśmy na początku dokładnego kontraktu, który określałby zakres działań oraz koszt projektu. W XP klient płaci na bieżąco za wykonaną pracę i zdaje sobie sprawę z tego, że zmiana elementów już zaimplementowanych będzie go kosztowała dodatkowo. Dzięki temu informatycy nie muszą się martwić, gdyż zawsze dostaną wynagrodzenie za swoją pracę.

Działa to również w drugą stronę - jeżeli programiści dostrzegą pewien problem i zaproponują rozwiązanie, które zmienia wymagania - klient ma do nich zaufanie i również zgadza się na przedstawione rozwiązanie.

Testy akceptacyjne

Kolejna ważna praktyka w programowaniu ekstremalnym, to testowanie akceptacyjne. Testy akceptacyjne, to testy, które pochodzą od klienta. Klient w ten sposób dokładnie określa, jak system musi się zachować w określonych warunkach, aby zaspokoić jego potrzeby. Najlepiej gdy testy te mogą być wykonywane automatycznie, więc gdy są zapisane w języku skryptowym. Niestety - klient rzadko kiedy posiada umiejętności programistyczne. Z pomocą przychodzi tester - czyli osoba, której zadaniem jest zapisanie testów klienta w formie skryptów testowych. W momencie kiedy mamy już takie skrypty, zyskujemy 2 rzeczy:

  • po pierwsze, klient jest pewien, że system spełnia jego wymagania
  • uruchamiając testy na bieżąco jesteśmy w stanie powiedzieć, jak wygląda postęp projektu, czyli ile % funkcjonalności zostało już zaimplementowane.

Obrazowo pokazuje to wykres na slajdzie - poszczególne słupki oznaczają poszczególne przyrosty (i1,1 = wydanie 1, przyrost 1, i1,2 = wydanie 1, przyrost 2, itp), kolor fioletowy - liczbę testów, które zostały pomyślnie wykonane, natomiast czerwony - liczbę testów wykonanych błędnie. Obserwując zmianę takiego wykresu w czasie, widzimy, że kolor czerwony powoli przechodzi w fioletowy, czyli pewne partie systemu zostały zaimplementowane. Słupki cały czas rosną w czasie, gdyż przy każdym przyroście mamy coraz więcej funkcjonalności, a co za tym idzie - coraz więcej przypadków testowych.

Zapewnianie jakości

Jakość ta jest również zapewniana w odmienny sposób niż w przypadku metodyk tradycyjnych:

  • po pierwsze - XP stawia na prostotę rozwiązań (optymalizować kod należy tylko wtedy, gdy jest to konieczne)
  • po drugie - przed rozpoczęciem kodowania należy przygotować przypadki testowe (ang. test-first-coding)
  • tak przygotowane testy są następnie jak najczęściej wykonywane automatycznie - dzięki czemu na bieżąco wychwytywane są błędy
  • do poprawy czytelności kodu stosuje się refaktoryzację
  • Zanim udostępni się zmiany dla innych programistów, należy dokładnie przetestować go za pomocą testów jednostkowych
  • Jeżeli wykryjemy jakiś błąd na przetestowanym kodzie, oznacza to, że sito złożone z testów jednostkowych w pewnym miejscu jest "nieszczelne". W takiej sytuacji należy je "uszczelnić" dodając nowe przypadki testowe zapobiegające przedostaniu się tego błędu w przyszłości
  • Należy również jak najczęściej uruchamiać testy integracyjne i akceptacyjne

Czynniki ryzyka XP

XP nie jest rozwiązaniem uniwersalnym: ma również wiele czynników ryzyka, które mogą się okazać wadami:

  • Założenie, że klient przez cały czas pracuje z zespołem może się okazać nierealne - rzadko który klient może sobie pozwolić na oddelegowanie jednego pracownika na kilka miesięcy (gdyż tyle może trwać projekt)
  • Brak dokumentacji z jednej strony powoduje przyspieszenie projektu, lecz czasem może się okazać, że po pewnym czasie trzeba wrócić do prac nad systemem (np. dodać nową funkcjonalność). Wtedy, bez odpowiedniej dokumentacji, trudno przypomnieć sobie za co poszczególne fragmenty kodu były odpowiedzialne.
  • Niektórzy zarzucają również brak fazy projektowania - twierdzą, że rozwiązania powstają za bardzo ad hoc
  • Krótka perspektywa planowania (planuje się tylko kolejne wydanie) nie pozwala przewidzieć, kiedy system będzie ukończony

Te wady przyczyniają się do tego, że niektórym ludziom trudno skłonić się do wypróbowania zwinnych podejść do wytwarzania oprogramowania.