Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku Agenda Metafory o Zwinności i Sztywności Teza: Oszukujemy się co do sukcesów projektów Agile Objawy chaosu w projektach Agile Klasyczna rola i wymagań Przykład umiejscowienia w metodzie DAD Architektura oprogramowania w Agile - przeniesienie dobrych stron podejścia architekturo-centrycznego do metodyk zwinnych 2 1
Architektura i Wymagania Agile Stereotypy Usztywnienie zakresu, Odgórne planowanie, Samotność, Reaktywność Stereotypy Zero-dokumentacji, Brak synergii z innymi projektami, Problem OPEXu 3 4 2
5 Objawy chaosu w projektach Agile Kilka przykładów i cytatów Inicjowanie projektu Realizacja projektu Eksploatacja produktów i ich dalsze zmiany Wizja produktu vs. rzeczywisty zakres Co jest podstawą do utworzenia Planu Sprintów? Co tak właściwie robimy? Czy pamiętaliśmy o pracach biznesowych? (np. marketing) Pytanie nowego dyrektora: Jaki jest zakres tego projektu? Jakie procesy biznesowe wspiera? Członek zespołu do Właściciela produktu: Czy możesz w tym user story napisać jakieś konkretne wymagania, żeby znowu nie trzeba było wywracać do góry nogami kodu tej funkcjonalności? Kierownik obszaru aplikacyjnego: Gdzie jest dokumentacja modelu danych? Dlaczego nie skorzystano z istniejącego komponentu? Architekt: po tych projektach Agile robi się niezłe spaghetti (rośnie nam dług techniczny) 6 3
Klasyczna rola i wymagań Architektura oprogramowania Przekształcenie wymagań (co system ma robić?) na wysokopoziomowy projekt systemu (kto i jak ma to robić?) Wypracowanie docelowej systemu Zaadaptowanie projektu do zewnętrznego środowiska oraz oczekiwań wydajnościowych 7 Klasyczna rola i wymagań Przykładowy zakres opisu Sposób reprezentacji Cele i ograniczenia Widok przypadków użycia Widok logiczny Widok procesów Widok wdrożenia Widok implementacji Realizacja wymagań pozafunkcjonalnych Komponent Wymagania Proces Infrastruktura Dane Dane Architektura oprogramowania, wybrane korzyści: Zarządzanie iteracjami z wykorzystaniem przypadków użycia Zarządzanie dostawami poprzez identyfikację głównych komponentów oprogramowania Zarządzanie zależnościami wewnętrznymi i zewnętrznymi Zabezpieczenie spełnienia wymagań pozafunkcjonalnych 8 4
Klasyczna rola i wymagań Cechy Tworzona we wstępnej fazie projektu Odpowiedzialna za zdefiniowanie zakresu prac Narzucająca standardy, zasady czy ograniczenia Przykładowy opis 1. Sposób reprezentacji 2. Cele i ograniczenia 3. Widok przypadków użycia 4. Widok logiczny 5. Widok procesów 6. Widok wdrożenia 7. Widok implementacji 8. Realizacja wymagań pozafunkcjonalnych Zawiera zdefiniowanie widoki np. logiczny, fizyczny, przypadków użycia, danych Formalnie udokumentowana i stanowiąca podstawę dla projektów szczegółowych 9 Przykład Disciplined Agile Delivery i kwestii Wejście z portfela projektów Wizja inicjalnej Wejście z Architektury korporacyjnej Architektura Źródło: http://disciplinedagiledelivery.wordpress.com 10 5
Architektura oprogramowania w Agile Pełni rolę wspierającą zespół Cechy Adaptacyjna bądź wyłaniająca się Zasada 11 Agile Manifesto : Najlepsze, wymagania i projekty powstają w samoorganizujących się zespołach Pełni rolę komunikacyjną Nie spowalnia projektu Jest testowalna Decyzje podejmujemy możliwie późno, a zaczynamy od rozwiązań możliwie prostych 11 Architekt oprogramowania w Agile 1 Backlog Backlog Dążenia architekta Komunikacja Wzorce projektowe Główne wymagania Zasadnicze wytyczne konstrukcyjne 2 3 Sprint 0 Inicjalna architektura Planowanie Sprintu Spike (PoC), Scenariusze testowe, aktualizacja Właściciel produktu Zespół Wytyczne EA/PFM 4 Przegląd Przegląd architektoniczny (m.in. kod, biblioteki, testy) 12 6
Klasyczna rola architektura i wymagań wady i zalety Klasyka Sposób reprezentacji Cele i ograniczenia Widok przypadków użycia Widok logiczny Widok procesów Widok wdrożenia Widok implementacji Realizacja wymagań pozafunkcjonalnych Zwinność Sposób reprezentacji Cele i ograniczenia Widok biznesu (szkic) Widok aplikacji i danych (szkic) Widok infrastruktury technicznej (szkic) Wzorce architektoniczne / standardy Realizacja głównych wymagań (wyłonionych z User Story ) Lista zasad konstrukcyjnych 13 Dziękuję Krzysztof Gwardys krzysztof.gwardys@promity.pl +48 510 002 568 14 7