Agile Development Zwinne tworzenie systemów

Prezentacja na temat: "Agile Development Zwinne tworzenie systemów"— Zapis prezentacji:

1 Agile Development Zwinne tworzenie systemów
Szymon Bohdanowicz

2 Świat systemów IT ŚWIAT SPEKTAKULARNYCH PORAŻEK
% systemów odnosi porażkę zanim uda się je ukończyć Połowa systemów przekracza swój budżet ponad dwukrotnie Zawalone projekty softwarowe kosztują corocznie ponad 100 miliardów USD(tylko w USA) 67% projektów mających na celu zarządzane kontaktami pomiędzy deweloperami i klientami kończy się klapą

3 Przykład NHS National Programme for IT – system dla służby zdrowia w Wielkiej Brytanii Początkowy budżet 6 miliardów funtów – zawieszony gdy pochłonął 12,7 miliarda W momencie zawieszenia opóźniony o ok. 5 lat Spotkał się z powszechną krytyką wszystkich grup użytkowników Na końcu oceniony jako niepotrzebny

4 Change! Nasza wstępna analiza była błędna W czasie projektowania nauczyliśmy się nowych rzeczy Chcemy poprawionego systemu Nie zdarzają się sytuację , których wymogi dla systemu nie ulegają zmianie w czasie jego tworzenia Typowy system wymaga przynajmniej 25% zmiany względem początkowych wymagań Krzywa uczenia się Nauka powoduje zmianę Edwards - Klient Granger – wielki szef Duże i średnie projekty wymagają 25-35% zmiany względem początkowych wymagań Data ukończenia Wycofanie się ze wstępnej specyfikacji

5 są nastawione na radzenia sobie ze ZMIANAMI
Metodologie Agile są nastawione na radzenia sobie ze ZMIANAMI Umiejętność tą uzyskują dzięki iteratywności i inkrementalności

6 6 zasad Agile Development
Klient sporządza listę wymagań i określa ich priorytety Regularne dostarczanie działających modułów według ustalonego planu Klient może wdrożyć software w każdym momencie

7 6 zasad Agile Development cd…
Klient może usunąć, dodać bądź zmienić wymagania w dowolnym momencie Należy dotrzymywać zobowiązań niezależnie od zmian Można zatrzymać rozwój w dowolnym momencie przy jednoczesnym korzystaniu z dotychczasowych osiągnięć

8 Tradycyjny model - waterfall
Analiza Specyfikacja Projekt Implementacja Testowanie i wdrożenia Działanie i serwis

9 Tradycyjny model - waterfall
1. Próba zapobiegania zmianom Krzywa kosztu zmiany Boehma 2. Poznajemy własne błędy w trakcie trwania projektu 6. Zamiast testów poprawki 3. Poprawki są wprowadzane w najdroższym momencie 4. Okres testów nieznany, koszty rosną Wymagania Analiza Projekt Implementacja Testy 5. Konieczna zmiana terminów bądź opóźnienia

10 Zaleta Agile nr 1: Wiele zmian jest za darmo
W momencie gdy pracujemy nad tym inkrementem Wszystkie wymagania …można bezkosztowo zmieniać wymagania pozostałym mają swoje priorytety Backlog

11 Zaleta Agile nr 2: Uniknięcie nadprodukcji
Tradycyjna specyfikacja wymagań jest zgadywanką… jest błędna Wiele funkcjonalności jest niepotrzebnych ale wciąż implementowanych Te bezwartościowe funkcjonalności na dole backlogu ale i tak są implementowane wg metody waterfall Metodyka zwinna daje lepsze rezultaty YAGNI Twórz na potrzeby obecne a nie na przyszłość

12 Zaleta Agile nr 3: Zmiany krytyczne można przetrwać
Metodyka zwinna wymusza pojawienie się zmian krytycznych na początku Lepiej zawalić projekt na początku zanim pieniądze zostaną wydane Większość zmian nie jest kosztowna Średni koszt zmiany Bardzo mała ilość zmian krytycznych Większość zmian Increment 1 Increment 2 Increment 3 Increment 4 Increment 5

13 Zaleta Agile nr 4:Zapobieganie i przyśpieszanie poprawek
Im wcześniej wykryjemy błąd tym łatwiej i taniej go naprawić Zapobieganie błędom najtańsze i najlepsze ale … Wszystkie wymagania Klient jest niemalże zawsze dostępny Stworzenie i zautomatyzowanie testowania przed kodowanie Testy automatyczne pozwalają na szybkie wykrywanie błędów wstecznych Ciągła integracja oprogramowania przyczynia się do szybszego wykrywania błędów Programowanie w parach pozwala na szybsze wykrywanie błędów mają swoje priorytety Backlog

14 Zaleta Agile nr 5:Projekt może być łatwo zmieniony
Zwinna metodyka tworzy działające oprogramowanie na innym działającym oprogramowaniu, które jest zbudowane na innym działającym oprogramowaniu, które… Każdy inkrement jest Wolny od błędów– możliwy do wdrożenia Dobrze zaprojektowany Refactoring czyni kod czystym Testy automatyczne działają jak lina bezpieczeństwa Wszystkie wymagania Wszystkie wymagania Dobry projekt = łatwy do zmiany = tani do zmiany mają swoje priorytety mają swoje priorytety Backlog

15 Zysk Agile vs Zysk Waterfall