pomysł na analizę w agile: agile modeling
Post on 18-Aug-2015
448 Views
Preview:
TRANSCRIPT
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
top related