LEKKIE METODOLOGIE WYTWARZANIA OPROGRAMOWANIA Wykład 7 Programowanie Ekstremalne (2) Jacek Dajda <dajda@agh.edu.pl> Kraków, 29 listopada 2007
Plan wykładu Praktyki warstwy organizacji projektu Praktyki warstwy pracy z klientem Zastosowanie XP i ryzyko projektów informatycznych Podsumowanie Strona: 2
Praktyki warstwy organizacji projektu
Klient w zespole Gra planistyczna Współwłasność kodu Warstwa organizacji projektu Programowanie parami Kod Testy Warstwa pracy w parach Doskonalenie modelu Prosty projekt Standard kodowania Programowanie sterowane testami Ciągła integracja Małe przyrosty Stałe tempo Warstwa pracy z klientem Testy klienta Metafora
Współwłasność kodu Wyniesione z Open-Source Na czym polega? Każdy programista może zmienić, uzupełnić, dopisać dowolny fragment kodu Kod nie posiada swojego indywidualnego właściciela Co daje? Konsolidacja zespołu Szybkość wprowadzania zmian Dyfuzja wiedzy o systemie Co potrzeba? Kod chroniony testami Istotny standard programowania Zarządzanie zmianami w kodzie (CVS, SVN) Strona: 5
Standard kodowania Na czym polega? Wspólny język dla zespołu Make it impossible to tell who wrote what Pewna norma, nieistotne jak zapisana Najczęściej odnosi się do formatowania, nazewnictwa, zarządzania kodem, coraz częściej do standardu zalicza się wykorzystywane narzędzia Co daje? Sposób na poprawienie komunikacji w ramach zespołu Wspiera Współwłasność kodu, Refaktoring, Programowanie w parach Co potrzeba? Wiele gotowych wzorców (np. Java Code Conventions http://java.sun.com/docs/codeconv) Przydatne automatyczne formatowanie w ramach IDE, może okazać się cenne w ramach pracy z narzędziami do zarządzania wersjami kodu (porównywanie zmian) Strona: 6
Ciągła integracja Jedna z bardziej docenionych i stosowanych praktyk Na czym polega Jej celem jest utrzymanie w pełni zintegrowanego i działającego systemu przez cały czas Polega na dużej częstości procesu integracji tzw. buildy (nawet kilkanaście razy dziennie) Co daje Pozwala na uniknięcie tzw. piekła integracji - najtrudniejsze błędy do usunięcia to błędy integracji Szybkie integrowanie nowych zmian z resztą kodu pozwala na szybkie i wczesne identyfikację błędow Braku częstych integracji zwiększa ryzyko zamrożenia projektu na okres integracji - niemile widziane przez klienta Spójność systemu utrzymana, klient może zobaczyć działający system z najnowszymi funkcjonalnościami Strona: 8
Ciągła integracja (2) Co potrzeba Proces integracji powinien być zautomatyzowany, obecnie spora ilość odpowiedniego oprogramowania Zaleca się integrowanie nowych zmian w czasie nie dłuższym niż jeden dzień Zespół powinien pracować na najnowszej wersji Ciągła integracja wymaga dobrej komunikacji w obrębie zespołu Najczęściej wykorzystuje się specjalną (wydajną) maszynę do przeprowadzania integracji tzw. serwer buildow Tylko jedna para integruje zmiany na raz - zazwyczaj integracja lokalna przed wypuszczeniem zmian do serwera buildów Należy dbać o krotki czas buildów Strona: 9
S erwery ciągłej integracji Wybrane darmowe serwery ciągłej integracji: Cruise Control, http://cruisecontrol.sourceforge.net Continuum, http://maven.apache.org/continuum Luntbuild, http://luntbuild.javaforge.com Zebrane informacje i porówania Krotki opis i linki do serwerow: http://en.wikipedia.org/wiki/continuous Integration Porównanie serwerow: http://docs.codehaus.org/display/damagecontrol/continuo us+integration+server+feature+matrix Strona: 10
Źródła: http://tempomat.objektpark.org
Stałe tempo Na czym polega 40-godzinny tydzień pracy jako rozsądna ilość pracy, zmęczeni programiści popełniają więcej błędów, Stałe tempo: niektorzy mogą pracować dłużej, niektorzy krocej, swoboda w organizacji czasu Dalekowzroczność XP: praca w nadgodzinach jest możliwa, ale na krótką metę Nadgodziny wynikają albo ze zbyt dużej ilości zaplanowej pracy lub z pojawiących się problemów, które nie są łatwe do usunięcia. Z reguły jeśli wyczerpano wszystkie możliwe pomysły rozwiązania ślęczenie kilka następnych nadgodzin nic nie da Lepiej zrobić dzisiaj mniej a dobrze Co daje Nadgodziny powodują zmęczenie i niechęć do pracy, wypoczęty programista jest wydajniejszy Tempo powinno być stałe, umożliwiać stały postęp i nie powodować wypalenia zespołu na dłuższą metę Co potrzeba Dyscyplina Odpowiednia polityka zarządzania projektem i zespołem Strona: 12
Praktyki warstwy pracy z klientem
Klient w zespole Gra planistyczna Współwłasność kodu Warstwa organizacji projektu Programowanie parami Kod Testy Warstwa pracy w parach Doskonalenie modelu Prosty projekt Standard kodowania Programowanie sterowane testami Ciągła integracja Małe przyrosty Stałe tempo Warstwa pracy z klientem Testy klienta Metafora
Metafora Na czym polega Nieformalny opis systemu Co daje Pozwala na zaproponowanie wspólnego sposobu myślenia (rozumienia) o działaniu systemu (programiści nie mają wiedzy biznesowej, a klienci technicznej Wspolna wizja systemu Wspólny słownik Generalizacja problemów Architektura Strona: 15
Metafora (2) Co potrzebne Tworzona przez wszystkich (zespoł i klienta) - burza mozgów Metafora zrozumiała dla wszystkich Może ulegać zmianie w trakcie projektu Przykład: The Internet is like spiders crawling on a web - when one way is blocked, they just go another way, always trying to get to their goal. Strona: 16
Metafora (3) Ograniczenia metafor Wymagają czasu Czasami bardzo trudno je znaleźć Mogą być za słabe za silne niezrozumiałe dla wszystkich ograniczone Strona: 17
Gra planistyczna Faza planowania dla XP - rozdzielenie części biznesowej i technicznej Dialog pomiędzy klientem i zespołem, polega na znalezieniu kompromisu pomiędzy dostępnymi środkami i czasie a tym co było zadane Efektem jest wyodrębniony zakresu funkcjonalnosci do realizacji spisany na kartach Historii Użytkownika, z podziałem na 1-3 tygodniowe iteracje Klienci odpowiedzialni za Programiści odpowiedzialni za Zakres Ewaluacja historii Priorytet Zależności Kompozycja przyrostow Proces Daty kolejnych przyrostów Szczegółowe planowanie (zadania) Strona: 18
Klient w zespole Podczas gry planistycznej nie uwzględnia się szczegółów Podczas pracy nad szczegółami pojawia się zwykle wiele innych istotnych szczegółów i związanych z nimi problemow W XP rozwiązywaniem problemow biznesowych zajmuje się tylko i wyłącznie klient To wszystko wymaga obecności klienta na miejscu trwania projektu Zwykle jest to praca na poł etatu Dzięki temu klient może śledzić pracę zespołu i postęp projektu Strona: 19
Kiedy klienta nie ma w zespole Możliwe powody klienta na to może być nie stać klient nie ma na to ochoty klient uważa to za stratę czasu (i pieniędzy) Co wtedy (zakładamy, że przeniesienie zespołu nie wchodzi w rachubę)? znalezienie pseudo klienta (proxy) rzadziej po stronie klienta, np. praktykant częściej po stronie zespołu, np. manager zespołu, praktykant wymuszenie na kliencie obecność przynajmniej podczas gier planistycznych częste odwiedziny u klienta, wysyłanie programistow, próba kontaktu przez emaile, komunikatory częsta prezentacja najnowszych wersji systemu uwzględnienie nieporozumień w harmonogramie prac Strona: 20
Małe przyrosty Bezpośrednio związane z grą planistyczną i sposobem planowania projektu w XP Małe przyrosty odnoszą się do czasu, ale co za tym idzie także funkcjonalności Kolejne przyrosty powinny być możliwie najmniejsze zawierając maksimum funkcjonalności użytecznej dla klienta (konkretne wartości) Wydania 6 miesięczne podzielone na 1-3 tygodniowe iteracje Pozwalają na zmniejszenie ryzyka (lepsze dostosowanie do zmiennych wymagań) Są źrodłem sprzężenia zwrotnego Mają wpływ na ocenę pracy zespołu przez klienta (wzrost zaufania) Strona: 21
Testy klienta Każda Historia Użytkownika musi być testowalna. Specyfikację testów umiescza się zwykle na odwrocie karty Historii Za definiowanie testow odpowiedzialny jest klient Zespoł implementuje testy i używa ich do sprawdzenia (i późniejszego pokazania) czy zaimplementowane historie są zgodne z wymaganiami klienta Automatyzacja testow konieczna podobnie jak testów jednostkowych, przydatne w ciągłej integracji Traktowane jak testy jednostkowe: wszystkie testy muszą przejść by iść dalej Środowiska do automatyzacji: FIT http://fit.c2.com (Java,.NET, C++ i inne) Fitnesse http://fitnesse.org, GUI dla FIT Strona: 22
Inne prakyki, zastosowanie XP a ryzyko projektów informatycznych
Inne praktyki i techniki XP Stand-up Meeting Tests for Bugs Optimize Last (Lazy Optimization) Spike Solution Project Velocity Extreme Reuse Support Crisis Open Workspace Strona: 24
Zastosowanie XP Programowanie ekstremalne z pewnością nadaje się to zastosowania w projektach: angażujących nową lub prototypową technologię badawczych nieznacznych o zmiennym zakresie wymagań W przypadku innych projektow wybór XP powinien być ostrożniejszy. Często adaptuje się wybrane praktyki XP lub stosuje hybrydy rożnych metodologii. Strona: 25
XP a typy projektów Jasno określone cele i zakres projektu Cele nie do końca określone, zakres może ulec zmianie Strona: 26
XP a ryzyko w projektach informatycznych Opóźnienia w harmonogramie małe przyrosty, planowanie oparte na empirycznym szacowaniu Anulowanie projektu wczesne wykrycie problemów (m.in. Poprzez działający software) TDD Usterki i bugi Niezrozumienie potrzeb klienta Częsty kontakt, nacisk na komunikację, proste techniki Zmiana wymagań Częsty kontakt z klientem, małe przyrosty, działający software pozwala wcześniej je wykryć Utracenie integralności systemu Ciągła integracja Niepotrzebne funkcjonalności Prosty projekt, YAGNI Obniżenie wydajności zespołu 40-godzinny tydzień pracy Utrata członka zespołu Praca w parach, współwłasność kodu Strona: 27
Podsumowanie
Ograniczenia Kolokacja uczestnikow (Distributed extreme Programming) Zastosowanie do niewielkich projektow/zespołow (XPrince, XP@Scrum) Konieczność pełnego udziału przedstawiciela klienta XP wymaga efektywnej pracy w zespole Strona: 29
Obecna tendencja rozproszonych zespołów programistycznych Obecna tendencja rozwoju oprogramowania: projekty realizowane jednocześnie przez geograficznie rozproszone zespoły Główne przyczyny: rozbudowa tańszych ośrodkow badawczych (np. Indie) specjalizacja ośrodkow badawczych dostępność wykwalifikowanej kadry lokalizacja projektu blisko klienta indywidualne ograniczenia członkow zespołow Zarządzanie rozproszonym projektem wiąże się z: podziałem projektu na niezależne komponenty o wspólnych interfejsach organizowaniem okresowych delegacji i częstych rozmow telefonicznych (lub telekonferencyjnych) położeniem większego nacisku na przygotowywanie szczegółowej dokumentacji w celu usprawnienia komunikacji Strona: 30
Metodologie zwinne a rozproszenie zespołu Metodologie zwinne? Współlokalizacja i dobra komunikacja? Rozproszony projekt Dowolna lokalizacja ale ograniczona komunikacja Strona: 31
Koncepcja rozwiązania problemu Zniesienie wymagania dotyczącego współlokalizacji na przykładzie programistów w parach Strona: 32
Spodziewane efekty Spodziewane efekty zniesienia (lub zmniejszenia) wymagań dotyczących wspołlokalizacji: możliwość korzystania z praktyk metodologii zwinnych w dowolnej konfiguracji geograficznej zespołu obniżenie kosztow projektu ze względu na brak konieczności przemieszczania się członkow zespołu zwiększona odporność projektu na zmieniające się warunki (nieprzewidziane konferencje i delegacje pracowników), organizację projektu (przeniesienie części zespołu do nowej lokalizacji) i indywidualne ograniczenia członkow zespołu (choroba) możliwość szybkich i mniej kosztownych ekspertyz Strona: 33
Dotychczasowe prace Rożne koncepcje i podejścia prezentowane w dotychczasowych Pracach: wykorzystanie narzędzi telekonferencyjnych implementacja dedykowanych narzędzi i systemow wspierających rozszerzanie istniejących narzędzi pod kątem wspierania zdalnej pracy rozwijanie i realizacja koncepcji wirtualnych przestrzeni biurowych Dotychczasowe prace pozwalają na wyrożnienie czterech obszarow projektu, w ramach ktorych można rozważać jego wspieranie w rozproszonym środowisku: Planowanie i zarządzanie Wymiana informacji Programowanie Zarządzanie kodem i integracja Strona: 34
Wspierające narzędzia W aktualnym stanie wiedzy następujące narzędzia oferują wsparcie dla rozproszonych projektow: Planowanie i zarządzanie MILOS ASE, PAM system XPWeb, XPlanner Wymiana informacji e-maile, komunikatory strony wiki narzędzia wideokonferencyjne, typu Whiteboard i application sharing Programowanie Środowisko TUKAN (Smalltalk) Sangam plugin do Eclipse IDE narzędzia wideokonferencyjne i typu application sharing (np. VNC) Zarządzanie kodem i integracja CVS, Subversion systemy ciągłej integracji (np. CruiseControl) Strona: 35
Kontrowersje Brak dokładnego planu Brak szczegółowej dokumentacji i specyfikacji Trudność w śledzeniu zmian projektu Nadmierna (przesadna) prostota Programiści pracujący w parach Testowanie wszystkiego spowalniające pracę Nieformalne podejście do tworzenia oprogramowania Trudność w zarządzaniu Strona: 36
Z perspektywy lat XP utraciło już status myśli rewolucyjnej, nowej i świeżej Spora część z praktyk powszechnie stosowana w firmach: TDD, refaktoring, małe przyrosty, ciągła integracja, wspołwłasność kodu, stand-up meeting etc. Inne praktyki mocno krytykowane: programowanie w parach, prostota, gra planistyczna Pierwsze założenia z książki Becka Extreme Programming Explained zrewidowane Pomimo słabszych punktow XP odegrało i nadal odgrywa ważną rolę w kształtowaniu nowego podejścia do procesu tworzenia oprogramowania Strona: 37
Bibliografia Kent Beck: Extreme Programming Explained Ron Jeffries, Ann Anderson, Chet Hendrickson, Ronald E. Jeffries: Extreme Programming Installed James W. Newkirk, Robert C. Martin: Extreme Programming in Practice Giancarlo Succi, Michele Marchesi: Extreme Programming Examined Continuous integration http://www.martinfowler.com/articles/continuousintegration.html Realizing continuous integration http://www-128.ibm.com/developerworks/rational/library/sep05/lee Integrate often http://www.extremeprogramming.org/rules/integrateoften.html Strona: 38