Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pomysł na analizę w Agile: Agile Modeling

971 views

Published on

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/

Published in: Software
  • Be the first to comment

Pomysł na analizę w Agile: Agile Modeling

  1. 1. Pomysł na analizę w Agile: Agile Modeling Paweł Jarosiński 2015-06-10
  2. 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. 3. Agile Modeling? • Czy Agile Modeling może tu pomóc?
  4. 4. O czym będzie? • Agile Modeling – Wartości – Zasady • Agile Model Driven Development – Metoda – Dobre praktyki • Wdrażanie Agile Modeling • Dyskusja
  5. 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. 6. Agile Modeling • Zastosowanie: – zbieranie wymagań i ich analiza, – modelowanie architektury, – projektowanie
  7. 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. 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. 9. Wartości Agile Modeling • Komunikacja • Prostota • Informacja zwrotna • Odwaga • Pokora
  10. 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. 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. 12. Jak zastosować zasady Agile Modeling? • Wdrożyć je w obecnej metodologii • Wykorzystać metodologię Agile Model Driven Development
  13. 13. Agile Model Driven Development • Wersja zwinna Model Driven Development • MDD – tworzenie oprogramowania poprzedzone modelowaniem (m.in. UML)
  14. 14. AMDD – cykl życia
  15. 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. 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. 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. 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. 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. 20. AMDD – iteracja n • Modelowanie iteracji • Dyskusja nad modelem (burza mózgów) • Test Driven Development • Opcjonalnie: Przegląd (review)
  21. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Podsumowanie • Agile Modeling – Stosujmy od zaraz  • Agile Model Driven Development – Jedna z możliwych technik – Dobre praktyki do wykorzystania wszędzie
  32. 32. Podsumowanie • Dalsze materiały: – Agile Modeling http://www.agilemodeling.com – DAD, Disciplined Agile Delivery http://www.disciplinedagiledelivery.com
  33. 33. Dyskusja
  34. 34. Dziękuję za uwagę pawel.jarosinski@pentacomp.pl Pentacomp Systemy Informatyczne S.A. www.pentacomp.pl

×