Jest to jedenasty wykład w tym cyklu i będzie dotyczył podejść do projektów informatycznych, a w szczególności Programowania Ekstremalnego.
Zaczniemy od krótkiego wprowadzenia…
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.
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ć.
Po tym krótkim wprowadzeniu zostaną przedstawione następujące tematy:
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:
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:
Przejdźmy do wartości XP. XP wymienia pięć wartości (początkowo były 4, jedna została dodana w drugim wydaniu książki Kenta Becka), na których zbudowana jest metodyka. Zobaczmy, co to za wartości…
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.
Tak więc po kolei…
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.
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ę.
Ktoś z Państwa zaraz zacznie się buntować - przecież w momencie kiedy tak eksperymentujemy i budujemy stopniowo wielu rzeczy nie będziemy w stanie przewidzieć na początku, natomiast kiedy trzeba będzie je zrobić, okaże się że musimy „łatać” obecne rozwiązanie. W ten sposób w bardzo krótkim czasie architektura systemu może się popsuć, a jakoś znacznie spadnie.
XP radzi sobie z tym problemem 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.
Kolejna wartość to sprzężenie zwrotne.
W programowaniu ekstremalnym sprzężenie zwrotne dotyczy różnych wymiarów:
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
Ostatnia wartość to szacunek. Szacunek do pracy i czasu innych osób w zespole:
Podsumujmy. Najważniejsze wartości XP to: komunikacja, prostota, sprzężenie zwrotne, odwaga, szacunek.
Zauważmy, że w odróżnieniu od podejść zorientowanych na dyscyplinę, nie ma tutaj mowy o procesach, dokumentacji, narzędziach. Najważniejsi są ludzie, gdyż to oni tworzą rozwiązania informatyczne.
Przejdźmy do szczegółów metodyki programowania ekstremalnego. Po kolei zapoznamy się z jej regułami…
Najpierw omówimy strukturę zespołu XP.
XP wymienia 2 najważniejsze role osób z zespołu:
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:
XP bardzo mocno stawia na współpracę zespołu z klientem. Zakłada pełne zaufanie członków zespołu do klienta, oraz klienta do członków zespołu.
Po pierwsze - przedstawiciel klienta jest ciągłym źródłem wymagań. Wymagania są przedyskutowywane z nim na bieżąco, natomiast ślad z tych dyskusji jest przechowywany w formie opowieści użytkowników.
Każda opowieść jest zapisana w kilku zdaniach na małej kartce papieru. Może byćoznaczona dodatkowymi atrybutami (np. data utworzenia, typ, numer, rozmiar).
Opowieść użytkownika nie jest kompletnym wymaganiem - wymagania bowiem są jedynie przekazywane w bezpośredniej rozmowie.
Po co więc zapisywać opowieści użytkownika? Powodów jest kilka:
Ważne, aby każda opowieść miała wartość dla klienta i była testowalna!
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.
W momencie kiedy chcemy obniżyć koszt projektu, na pewno wzrośnie nam jedna z innych zmiennych, np. niekompletność.
Znając tę prawidłowość możemy „sterować” projektem. Np. zwiększyć jakość (obniżyć poziom defektów) poprzez zwiększenie kosztu, lub przy zachowanym koszcie - zrezygnować z niektórych funkcji.
Prawidłowość ta jest wykorzystywana w XP: zakładamy niski poziom defektów, a klient sam steruje kosztami w zależności od tego ile funkcjonalności sobie życzy.
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.
Cykl życia w XP wygląda zatem następująco: mamy wydania podzielone na przyrosty.
Każde wydanie ma wartość użytkową i trafia do użytkowników końcowych, dzięki czemu programiści dostają sprzężenie zwrotne.
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.
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ę.
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:
Jakość ta jest również zapewniana w odmienny sposób niż w przypadku metodyk tradycyjnych:
Więcej informacji o refaktoryzacji otrzymacie Państwo podczas kolejnego wykładu. Po krótce jednak - refaktoryzacja to sposób na systematyczną poprawę jakości kodu i ewolucję architektury produktu.
Załóżmy, że mamy do przeprowadzenia dużą zmianę w oprogramowaniu. Zamiast wykonywać ją od razu na starej wersji systemu, robi się to stopniowo:
Takie podejście pozwala na bezpieczne wprowadzanie zmian architektonicznych - w przypadku kiedy dotychczasowa architektura nie pasuje do nowych wymagań.
Kolejnych kilka zasad związanych z zapewnieniem jakości:
W tym podejściu, przy jednym komputerze siedzą 2 osoby jednocześnie: autor i recenzent. Autor pisze kod, natomiast recenzent na bieżąco go przegląda i wychwytuje defekty.
Autor jest bardzo skupiony na tworzeniu kodu, a recenzent ma więcej czasu na myślenie. Może się okazać zatem, że znajdzie lepszy sposób na rozwiązanie problemu, lub np. dostrzeże problemy związane z testowaniem obecnego kodu, lub po prostu wychwyci błąd w programie.
XP zaleca, żeby każdy fragment kodu powstał poprzez programowanie parami. Aby można było wygodnie pracować w parach, potrzebny jest wspólny standard kodowania dla całego zespołu.
XP zakłada również, że będą następować częste zmiany w parach, tak aby każda osoba pracowała nad każdym fragmentem systemu. Ma to dodatkową zaletę w postaci przepływania wiedzy pomiędzy poszczególnymi programistami. Dodatkowo w momencie kiedy jeden programista odejdzie z zespołu, dla każdego fragmentu kodu znajdziemy inną osobę, która będzie znała ten fragment.
W XP nie ma osoby odpowiedzialnej za każdą część kodu - kod jest własnością całego zespołu.
Nie da się wydajnie pracować parami, jeżeli nie ma w firmie systemu zarządzania wersjami, np. CVS.
Wymagana jest również otwarta przestrzeń pracy dla zespołu - aby poszczególne osoby mogły się łatwo komunikować.
XP nie jest rozwiązaniem uniwersalnym: ma również wiele czynników ryzyka, które mogą się okazać wadami:
Te wady przyczyniają się do tego, że niektórym ludziom trudno skłonić się do wypróbowania zwinnych podejść do wytwarzania oprogramowania.
Podsumujmy wykład:
