Pomysł na analizę w Agile: Agile Modeling

Paweł Jarosiński2015-06-10

Analiza w Agile?

• Kiedy jest czas na analizę w Agile? • Jak dokładny powinien być wynik analizy?• Kto powinien prowadzić analizę?• Jakie modele utworzyć?• … ?

Agile Modeling?

• Czy Agile Modeling może tu pomóc?

O czym będzie?

• Agile Modeling– Wartości– Zasady

• Agile Model Driven Development– Metoda– Dobre praktyki

• Wdrażanie Agile Modeling• Dyskusja

Agile Modeling

• 2001/2002 Scott Ambler• Metodologia efektywnego modelowania i

dokumentowania systemów informatycznych• Kolekcja wartości, zasad i praktyk – nie jest

procesem typu „instrukcja działania”• Kluczem modelowania nie są same techniki

modelowania, ale sposób ich zastosowania

Agile Modeling

• Zastosowanie: – zbieranie wymagań i ich analiza, – modelowanie architektury, – projektowanie

Dlaczego Agile Modeling?• Obecnie:

– Nadmiar niepotrzebnej dokumentacji, której nikt nie czyta/wykorzystuje

– Często to strata czasu– Dokumentacja/modelowanie staje się celem samym w

sobie

Dlaczego Agile Modeling?

• Agile Modeling:– Tylko tyle dokumentacji, ile jest niezbędne– Tylko te modele, które są przydatne– Narzędzia, które są najmniej pracochłonne

Wartości Agile Modeling

• Komunikacja • Prostota• Informacja zwrotna• Odwaga• Pokora

Zasady Agile Modeling

• Modelowanie z nastawieniem na cel (Dlaczego? Po co? Dla kogo?)

• Maksymalizacja zwrotu z inwestycji• „Lekki bagaż”• Znajomość wielu modeli, wykorzystanie wybranych• Szybka informacja zwrotna• Prostota• Zmiany są naturalne

Zasady Agile Modeling

• Przyrostowe wprowadzanie zmian (w tym w modelach)

• Wysoka jakość modeli• Główny cel: działające oprogramowanie• Cel drugoplanowy: Kolejne zadania (Następny

release? Utrzymanie?)• Treść jest ważniejsza niż forma• Otwarta i uczciwa komunikacja

Jak zastosować zasady Agile Modeling?

• Wdrożyć je w obecnej metodologii• Wykorzystać metodologię Agile Model Driven

Development

Agile Model Driven Development

• Wersja zwinna Model Driven Development• MDD – tworzenie oprogramowania poprzedzone

modelowaniem (m.in. UML)

AMDD – cykl życia

AMDD – iteracja 0

• Cel: Określenie zakresu systemu i najlepszej jego architektury

• Celem nie jest:Szczegółowa specyfikacja -> duże ryzyko

• TO DO:• Wysokopoziomowy model wymagań• Wysokopoziomowy model architektoniczny

• Timebox:• Kilka godzin (projekty <= kilka tygodni) do 2 tygodni

(projekty >= rok)

AMDD – inicjalna wizja wymagań

• Cel: • Uzyskanie dobrego poczucia,

czego dotyczy projekt• Zidentyfikowanie wysokopoziomowych wymagań i

zakresu releasu (co system powinien robić w tym zakresie)• Celem nie jest:

Wytworzenie szczegółowej dokumentacji. Ważniejsze jest zbudowanie wspólnego rozumienia zakresu z klientem

AMDD – inicjalna wizja wymagań

• TO DO:• Model użycia systemu

przez użytkowników• Inicjalny model domenowy z podstawowymi encjami

biznesowymi• Inicjalny model interfejsu użytkownika i kwestie dotyczące

użyteczności• Krytyczne: użycie takich technik, które aktywnie angażują

interesariuszy

AMDD – inicjalna wizja architektury

• Cel: • Zaproponowanie architektury,

która ma duże szanse spełnienia wymagań• Określenie kierunku technicznego dla projektu• Skupienie zespołu na wybranym kierunku technicznym

• Celem nie jest:Wytworzenie szczegółowej architektury

AMDD – inicjalna wizja architektury

• TO DO:• Diagram pokazujący

infrastrukturę techniczną (w nieformalnej formie)• Inicjalny model domenowy z podstawowymi encjami

biznesowymi• Opcjonalnie: możliwe zmiany, które architektura będzie

być może będzie musiała w przyszłości uwzględnić• Krytyczne: Modele muszą być proste, doprecyzowane tylko na

tyle, by móc ruszyć z pracami. Zalecane jest modelowanie na tablicy

AMDD – iteracja n

• Modelowanie iteracji• Dyskusja nad modelem

(burza mózgów)• Test Driven Development• Opcjonalnie:

Przegląd (review)

AMDD – modelowanie iteracji

• Cel:– Przemyślenie, co zostanie

zrobione w iteracji

• Analiza i projekt realizacjiwymagań dla iteracji

• Plan prac i ich oszacowanie

AMDD – dyskusja nad modelem

• Cel:– Modelowanie wybranego

aspektu

• Mała grupa osób (2-3)• Krótki czas dyskusji (5-10,

maks. 30 min.)• Wspólne modelowanie na tablicy

i dyskusja kwestii spornych• Ad-hoc, bez przygotowania

AMDD – implementacja TDD

• Cel:– Implementacja wymagania

zgodnie z TDD

• Napisanie wykonywalnego testu

• Implementacja aż test zacznie przechodzić pozytywnie

• Częsty refactoring• Zajmuje największą część iteracji

AMDD – przegląd

• Cel:– Podsumowanie i sprawdzenie

wyników iteracji

• W małych projektach/zespołach raczej niepotrzebne

• Może być przydatne w dużych zespołach

• Najważniejsza jest informacja zwrotna uzyskana podczas przeglądu

AMDD – podsumowanie

• Mało modelowania na początku, dużo implementacji• Iterowanie: modelowanie <-> implementacja, z

częstym kontaktem z klientem• Przeplatanie się roli analityka i dewelopera• Specjaliści z wieloma umiejętnościami

(analiza/projektowanie/implementacja)

Najlepsze praktyki AMDD

• Aktywne uczestnictwo interesariuszy• Wizja architektury• Wizja wymagań• Ciągłe dokumentowanie• Późne dokumentowanie• Wykonywalne specyfikacje wymagań (np.

Specification by Example, Acceptance Test-Driven Development)

Najlepsze praktyki AMDD

• Modelowanie iteracji• Dokumentacja aktualna na czas tworzenia• Modelowanie „patrzące wprzód”• Dyskusja nad modelem • Wiele modeli, wykorzystanie wybranych• Priorytetyzacja wymagań• Pojedyncze źródło informacji• Test-Driven Development

Wdrażanie Agile Modeling

• Jako kierownik projektu:– Zaplanuj sesję inicjalnej wizji na początku projektu– Zorganizuj prace w krótkich iteracjach. W pierwszej

kolejności realizuj wymagania o najwyższym priorytecie– Nie planuj zbyt daleko – priorytety i wymagania będą się

zmieniać– Najlepsze oszacowanie prac zrobią te osoby, które będą je

realizować. Ale potrzebują trochę modelowania– Modelowania nie planujemy w harmonogramie. To jest

część iteracji

Wdrażanie Agile Modeling

• Jako analityk (1):– Wizja architektury i wymagań trwa dni, nie tygodnie/

miesiące. Celem jest zrozumienie zakresu, nie szczegółów– Szczegóły są analizowane i modelowane podczas iteracji

(m.in. dyskusja modelu)– Nie ma „fazy analizy wymagań” – jest analiza w iteracji– Wymagania się zmieniają – to jest OK. Priorytetyzuj je.– Zaangażuj interesariuszy do modelowania – użyj

odpowiednich technik

Wdrażanie Agile Modeling

• Jako analityk (2):– Użyj wybranych, pasujących modeli, odpowiednich do

projektu. Znaj wiele różnych technik modelowania– Celem jest rozumienie wymagań, nie ich dokumentowanie.

Jeśli dokumentujesz, zastanów się, czy to ma cel i do kogo jest skierowane

– Modeluj razem z deweloperami. Oni lepiej rozumieją wymagania, ty – co zostanie zbudowane

– Rozszerzaj swoje umiejętności, nie tylko typowo analityczne

Podsumowanie

• Agile Modeling– Stosujmy od zaraz

• Agile Model Driven Development– Jedna z możliwych technik– Dobre praktyki

do wykorzystania wszędzie

Podsumowanie

• Dalsze materiały:– Agile Modeling

http://www.agilemodeling.com– DAD, Disciplined Agile Delivery

http://www.disciplinedagiledelivery.com

Dyskusja

Dziękuję za uwagę

pawel.jarosinski@pentacomp.plPentacomp Systemy Informatyczne S.A.

www.pentacomp.pl