Agile nie zakazuje diagramów ani dokumentacji#
UML może wspierać zwinny projekt, jeśli diagram pomaga zespołowi podjąć decyzję, zrozumieć ryzyko lub uzgodnić wymaganie. Podejście Agile nie wymaga tworzenia kompletnego modelu z góry ani nie oznacza rezygnacji z dokumentacji. Ceni działające rozwiązania i współpracę, a artefakty powinny służyć pracy oraz być utrzymywane proporcjonalnie do wartości.
Modeluj wtedy, gdy potrzebujesz wspólnego zrozumienia, i przestań, gdy kolejny detal nie pomaga. Szkic na tablicy, diagram tekstowy w repozytorium i formalny model w narzędziu mogą być właściwe w różnych sytuacjach.
Modelowanie na czas#
Modelowanie na żądanie (just-in-time) oznacza tworzenie diagramu wtedy, gdy zespół napotyka niepewność lub decyzję. Przed implementacją można szybko uzgodnić granice komponentów; podczas pracy — rozrysować trudny scenariusz integracji; przy testowaniu — przejść maszynę stanów i znaleźć brakujące przejścia.
Nie czekaj na idealny komplet wymagań, jeśli model może pomóc je odkryć. Jednocześnie nie zapisuj hipotezy jako zatwierdzonego kontraktu. Oznacz założenia, właściciela decyzji oraz kryterium, po którym wrócisz do tematu.
Wystarczający, nie przypadkowy model#
Model „wystarczający do celu” (just barely good enough) zawiera informacje potrzebne do aktualnej decyzji i nic ponad to. Nie oznacza modelu niedbałego ani niepełnego w ważnych miejscach. Jeśli szczegół wpływa na bezpieczeństwo, interoperacyjność, cykl życia lub wymaganie, uwzględnij go albo opisz gdzie indziej.
Zbyt mały model może pozostawić krytyczną niejasność; zbyt duży spowalnia zmianę i szybko się dezaktualizuje. Ustal odbiorców, zakres, poziom abstrakcji i następny krok. Możesz dodać szczegóły później, gdy staną się potrzebne.
UML w iteracjach#
Na początku inicjatywy zespół może stworzyć przeglądowy model zakresu i architektury. W planowaniu iteracji może rozrysować ryzykowną funkcję, a podczas implementacji — aktualizować wybrany widok po zmianie kontraktu. Retrospektywa może ujawnić, że model nie pomagał lub nikt nie wiedział, gdzie go utrzymywać.
Nie wymagaj, by każda historia użytkownika miała diagram. Wprowadź UML wtedy, gdy tekst, kod lub wspólna rozmowa nie wystarczają do uzgodnienia relacji i zachowania. Zapisz trwałe decyzje w miejscu, które zespół będzie odnajdywać i aktualizować.
Kiedy diagram jest przydatny#
- Gdy zmiana dotyczy wielu komponentów lub zespołów i granice są sporne.
- Gdy przebieg ma istotne błędy, warunki, równoległość lub komunikację asynchroniczną.
- Gdy zespół musi uzgodnić cykl życia obiektu albo ograniczenia relacji danych.
- Gdy zmiana infrastruktury wpływa na wdrożenie, dostępność lub bezpieczeństwo.
- Gdy nowi członkowie potrzebują przeglądu modelu systemu.
- Gdy diagram pomaga wyprowadzić kryteria akceptacji lub testy ryzyka.
Jeśli prosty komentarz w kodzie, kontrakt API, test akceptacyjny lub prototyp lepiej pokazuje intencję, nie dodawaj UML na siłę. Wybór formy jest częścią projektowania informacji.
Utrzymywanie modeli w zespole#
Modele tekstowe można wersjonować razem z kodem, dzięki czemu zmiany przechodzą przegląd i pozostają obok implementacji. Diagramy wizualne mogą być w repozytorium lub wspólnym modelerze. Ważne, by zachować edytowalne źródło, nie tylko eksportowany obraz, i określić, kto aktualizuje widok.
Ustal źródło prawdy: kod, diagram, kontrakt czy wymaganie. Generowanie z kodu może pomóc przy widokach szczegółowych, ale nie odtworzy intencji architektonicznej. Renderowanie diagramu nie potwierdza jego aktualności ani poprawności.
Agile a dokumentacja długowieczna#
Niektóre modele wspierają chwilową rozmowę i mogą zostać usunięte po spotkaniu, gdy wynik został zapisany gdzie indziej. Inne opisują krytyczne kontrakty, integracje, regulacje lub operacje i powinny przetrwać iteracje. O trwałości decyduje wartość dla przyszłego odbiorcy, nie fakt, że dokument powstał w procesie Agile.
W systemach regulowanych, rozproszonych lub długo utrzymywanych trzeba uwzględnić wymagania dowodowe, zgodność, przekazanie wiedzy i utrzymanie. Lekkość procesu oznacza usuwanie bezwartościowych artefaktów, a nie pomijanie informacji wymaganych przez ryzyko lub prawo.
Typowe błędy#
- Agile utożsamione z brakiem dokumentacji. Zachowuj materiały ważne dla odbiorców i utrzymania.
- Modelowanie wszystkiego przed pierwszą iteracją. Twórz widoki w odpowiednim momencie.
- „Wystarczający” użyty jako usprawiedliwienie pominięcia ryzyka. Szczegóły krytyczne muszą być jawne.
- Każda historia obudowana diagramami. Modeluj tam, gdzie rozwiązuje problem komunikacyjny.
- Szkic mylony z zatwierdzonym modelem. Oznacz status, zakres i założenia.
- Automatyczne generowanie bez odpowiedzialności. Wybierz właściciela i źródło prawdy.
- Wszystkie diagramy uznane za długowieczne. Zdecyduj, które warto utrzymywać, a które archiwizować.
Podsumowanie#
UML dobrze współgra z Agile, gdy zespół tworzy modele w odpowiednim momencie, w zakresie wystarczającym do decyzji i z jasną odpowiedzialnością za aktualizację. Zachowuj diagramy, które wspierają kontrakty, ryzyko i przekazywanie wiedzy; nie wymagaj ich dla każdej zmiany.