Agile Development

Agile Development
Marcin Kucięba
[email protected]
Agile Development
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Dotychczasowe podejście
Konieczność zmian
Agile Manifest
Praktyki Agile
Dlaczego Agile?
Agile resources & books
2
Software development dotychczas
ƒ Waterfall – tradycyjne podejście w procesie
wytwarzania oprogramowania
Analiza
Design
Development
Testowanie
Instalacja
Sekwencyjność - brak możliwości zmiany
wcześniejszych decyzji !
3
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 możliwości reagowania na zmiany
ƒ Niska jakość dostarczanego oprogramowania
4
Początki zmian
•
•
•
•
•
•
•
Extreme Programming
SCRUM
DSDM
Adaptive Software Development
Crystal
Feature-Driven Development
Pragmatic Programming
5
Manifest Agile
11 Lutego 2001 w Wasatach w stanie Utah 17 ludzi spotkało
się aby określić wspólny mianownik nowych „procesów”
związanych z wytwarzaniem oprogramowania oraz stworzyć
podstawowe, wspólne dla tych „procesów” zasady software
developmentu
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
6
Manifest Agile
ƒ Interactions with individuals over processes and tools.
ƒ Creating working software over comprehensive
documentation.
ƒ Customer collaboration over contract negotiation.
ƒ Responding to change over following a plan
7
Praktyki Agile
ƒ Planowanie
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Iteracje
User stories
Obecność klienta
Planowanie iteracji
Prezentacja aplikacji
Project velocity
Release planning
ƒ Design
ƒ Simple design
ƒ YAGNI
ƒ Refactoring
ƒ Kodowanie
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Standardy kodowania
Test driven development
Continious integration
Wspólny kod
Pair programming
Zespół nie pracuje overtime
ƒ Testowanie
ƒ
ƒ
ƒ
ƒ
ƒ
Unit testy
Analiza jakości kodu
Testy integracyjne
Testy akceptacyjne
Automatyzacja testów
8
Iteracja n
Iteracja 12
Iteracja 11
Iteracja 10
Iteracja 9
Iteracja 8
Iteracja 7
Iteracja 6
Iteracja 5
Iteracja 4
Iteracja 3
Iteracja 2
Iteracja 1
Iteracja 0
Iteracje
{
{
{
{
{
{
{
{
{
{
{
{
{
{
IP
I
T
C
D
A
I
T
C
D
A
IP – Initial Planning
A – Analiza
D – Design
C - Kodowanie
T– Testowanie
I– Integracja
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
I
T
C
D
A
ƒ Zawsze niezmienna długość
ƒ Pełny cykl zadań developerskich w
każdej iteracji
9
Planowanie iteracji
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Zawsze na początku każdej iteracji
Klient decyduje co będzie realizowane w danej iteracji
Aktywny udział wszystkich członków zespołu
Estymacja –zadanie wyłączne developerów
Podział zaplanowanych user stories na zasadach sign up
Planujemy tylko tyle, ile jesteśmy w stanie zrobić w iteracji
10
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
11
Prezentacja aplikacji
ƒ Każdy z developerów prezentuje zaimplementowane user
stories
ƒ Wspólna ocena wykonania user stories
ƒ Regularny feedback
ƒ Możliwość śledzenia postępu prac przez klienta
12
Project velocity
Project Burndown
ƒ Backlog – zbiór user stories do
wykonania
ƒ Tracking - analiza postępu prac
ƒ Velocity – średnia ilość
zrealizowanych punktów
ƒ Burndow chart – charakterystyka
postępu prac w czasie
ƒ Metryki – narzędzie umożliwiające
predykcje
Trend Gap Last Iteration
Total Deliverable Work:
Gap %:
% of Iterations Remaining:
Trend Units of Work per Iteration:
Needed Units or Work per Iteration:
Per Iteration Variance:
Iteration Variance
Iteration Variance %
7000
6000
5000
Scheduled
4000
Actual
Trend
3000
Planned
2000
1000
0
I1
E1
E2
E3
C1
C2
C3
C4
C5
C6
C7
C8
C9 C10 C11
Iteration
2309
6184
37%
27%
279
741
166%
9
60%
Actual
Trend
Schedule
Trend Gap
Iteration Variance
13
Release planning
ƒ Etapowe wdrażanie systemu
ƒ Minimalizacja ryzyka związanego z uruchomieniem systemu
ƒ Zwiększone szanse na sukces poprzez zarządzanie
czynnikiem time to market
ƒ What you get is what you see - klient wie i widzi, co system
oferuje użytkownikom
ƒ Klient decyduje co i kiedy oddać użytkownikom
14
Simple design
ƒ Nie robimy dokładnego up front design
ƒ Zawsze stosuj simple design principles
High cohesion, Low copuling, Single responisbility, Open/Close, Liskov’s
Substitution
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Proste 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
Unikaj zbędnej komplikacji i overdesignu
YAGNI – You are not going to need this
15
Test Driven Development
ƒ 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
16
Continious Integration
ƒ Cały zespół pracuje na wspólnym kodzie
ƒ Projekt posiada automatyczny proces
budowania aplikacji
ant, maven
ƒ Build integracyjny kompiluje projekt i
uruchamia wszystkie testy unitowe i
sprawdza jakość kodu
ƒ Build integracyjny uruchamiany jest po
oddaniu każdej zmiany
ƒ Status buildu jest komunikowany
natychmiast wszystkim członkom
zespołu
ƒ Zmiany muszą być oddawane często
17
Unit testy
ƒ Unit 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
ƒ Unit testy powinny pokrywać jak największą ilość kodu –
pokrycie testami powinno być mierzone
ƒ Aplikacja nie może być „zreleasowana” jeżeli któreś z klas
nie posiadają testów
ƒ Unit testy strzegą zaimplementowanej funkcjonalności przed
przypadkowym uszkodzeniem podczas przyszłej
implementacji
18
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
ƒ Checkstyle (standardy kodowania)
ƒ Cobertura (code coverage)
ƒ PMD (statyczna analiza kodu)
ƒ JDepend (analiza zależności)
19
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
20
Dlaczego Agile?
ƒ
ƒ
ƒ
ƒ
Zapewnia większą jakość dostarczanego softwaru
Dzięki feedbackowi klienta produkt nie rozmija się z oczekiwaniami
Pozwala reagować na zmiany w trakcie realizacji projektu
Pozwala klientowi na bieżąco kształtować produkt
Realizacja oczekiwań klienta
Waterfall
Agile
Oczekiwania klienta
21
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
Koszt zmian
Waterfall
Agile
22
Dlaczego Agile?
ƒ Pozwala na bieżąco zarządzać release planem dzięki
czemu klient ma większe elastyczność budżetowania
projektu
R2
R1
120
100
80
60
40
20
1
2
3
4
5
6
7
FR
8 10 11 12 13 14 15 16 17
23
Dlaczego Agile?
ƒ Większa kontrola realizacji prac
ƒ Szacunek na podstawie
dotychczasowych doświadczeń
zamiast planowania przyszłej realizacji
ƒ Natychmiastowa szacunkowa
weryfikacji wstępnych estymacji
Project Burndown
I 4, Total 17
6000
5000
4000
Sheduled
Actual
3000
Trend
Planned
2000
1000
0
Project Burndown
I1
I 11, Total 23
E1
E2
E3
C1
C2
C3
C4
C5
C6
C7
Iteration
7000
6000
Project Burndown
I 16, Total 19
5000
Scheduled
4000
6000
Actual
Trend
3000
5000
Planned
2000
4000
1000
3000
Scheduled
Actual
Trend
Planned
0
I1
E1
E2
E3
C1
C2
C3
C4
C5
C6
C7
C8
C9 C10 C11
2000
Iteration
1000
0
I1
E1
E2
E3
C1
C2
C3
C4
C5
C6
C7
C8
C9 C10 C11
Iteration
24
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ół
ƒ Samodzielność zespołu owocuje większym zaangażowaniem
25
Agile resources
ƒ
Agile Development
http://www.agilemanifesto.org/
http://www.agilealliance.org/
ƒ
Extreme Programming
http://www.xprogramming.com/
http://www.extremeprogramming.org/
http://www.jera.com/techinfo/xpfaq.html
26
Agile books
Agile Software Development,
Principles, Patterns, and
Practices Rober C. Martin
A Practical Guide to eXtreme
Programming
Applying UML and Patterns
Test Driven Development: By
Example
Craig Lerman
David Astels, Granville Miller, Miroslav Novak
Kent Beck
Agile and Iterative Development:
A Manager's Guide
Refactoring: Improving the
Design of Existing Code
Craig Lerman
Martin Fowler, Kent Beck, John Brant, William Opdyke
Extreme Programming
Explained: Embrace Change
Kent Beck, Cynthia Andres
27