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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Warunki zapewnienia jakości Dobra 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

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

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

Źródła Kent Beck: Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999 http://www.xprogramming.com http://www.extremeprogramming.org http://www.agile.com http://www.pairprogramming.com http://www.martinfowler.com http://www.xp123.com http://www.thoughtworks.com http://www.rolemodelsoftware.com http://www.industriallogic.com/xp http://www.agilealliance.org Jakość Oprogramowania Agile Programming