...

Pomysł na analizę w Agile: Agile Modeling

by pawel-jarosinski

on

Report

Category:

Software

Download: 0

Comment: 0

443

views

Comments

Description

Download Pomysł na analizę w Agile: Agile Modeling

Transcript

  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
Fly UP