Ryszard Krakowiak

AgileDevelopment

15.04.2023 2

Agenda

Dotychczasowe podejście

Manifest Agile

Praktyki Agile na przykładzie SCRUM

Dlaczego Agile?

15.04.2023 3

Tworzenie oprogramowania dotychczas

Waterfall – tradycyjne podejście w procesie wytwarzania oprogramowania

Pełna sekwencyjność

bardzo utrudniona możliwość zmiany wcześniejszych decyzji

Analiza Design Development Testowanie Wdrożenie

15.04.2023 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

15.04.2023 5

Sama iteracyjność nie zapewnia Agile

Analiza Kodowanie

Testowanie

Analiza Kodowanie

Testowanie

Analiza Kodowanie

Testowanie

15.04.2023 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

15.04.2023 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

15.04.2023 8

Proces SCRUM

15.04.2023 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

15.04.2023 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ę

15.04.2023 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

15.04.2023 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

15.04.2023 13

Backlog iteracji

funkcjonalność dla danej iteracji

może zawierać wymagania techniczne lub cele—database design—UI standards—architecture documentation

15.04.2023 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

15.04.2023 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

15.04.2023 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ół

15.04.2023 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

15.04.2023 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

15.04.2023 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

15.04.2023 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

15.04.2023 21

Burndown chart

charakterysytka postępu prac w czasie

15.04.2023 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

15.04.2023 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 oprogramowaniemTworzenie kodu, organizacja projektu, zarządzanie, testowanie

Są od siebie zależne wspierając się nawzajem

Wyznaczają dyscyplinę i organizują prace w projekcie

15.04.2023 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

15.04.2023 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)

15.04.2023 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

15.04.2023 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

15.04.2023 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)

15.04.2023 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)

15.04.2023 30

Simple design

Nie robimy dokładnego up front design

Zawsze stosuj simple design principlesHigh 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

15.04.2023 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

15.04.2023 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

15.04.2023 33

Dlaczego Agile ?

Realizacja oczekiwań klienta

15.04.2023 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

15.04.2023 35

Dlaczego Agile?

Pozwala na bieżąco zarządzać release planem dzięki czemu klient ma większe elastyczność budżetowania projektu (MMF)

15.04.2023 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

15.04.2023 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