3. Tworzenie oprogramowania dotychczas
Waterfall – tradycyjne podejście w procesie wytwarzania
oprogramowania
Analiza Design Development Testowanie Wdrożenie
Pełna sekwencyjność
bardzo utrudniona możliwość zmiany wcześniejszych decyzji
2014-11-24 3
4. Konieczność zmian
Brak efektywności dotychczasowego podejścia
Wysoki współczynnik projektów zakończonych porażką
Według raportu CHAOS w 1998 roku:
— 26% projektów zakończonych zostało z sukcesem
— 28% zakończonych zostało porażką
— 46% projektów przekroczyło budżet bądź planowany termin zakończenia
Zderzenie narzuconej metodyki z „rzeczywistością projektu”
Brak szybkiej możliwości reagowania na zmiany
Niska jakość dostarczanego oprogramowania
2014-11-24 4
5. Sama iteracyjność nie zapewnia Agile
Analiza Kodowanie Testowanie
2014-11-24 5
Analiza Kodowanie Testowanie
Analiza Kodowanie Testowanie
6. Manifest Agile (Agile Manifesto)
Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym
zakresie odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych
doświadczeń zaczęliśmy przedkładać:
Ludzi i ich wzajemne interakcje (współdziałanie) ponad
procedury i narzędzia.
Działające oprogramowanie nad wyczerpującą dokumentację.
Współpracę z klientem nad negocjację umów.
Reagowanie na zmiany nad realizowanie planu.
Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie,
to jednak bardziej cenimy to co wymieniono po lewej.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
2014-11-24 6
7. Proces Agile (na podstawie SCRUM)
Zespół
— ScrumMaster
— zespół SCRUM
— Właściciel produktu
— Użytkownicy
Iteracja – Sprint
Backlog
— Produkt
— Sprint
Spotkania
— Daily scrum
— Planning
— Review
— Retrospective
Burndown
— Chart
— Velovity
2014-11-24 7
9. Zespół
ScrumMaster
— Project manager, nie w sensie zarządzania i kontroli
— kontroluje proces i jest kierownikiem zespołu
— jest odpowiedzialny za usuwanie przeszkód
Zespół Scrum
— członkowie są odpowiedzialne za wyniki sprintu
— mix umiejętności
— zazwyczaj 6-8 osób
Właściciel produktu
— odpowiada za produkt i jego dochodowość
— tworzy i wybiera listę funkcjonalności i priorytety dla każdej iteracji
— akceptuje lub odrzuca wyniki prac
Użytkownicy
— zainteresowaniu wynikami ale nie ponoszą odpowiedzialności za produkt
finalny
2014-11-24 9
10. Iteracja - Sprint
Wysiłek w ściśle określonym czasie (niezmienna dlugość)
— najczęsciej 2 tygodnie
— może być dłuższy lub krótszy
Zdefiniowany zakres prac
— brak zmian w po rozpoczęciu iteracji
— jeśli zmiany zostaną wprowadzone, następuje restart iteracji
— pełny cykl zadań deweloperskich (analiza, design, kodowanie,
testowanie, integracja)
Planowanie poprzedza iterację
Demonstracja wyników kończy iterację
2014-11-24 10
11. Backlog produktu
kompletna funkcjonalność końcowego produktu w formie User
Stories
może być pogrupowana na wydania
priorytyzacja wykonana przez Właściciela Produktu
estymacja wykonana przez Zespół Scrum
jest definiowany przed iteracjami
jest uaktualniany w trakcie postępów projektu
musi być zaalokowany czas w trakcie iteracji na wykonanie prac
porządkowych w backlog
2014-11-24 11
12. User stories
Opisują zamknięty kawałek funkcjonalność
Muszą posiadać wartość dla klienta
Muszą mieścić się w iteracji
Nie skupiają się na aspektach technologicznych projektu
Są demonstrowalne
Są szacowane w bezjednostkowych punktach
Wymagają implementacji we wszystkich warstwach systemu
2014-11-24 12
13. Backlog iteracji
funkcjonalność dla danej iteracji
może zawierać wymagania techniczne lub cele
— database design
— UI standards
— architecture documentation
2014-11-24 13
14. Spotkania
Sprint planning
— określenie celu sprintu i funkcjonalności
— identyfikacja zadań
Daily Scrum
Sprint Review
Sprint Retrospective
Spotkania są ograniczone w czasie i odbywają się regularnie
2014-11-24 14
15. Sprint Planning
Uczestniczy Właściciel produktu i Zespół Scrum
Przegląd backlogu produktu
Właściciel produktu dostarcza definicję i szczegóły
funkcjonalności
Negocjacje zawartości backlogu iteracji
Właściciel decyduje co będzie realizowane w danej iteracji
Identyfikacja nowych wymagań produktu
Planujemy tylko tyle, ile jesteśmy w stanie zrobić w iteracji
2014-11-24 15
16. Definicja tasków
Zaraz po Sprint Planning
Podział funkcjonalności na zadania
— 4-16 godzin na jedno zadanie
— identyfikacja zależności
definicja backlogu iteracji
zadania otrzymują priorytety nadane przez zespół
2014-11-24 16
17. Daily Scrum
na stojąco – 15 minut
każdy czlonek zespołu odpowiada na 3 pytania:
— co zrobiłeś
— co będziesz robił
— jakie masz problemy przy realizacji swoich zadań
spotkanie jest dla członkow zespołu
— nie jest to „raport prac” dla ScrumMastera
2014-11-24 17
18. Sprint Review
Wyniki iteracji są prezentowane Właścicielowi produktu
Właściciel akceptuje lub odrzuca wyniki
Wyniki spotkania sa danymi do:
— następnego spotkania Sprint Planning
— Sprint Retrospective
2014-11-24 18
19. Sprint Retrospective
W ramach zespołu Scrum
— może w nich uczestniczyć Właściciel produktu
Przegląd działania procesu i jego modyfikacje
Lessons learned są aplikowane w kolejnych iteracjach
2014-11-24 19
20. Estymacja
Zadanie tylko Zespołu Scrum
Planning Poker
— dyskusja nad podanymi wartościami i ponowna estymacja aż wszyscy wspólnie
się zgodzą
wyrażana w relatywnych jednostkach trudności wykonania danego user
story
— należy uwzględniać:
skomplikowanie
pracochłonność
niepewność
— ograniczony zbiór możliwych wartości:
np.: bazujący na ciągu Fibonacciego
— 0, 1, 2, 3, 5, 8, 13, 21
2014-11-24 20
21. Burndown chart
charakterysytka postępu prac w czasie
2014-11-24 21
22. Velocity
ilość zrealizowanych punktow User Stories
obrazuje prędkość pojawiania się funkcjonalności w projekcie
porównując Velocity do całkowitej liczby estymowanej pracy dla
backlogu produktu możemy estymowac faktyczną datę ukońćzenia
projektu
określenie Velocity Zespołu Scrum wymaga kilku iteracji
BORG Velocity: 16
2014-11-24 22
23. Praktyki Agile
Stanowią narzędzia w rękach zespołu
Wspierają podstawowe zasady wyrażone w manifeście
Obejmują wszystkie aspekty związane z tworzonym oprogramowaniem
Tworzenie kodu, organizacja projektu, zarządzanie, testowanie
Są od siebie zależne wspierając się nawzajem
Wyznaczają dyscyplinę i organizują prace w projekcie
2014-11-24 23
24. Praktyki Agile
Kodowanie
— Standardy kodowania
— Test driven development
— Continious integration
— Wspólny kod
— Pair programming
— Zespół nie pracuje overtime
Design
— don’t reinvent the wheel
— KISS
— DRY
— YAGNI
— Refactoring
Testowanie
— Unit testy
— Analiza jakości kodu
— Testy integracyjne
— Testy akceptacyjne
— Automatyzacja testów
2014-11-24 24
25. Standardy kodowania
koduj tak by inni członkowie zespołu musieli używać opcji Blame w SVN
by dowiedzieć się kto kodował
umożliwia prostsze zarządzanie kodem przez zespół
— np.: refaktoring
odpowiednie nazewnictwo funkcji (dokumentacja)
wykorzystywanie narzędzi (ReSharper, FxCop, StyleCop)
2014-11-24 25
26. Test Driven Development - TDD
Najpierw implementujemy testy, potem klasy
Testy definiują zakres implementacji oraz funkcjonalność klas i
komponentów
Testy wspomagają simple design
Testy stanowią dokumentacje użycia klas i komponentów
Tworzone klasy i komponenty są łatwiejsze w użyciu
2014-11-24 26
27. Continious Integration
Cały zespół pracuje na wspólnym kodzie
Projekt posiada automatyczny proces budowania aplikacji
Build integracyjny kompiluje projekt i uruchamia wszystkie testy
jednostkowe i sprawdza jakość kodu
Build integracyjny uruchamiany jest po oddaniu każdej zmiany
Status buildu jest komunikowany natychmiast wszystkim członkom
zespołu (CCNet Tray)
Zmiany muszą być oddawane często
— nie trzymamy zmian w kodzie
2014-11-24 27
28. Testy jednostkowe
Testy są częścią developmentu i tworzone są przez developerów
Wszystkie testy powstają przed implementacją
Testy umożliwiają refactoring
Każda metoda publiczna klasy powinna posiadać test
Testy jednostkowe powinny pokrywać jak największą ilość kodu pokrycie
testami powinno być automatycznie mierzone
Aplikacja nie może być „zreleasowana” jeżeli któreś z klas nie posiadają
testów
Testy jednostkowe strzegą zaimplementowanej funkcjonalności przed
przypadkowym uszkodzeniem podczas przyszłej implementacji
Testy jednostkowe powinny dotyczyć tylko zaimplementowanej w danej
klasie (jednostce) funkcjonalności (użycie mokowania)
2014-11-24 28
29. Analiza jakości kodu
Wysoka jakość kodu jest jednym z priorytetów Agile Development
Sprawdzanie jakości powinno być częścią continious integration
Narzędzia wspomagające analizę jakości
— FxCop (statyczna analiza kodu)
— Gandarme (statyczna analiza kodu, wykrywanie duplikatów)
— NDepend (analiza zależności i złożoności)
— NCover (analiza pokrycia kodu)
— StyleCop (analiza pod kątem stylu kodowania)
2014-11-24 29
30. Simple design
Nie robimy dokładnego up front design
Zawsze stosuj simple design principles
High cohesion, Low copuling, Single responisbility
Prosty kod łatwiej zmienić
Prosty kod łatwiej zrozumieć
Prosty kod łatwiej utrzymywać
Implementacja designu, który jest prosty zajmuje mniej czasu
Pamiętaj o tym, że ktoś będzie używał twojego kodu
2014-11-24 30
31. Simple design
Unikaj zbędnej komplikacji i overdesignu
DRY – Don’t Repeat Yourself
KISS – Keep It Simple and Small (… lub Stupid)
YAGNI – You are not going to need it
2014-11-24 31
32. Dlaczego Agile?
Zapewnia większą jakość dostarczanego softwaru
Dzięki wczesnej demonstracji funkcjonalności produktu i regularnemu
feedbackowi klienta produkt nie rozmija się z oczekiwaniami
What you get is what you see - klient wie i widzi, co system oferuje
użytkownikom
Gotowość na wdrożenie
Pozwala reagować na zmiany w trakcie realizacji projektu
Pozwala klientowi na bieżąco kształtować produkt
Możliwość śledzenia postępów przez Właściciela projektu
2014-11-24 32
34. Dlaczego Agile?
Dzięki simple design i obecności testów łatwo jest wprowadzać zmiany
Maintanance systemu jest tańszy w porównaniu z dotychczasowym
podejściem
2014-11-24 34
35. Dlaczego Agile?
Pozwala na bieżąco zarządzać release planem dzięki czemu klient ma
większe elastyczność budżetowania projektu (MMF)
2014-11-24 35
36. Dlaczego Agile?
Od pierwszej iteracji system jest gotowy do wdrożenia dzięki continious
integration
Unit testy zwiększają zaufanie do działania systemu
Działające oprogramowanie motywuje zespół
widzimy organiczny wzrost oprogramowania
Samodzielność zespołu owocuje większym zaangażowaniem
2014-11-24 36
37. Agile w praktyce
repozytorium SVN http://svn.wolterskluwer.pl
— każdy ma dostęp do prawie całego drzewa kodu
Continious Integration – Cruise Control .Net
— http://ci.wkpolska.pl
Pwp.WebACS – CI, TDD
Lex@Text – pierwszy w pełni agile
Strigi – QA Services
BORG
2014-11-24 37
