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/
Jak wykorzystać Scrum i metodyki Agile do projektowania dużych systemów SaaS?
Pomysł na analizę w Agile: Agile Modeling
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ć?
• … ?
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
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
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)
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
Kluczowe w modelowaniu jest:
- Efektywna komunikacja pomiędzy analitykami i interesariuszami oraz między analitykami i deweloperami
Dążenie do wytworzenia najprostszego rozwiązania, które realizuje wszystkie potrzeby – w tym prostych modeli, dokumentów
Otrzymywanie informacji zwrotnej (zarówno od interesariuszy jak i deweloperów) często i szybko, (Kent Beck, XP: Optymizm to ryzyko zawodowe programowania, informacja zwrotna jest lekarstwem)
Odwaga w podejmowaniu decyzji i trzymaniu się ich
Pokora, żeby przyznać, że nie wiem wszystkiego i że inni też są wartościowi.