Prezentacja przedstawia pomysł Scotta Amblera na prowadzenie analizy w metodach zwinnych: Agile Modeling oraz Agile Model Driven Development. Prezentacja została przedstawiona na spotkaniu IIBA PC Business Analysis Round-tables #7 Pomysł na analizę w Agile: Agile Modeling: http://www.meetup.com/IIBA-PC-Business-Analysis-Round-tables/events/222647759/

1. Pomysł na analizę w Agile:
Agile Modeling
Paweł Jarosiński
2015-06-10

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

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

4. O czym będzie?
• Agile Modeling
– Wartości
– Zasady
• Agile Model Driven Development
– Metoda
– Dobre praktyki
• Wdrażanie Agile Modeling
• Dyskusja

5. 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

6. Agile Modeling
• Zastosowanie:
– zbieranie wymagań i ich analiza,
– modelowanie architektury,
– projektowanie

7. 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

8. 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

9. Wartości Agile Modeling
• Komunikacja
• Prostota
• Informacja zwrotna
• Odwaga
• Pokora

10. 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

11. 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

12. Jak zastosować zasady
Agile Modeling?
• Wdrożyć je w obecnej metodologii
• Wykorzystać metodologię Agile Model Driven
Development

13. Agile Model Driven Development
• Wersja zwinna Model Driven Development
• MDD – tworzenie oprogramowania poprzedzone
modelowaniem (m.in. UML)

14. AMDD – cykl życia

15. 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)

16. 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

17. 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

18. 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

19. 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

20. AMDD – iteracja n
• Modelowanie iteracji
• Dyskusja nad modelem
(burza mózgów)
• Test Driven Development
• Opcjonalnie:
Przegląd (review)

21. AMDD – modelowanie iteracji
• Cel:
– Przemyślenie, co zostanie
zrobione w iteracji
• Analiza i projekt realizacji
wymagań dla iteracji
• Plan prac i ich oszacowanie

22. 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

23. 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

24. 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

25. 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)

26. 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)

27. 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

28. 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

29. 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

30. 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

31. Podsumowanie
• Agile Modeling
– Stosujmy od zaraz 
• Agile Model Driven Development
– Jedna z możliwych technik
– Dobre praktyki
do wykorzystania wszędzie

32. Podsumowanie
• Dalsze materiały:
– Agile Modeling
http://www.agilemodeling.com
– DAD, Disciplined Agile Delivery
http://www.disciplinedagiledelivery.com

33. Dyskusja

34. Dziękuję za uwagę
pawel.jarosinski@pentacomp.pl
Pentacomp Systemy Informatyczne S.A.
www.pentacomp.pl