Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

EXtreme Programming – czyli coś ekstremalnie zwinnego Szymon Bohdanowicz.

Podobne prezentacje


Prezentacja na temat: "EXtreme Programming – czyli coś ekstremalnie zwinnego Szymon Bohdanowicz."— Zapis prezentacji:

1 eXtreme Programming – czyli coś ekstremalnie zwinnego Szymon Bohdanowicz

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

3 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

4 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

5 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

6 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

7 Statystyka projektów Wielkość projektu (w punktach funkcjonalności) Przed terminem Na czas Opóźniony Zakończony fiaskiem Suma %83.16%1.92%0.25%100.00% %81.25%5.67%2.00%100.00% %74.77%11.83%7.33%100.00% 1, %60.76%17.67%20.33%100.00% 10, %28.00%23.83%48.00%100.00% 100, %13.67%21.33%65.00%100.00% Średnia5.53%56.94%13.71%23.82%100.00% z Patterns of Software Systems Failure and Success, Capers Jones Termin dostarczenia projektu

8 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)

9 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

10 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

11 Economics of software development

12 Co jeśli…

13 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.

14 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

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

16 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

17 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.

18 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

19 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.

20 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.

21 Praktyki, zwyczaje charakterystyczne dla XP The Planning Game* Krótki cykle(inkrementy) Metafora systemu (wspólne wyobrażenie) Prostota projektowania* Testy* Refaktoring* Programowanie w parach* 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)

22 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.

23 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

24 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

25 Testy jednostkowe(Unit Tests)

26 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

27 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

28 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

29 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

30 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

31 Kto zyskuje na XP? 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 Programiści\deweloperzy:Klienci:

32 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

33 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)

34 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ń

35 Dodatkowe materiały


Pobierz ppt "EXtreme Programming – czyli coś ekstremalnie zwinnego Szymon Bohdanowicz."

Podobne prezentacje


Reklamy Google