Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Transkrypt

1 Jarosław Kuchta Wymagania jakości w Agile Programming

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 Agile Programming 2

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. Agile Programming 3

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. Agile Programming 4

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

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

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ń. Agile Programming 7

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. Agile Programming 8

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. Agile Programming 9

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. Agile Programming 10

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. Agile Programming 11

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. Agile Programming 12

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

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. Agile Programming 14

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

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. Agile Programming 16

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

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ń. Agile Programming 18

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

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) Agile Programming 20

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

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