Każdemu zalecam stosowanie przypadków użycia ? także a może przede wszystkim w projektach Agile.
Poniżej zamieszczam trzy podstawowe zalety, które myślę, że przekonają do używania przypadków użycia w projektach Agile
1. Dzięki przypadkom użycia zyskuje się kontekst
Nawet w projektach Agile przypadki użycia są mechanizmem umożliwiającym firmom osiąganie celów. Podejście, które wykorzystuje ustrukturyzowane wymagania dostarcza ten kontekst. Innymi słowy przypadki użycia pozwalają określić z jakimi systemami lub innymi zasobami będzie współpracował nasz system.
2. Dzięki przypadkom użycia zyskuje się informacje dot. zakresu projektu
Z politycznego punktu widzenia największym problemem z uruchomieniem projektu Agile w organizacjach typu waterfall jest niewłaściwe ustalenie oczekiwań wobec projektu w zakresie jego trwania i kosztów. Ustalenie oczekiwań i w ten sposób zabezpieczenie zarówno finansowania jak i wsparcia dla projektu może być ważniejsze niż samo wykonanie.
Ustalanie zakresu polega przede wszystkim na ustalaniu priorytetów celów osób zamawiających produkt oraz ustaleniu ram czasowych i harmonogramów dostarczania.
Kluczem jest tutaj dokonanie wpierw przeglądu zakresu projektu, a potem jego dokładne zrozumienie poprzez przeprowadzanie iteracji.
3. Dzięki przypadkom użycia zyskuje się naturalną dekompozycję
Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody Agile to zacząć od definicji zakresu. Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane do harmonogramu projektu. Dokonujesz także refaktoryzacji przypadków użycia, w miarę potrzeb konsolidując i definiując podrzędne przypadki użycia, oraz definiując, jeśli zachodzi taka potrzeba, rozszerzeń przypadków użycia.
Dzięki przypadkom użycia (lub user stories) uzyskujemy szkielet testów. Nie tylko dekompozycję przestrzeni testów i ich systematyzację. Poprzez analizę powiązań przypadków użycia (np. z regułami biznesowymi) można wskazać więcej istotnych przypadków testu.
Kiedyś rozważałem możliwość utrzymywania tylko dokumentacji testu. Prypadki użycia dawały mi zbyt duży margines błędu przy szacowaniu kosztów. Z np. 25 przypadków użycia można wygenerować i 200 i 700 przypadków testu, w zależności od skomplikowania systemu. Z drugiej strony taką dużą grupą testów trudniej się operuje.
Dlatego rozwiązanie a) akceptowalne przez klientów b) „agilne”, to model projektu (w Enterprise Architect) stale synchronizowany z chmurą testów, utrzymywanych jako skrypty.
Niestety, z różnych względów, nie mogę dokumentów generować automatycznie z EA i dokument, stanowiący bazę do rozmów z klientem, jest utrzymywany „ręcznie”.