eXtreme Programming – czyli coś ekstremalnie zwinnego Szymon Bohdanowicz

Treść prezentacji Problem eXtreme Programming (XP) Wnioski Problemy spotykane przy tworzeniu systemów eXtreme Programming (XP) Wartości Techniki, praktyki Dlaczego XP działa Korzyści XP Wnioski

Podstawowe problemy napotykane w czasie produkcji oprogramowania Zagrożenia: Niedotrzymanie terminów Niezrozumienie modelu biznesowego Wysoki poziom błędów Wstrzymanie projektu Starzenie się systemu Zmiana w modelu biznesowym klienta eg. Netscape 6 No communication after requirements analysis, or, Business needs changes Time pressure, quality sacrificed for short-term speed gain Bigger projects have good chance of being cancelled: low visibility, large budgets/timeframes System delivered, works, but complex and/or fragile

Problem z terminowością Wiele projektów nie kończy się w ustalony terminie Przykład : Diablo 2, systemy dla ZUS Niektórych deadline’ów nie można przesunąć Przykład: systemy na Euro 2012 Co jeśli: uda nam się jednak dostarczyć główne funkcjonalności na czas

Problem z rozpoznaniem realnych potrzeb klienta(modelu biznesowego) Bez bezpośredniej komunikacji z klientem programista/deweloper może tylko zgadywać co powinien wyprodukować(nie mówiąc o tym, że klient na ogół nie ma pojęcia czego chce) Przykład: Systemy audytowe Co jeśli: klient będzie w stanie przekazać swe oczekiwania dotyczące systemu

Problem z awaryjnością systemu System został sprzedany, wprowadzony do użytku jednak jego jakość uniemożliwia efektywne wykorzystanie. Co jeśli: udało się zautomatyzować testy

z Patterns of Software Systems Failure and Success, Capers Jones Statystyka projektów Wielkość projektu (w punktach funkcjonalności) Przed terminem Na czas Opóźniony Zakończony fiaskiem Suma 1 14.68% 83.16% 1.92% 0.25% 100.00% 10 11.08% 81.25% 5.67% 2.00% 100 6.06% 74.77% 11.83% 7.33% 1,000 1.24% 60.76% 17.67% 20.33% 10,000 0.14% 28.00% 23.83% 48.00% 100,000 0.00% 13.67% 21.33% 65.00% Średnia 5.53% 56.94% 13.71% 23.82% Termin dostarczenia projektu Todo: function point http://www.yourdon.com/books/y2k2020/11.dejavu.html z Patterns of Software Systems Failure and Success, Capers Jones

Problem – projekt zawieszony/zamknięty Co jeśli: krótkie cykle produkcyjne(inkrementy) umożliwiają dostarczenie przynajmniej częściowo działającego oprogramowania (zainwestowane pieniądze mają odzwierciedlenia w dostarczonym produkcie)

Problem starzenia się systemu Software jest wykorzystywany, działa prawidłowo, jednak z czasem koszt jego modernizacji, wprowadzenia poprawek jest bardzo wysoki – tańsza okazuje się produkcja nowej aplikacji niż utrzymywania dotychczasowej. Co jeśli: kod jest czysty, klarowny a projekt czytelny

Problem zmieniającego się świata – wraz z nim wymagań wobec systemu Zmiany w prawie, nowe warunki rynkowe, rozwój technologii wymuszają modyfikacje modelu biznesowego klienta Co jeśli: klient może się rozmyślić, zmienić zdanie definiując inne funkcjonalności, określić na nowo priorytety

Economics of software development

Co jeśli…

eXtreme Programming Zbiór technik, praktyk wypracowywanych przez środowisko deweloperów/programistów softwarowych, które mają na celu szybką produkcję oprogramowania wysokiej jakości, łatwo dostosowującego się do zmian w wymaganiach.

eXtreme… Nadanie sprawdzonym rozwiązaniom charakteru ekstremalnego Testowanie jest dobre - niech wszyscy ciągle testują Ocenianie kodu jest dobre – prowadźmy ciągłą ocenę Projektowanie jest dobre - niech wszyscy projektują (udoskonalają system - refaktoring) Testy integracyjne są dobre – integrujmy bez przerwy Prostota jest dobra - wybierajmy najprostsze możliwe rozwiązania Krótkie cykle są dobre – zróbmy je naprawdę bardzo krótkimi Take practices that have been proven to be good and take them to the extreme.

Wartości przyświecające XP naczynia powiązane Komunikacja/kontakt/współpraca Prostota/klarowność/czytelność Informacja zwrotna(and. feedback) Odwaga Szacunek

Komunikacja Kontakt pomiędzy klientem a twórcami systemu jest kluczem do sukcesu Klient powinien być w pełni dyspozycyjny Komunikacja i współpraca wewnątrz zespołu nie powinna napotykać jakichkolwiek barier

Prostota Skupienie się na głównych celach – proste rozwiązania – optymalizacja, dodatkowe funkcjonalności dodawane później. Realizacja potrzeb tylko dzisiejszych -YAGNI Dzięki prostocie kod może być łatwo rozumiany przez innych.

Feedback – informacja zwrotna Informacja zwrotna z systemu – dzięki testom jednostkowym system natychmiast udziela odpowiedzi dotyczącej jego stanu Informacja zwrotna od klienta – testy akceptacyjne (pisane wspólnie przez klienta i programistę) mówią o poziomie spełaniania wymagań Informacja zwrotna od zespołu – w sytuacji gdy klient przedstawia nowe wymagania, oczekiwania zespół natychmiastowo szacuje zasoby, które muszą być zaangażowane

Odwaga Przy refaktoringu – jeśli uważasz, że coś można poprawić zrób to! Przy usuwaniu fragmentów przestarzałych – jeśli uważasz część aplikacji za zbędną, przestarzałą usuń ją(nieważne jak wiele pracy ona pochłonęła) Przy rozwiązywaniu skomplikowanych problemów – jeśli pracujesz nad czymś długo bądź wytrwały, nie rezygnuj.

Szacunek(wobec siebie i innych) Programista nie powinien dodawać(commit) kodu, który nie przechodzi kompilacji, sypie się na testach lub utrudni pracę innym. Wzajemne szanowanie własnej pracy polega na ciągłym refaktoringu(doskonaleniu) kodu.

Praktyki, zwyczaje charakterystyczne dla XP Wspólnota własność kodu Ciągła integracja systemu 40 godzinny tydzień pracy Pełny dostęp do klienta Standardy kodowania/projektowania Otwarta przestrzeń pracy(openspace) The Planning Game* Krótki cykle(inkrementy) Metafora systemu (wspólne wyobrażenie) Prostota projektowania* Testy* Refaktoring* Programowanie w parach*

The Planning Game Release planning(planowanie wydania,etapu): Exploration phase(faza poszukiwań): Spisanie oczekiwań, wymagań (user story cards) Oszacowanie zasobów(czas, ludzie) Podział oczekiwań, wymagań na mniejsze Commitment phase(faza zaangażowania): Sortowanie wymagań wg wartości(krytyczne, istotne, przydatne) Sortowanie wg ryzyka(niskie, średnie, wysokie; kompletność, zmienność, skomplikowanie) Oszacowanie prędkości, możliwego tempa pracy Wybór zakresu Steering phase(faza sterowania): Czas na zmiany, dostosowanie do nieoczekiwanych zdarzeń, warunków. Big subject: will gloss over it Release planning & iteration planning

The Planning Game Iteration planning(planowanie cyklu): Exploration phase(faza poszukiwań): Przetłumaczenie kart na zadania Połączenie/podział zadań Oszacowanie potrzebnego czasu na zadanie Commitment phase(faza zaangażowania): Wybór zadań Programista szacuje ile czasu zajmie mu zadanie Ustalenie czynnika obciążenia(load factor) Zbilansowanie zadań(wyrównanie obciążenia) Steering phase(faza sterowania): Implementacja – znalezienie partnera-> zaprojektowanie rozwiązania-> testy jednostkowe-> kodowanie -> refaktoring -> testy funkcjonalne

Testy Unit Testy and Functional Tests Troszkę testuj, troszkę koduj(Test a little, code a little…) “Test-first programming” Testy stają się wyznacznikiem wymagań Testy nadają systemowi stabilność Testy dodają programistom odwagi w momencie wprowadzania zmian

Testy jednostkowe(Unit Tests)

Programowanie w parach Dwie osoby siedzą przed jednym komputerem, jedna klawiatura, jedna myszka. Każdy ma swoją rolę: jeden koder/programista, jeden projektant/deweloper Cały kod implementacji jest pisany w parach

Zalety programowania w parach 15% mniej kodu niż w przypadku dwóch niezależnych programistów Ciągła weryfikacja, ocena kodu: lepsza jakość, mniej błędów Większa pewność, gotowość do wprowadzania zmian, nowych funkcjonalności Utrzymanie zwyczaju ciągłych testów i rekatoringu Wzajemna wymiana poglądów, spostrzeżeń dotyczących działania systemu Nauka nowych umiejętności od partnera http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm (Alistair Cockburn & Laurie Williams) Partner is a safety net: changing the system is not scary

Prostota w projektowaniu Twórz/projektuj kod najprostszymi i najszybszymi sposobami Kod przejdzie większość testów Brak powtórzeń w kodzie(usunięcie redundancji) States every intention Mniej klas i metod

Refactoring Projektowanie staje się dla każdego codzienną czynnością Ciągła praca nad udoskonalaniem kodu Testy jednostkowe i programowanie w parach dodają odwagi Rezultaty: Szybkie tempo rozwoju systemu Kod staje się elastyczny, łatwy do zmiany

Jak/Dlaczego XP działa?! Lekkość: solidność bez biurokracji Pod presją ludzie wybierają rozwiązania najprostsze: All XP practices have short-term benefits as well as long-term benefits Rozwój jako forma/rezultat komunikacji Kod jest dokumentacją(jak to możliwe? – standardy kodowania) XP dostarcza dużo radości

Kto zyskuje na XP? Programiści\deweloperzy: Klienci: Dostają klarowny, czysty zestaw wymagań i priorytetów can do a good job Mogą podejmować decyzje techniczne i projektowe Nie muszą wyrabiać nadgodzin get most business value first Dostają czytelną informację zwrotną can make informed business decisions Mogą zmieniać zdanie

Wnioski W jakich sytuacjach warto zdecydować się na prowadzenie projektu wg XP: gdy system tworzony jest dla obszaru podlegającego ciągłym zmianom, funkcjonalności są trudne do sprecyzowania gdy mamy do dyspozycji małe zespoły pracowników XP jest nastawione na prędkość XP dostarcza dużo radości

Zarzuty wobec XP Bardzo kosztowny dla klientów(zasada pełnej dostępności) Brak dokumentacji, całościowego projektu Wiąże się z całkowita zmianą względem tradycyjnej kultury pracy W XP muszą być zaangażowanie doświadczenie, dobrzy programiści /deweloperzy Jako, że skupia się na funkcjonalnościach trudno jest przekazać oczekiwanie nie związane bezpośrednio z nimi(user story cards) Może prowadzić do niekontrolowanego rozrostu projektu(scope creep)

Zarzuty wobec XP Niemożliwym w zasadzie jest realne oszacowanie zasobów dla realizacji całego projektu(skoro na początku nic nie wiadomo – wszystko się może zmienić w trakcie) Bez pełnego zaangażowania sukces nie jest możliwy Ciągła zmiana oczekiwań może prowadzić do bezustannego przeprogramowywania jednego obszaru – nie jest brane podczas szacunków, tworzenia harmonogramu Negocjacje kontraktowe z klientem są niezwykle trudne Kolejne deliwerable nie są jasno określane – może prowadzić do nadużyć, wyłudzeń

Dodatkowe materiały www.junit.org www.xprogramming.com www.extremeprogramming.org www.refactoring.com www.pairprogramming.com http://www.martinfowler.com/articles/designDead.html