Agile Development
Transkrypt
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