Agile Programming a jakość

Prezentacja na temat: "Agile Programming a jakość"— Zapis prezentacji:

1 Agile Programming a jakość
Jarosław Kuchta Jakość Oprogramowania Agile Programming a jakość

2 Wady klasycznych metod zapewnienia jakości
Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu wymagań Utrata łączności z klientem (użytkownikiem) w fazie implementacji Brak pewności co do uzyskanej jakości Jakość Oprogramowania Agile Programming

3 Założenia Agile Programming (1/2)
Najwyższym priorytetem jest zadowolenie klienta, które można zapewnić przez szybkie i ciągłe dostarczanie działającego oprogramowania. Dopuszczalne są zmiany wymagań nawet w późnym stadium projektu. Projekt musi być dopasowywany do zmieniających się wymagań i warunków na korzyść klienta. Działające oprogramowanie jest dostarczane często, co kilka tygodni lub co kilka miesięcy. Im częściej tym lepiej. Potrzebna jest bliska, codzienna współpraca między przedstawicielami klienta i zespołem projektowym. Projekty są oparte o odpowiednio zmotywowanych deweloperów, którym trzeba zapewnić środowisko pracy i zaufać, że wykonają swoją pracę. Najbardziej odpowiednią i efektywną metodą zbierania informacji przez zespół projektowy jest bezpośrednia rozmowa. Jakość Oprogramowania Agile Programming

4 Założenia Agile Programming (2/2)
Działające oprogramowanie jest podstawową miarą postępu prac. Proces opracowywania oprogramowania powinien być stale podtrzymywany przez sponsorów, deweloperów i użytkowników. Potrzebne jest stałe zwracanie uwagi na techniczną doskonałość i dobre projektowanie Upraszczanie ma znaczenie zasadnicze Najlepsze wymagania, projekty i struktury pochodzą od samoorganizujących się zespołów. W regularnych odstępach zespół projektowy zastanawia się nad tym, jak zwiększyć swoją efektywność, następnie odpowiednio zmienia i dopasowuje swoje sposoby postępowania. Jakość Oprogramowania Agile Programming

5 Model cyklu pracy Opowieści użytkownika Planowanie wydania Prototyp
Metafora systemu nieformalne wymagania oszacowanie niepewne oszacowanie potwierdzone Iteracje plan wydania nowa opowieść użytkownika szybkość projektu Testy akceptacyjne ostatnia wersja błędy scenariusze testowe następna iteracja Małe wydanie akceptacja klienta Jakość Oprogramowania Agile Programming

6 Częste tworzenie małych wydań
Częste tworzenie wydań umożliwia lepsze dostosowanie się do wymagań użytkowników (uzyskanie oceny) Jakość Oprogramowania Agile Programming

7 Podział projektu na iteracje
Harmonogram opracowania jest dzielony na 1-3 tygodniowe iteracje. Utrzymuje się stałą długość iteracji. Nie planuje się zadań na przyszłość. Jeśli długość iteracji jest zagrożona, to trzeba usunąć z niej część zadań. Jakość Oprogramowania Agile Programming

8 Planowanie iteracji Każda iteracja trwa od 1 do 3 tygodni.
Na początku każdej iteracji wybiera się opowieści do implementacji. Dla każdej opowieści określa się zadania programistyczne. Wybiera się też testy akceptacyjne, które się nie powiodły w poprzedniej iteracji. Jakość Oprogramowania Agile Programming

9 Prostota Prosty projekt zajmuje o wiele mniej czasu
Jeśli coś jest skomplikowane, to trzeba to zastąpić czymś prostszym Unikaj dodawania funkcjonalności przed uwzględnieniem tego w harmonogramie. Jakość Oprogramowania Agile Programming

10 Unikanie wczesnego dodawania funkcjonalności
Należy unikać dodawania funkcjonalności, które „mogą być użyte później”. Jedynie 10% z nich jest rzeczywiście później wykorzystanych. Jakość Oprogramowania Agile Programming

11 Stosowanie refaktoringu
Programiści stosują dawno już napisany kod, który niekoniecznie pasuje do rozwiązania, ale działa. To rozwiązanie jest nieefektywne. Należy usuwać nadmiarowości, niewykorzystane funkcjonalności, przestarzałe projekty. Jakość Oprogramowania Agile Programming

12 Klient jest zawsze dostępny
Klient ma nie tylko pomagać zespołowi projektowemu, ale ma być jego częścią. Klient pisze opowieści użytkownika. W czasie planowania wydania klient negocjuje wybór opowieści, które mają być włączone do wydania. Klient określa szczegółowe wymagania dla programistów. Klient uczestniczy w testach funkcjonalnych. Jakość Oprogramowania Agile Programming

13 Stosowanie standardów
Kod musi być pisany zgodnie ze standardami. Łatwość czytania dla całego zespołu. Łatwość refaktoringu. Jakość Oprogramowania Agile Programming

14 Moduły testowe Moduły testowe są kodowane w pierwszej kolejności.
Umożliwia to skupienie się na zrobieniu tego, co jest rzeczywiście wymagane. Jakość Oprogramowania Agile Programming

15 Optymalizacja Optymalizację zostawia się na koniec.
Nie próbuje się zgadnąć, co będzie „wąskim gardłem”. To trzeba zmierzyć. Jakość Oprogramowania Agile Programming

16 Testowanie przed rozpowszechnieniem
Kod nie może być rozpowszechniony, jeśli nie przejdzie testów. To umożliwia stosowanie kolektywnej własności kodu. Jakość Oprogramowania Agile Programming

17 Testy akceptacyjne Testy akceptacyjne są tworzone na podstawie opowieści użytkownika. Klient formułuje scenariusze testowe. Jedna opowieść może mieć wiele testów akceptacyjnych. Implementacja opowieści nie jest zakończona dopóki nie przejdzie wszystkich testów akceptacyjnych. Jakość Oprogramowania Agile Programming

18 Wnioski Agile Programming zapewnia większą wydajność tworzenia aplikacji w stosunku do tradycyjnych, „ciężkich” metod (np. RUP). Agile Programming może zapewnić odpowiednią jakość produktu pod warunkiem spełnienia kluczowych założeń. Jakość Oprogramowania Agile Programming

19 Warunki zapewnienia jakości
Dobra, codzienna współpraca (komunikacja) z klientami (użytkownikami końcowymi) w całym procesie wytwarzania. Formułowanie celów wydań na podstawie rzeczywistych wymagań klientów. Stosowanie odpowiednich standardów pracy inżynierskiej. Utrzymanie harmonogramu częstych wydań - ciągła praca nad produktem (!). Pisanie testów przed pisaniem kodu i przeprowadzanie testów przed opublikowaniem każdego wydania. Poddawanie wydań testom akceptacyjnym użytkowników. Jakość Oprogramowania Agile Programming

20 Wady - zagrożenia Uzależnienie procesu od ludzi – zmienność składu zespołu. Brak możliwości powrotu do projektu po dłuższej przerwie – brak dokumentacji. Możliwość przeoczenia poważnych błędów projektowych – sytuacje wyjątkowe i awaryjne. Wysokie koszty wsparcia (pielęgnacji) Jakość Oprogramowania Agile Programming

21 Zastosowanie Proste aplikacje Projekty o niskim poziomie ryzyka
Możliwość nieustannej pielęgnacji produktu Jakość Oprogramowania Agile Programming

22 Źródła Kent Beck: Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999 Jakość Oprogramowania Agile Programming