Dzisiejszy odcinek będzie o przypadkach użycia. Większość z Was pewnie bardziej kojarzy Przypadki Robinsona Crusoe ;), czyli mega fajną historię. Przypadki użycia są nie mniej fajnym narzędziem, które możecie wykorzystać w projektach.
Narzędzie, które pozwala rozwiązać dużo problemów:
– definiowanie zakresu
– zamodelowanie sobie całego systemu, w którym pracujecie
– określenie skąd mogą przyjść problemy i nieoczekiwane wymagania
Jeżeli to Was interesuje, to serdecznie zapraszam. Jeżeli nie interesuje, to warto, żeby zainteresowało, bo to jedno z najlepszych narzędzi, mocno niedocenionych, które warto znać.
Czym są przypadki użycia?
Use Case-y to naprawdę świetna sprawa, nie tylko dla IT. Możecie wykorzystać przypadki użycia i ten sposób opisywania rzeczywistości do praktycznie każdej dziedziny. Przejdziemy krok po kroku przez przykład, który dla Was przygotowałem, po to, żebyśmy później mogli pracować na bardziej zaawansowanych tematach.
Po co są przypadki użycia i skąd to się wzięło?
Wzięło się z IT, dlatego, że bardzo często sytuacja wygląda tak, że to jak sobie myślisz o pewnych rzeczach definiując wymagania i o tym, żeby było zrobione i wykonane myślisz tzw. głównym scenariuszem sukcesu.
Wyobraź sobie przykład bankomatu. Ktoś Ciebie pyta jak ten bankomat ma działać. Najprawdopodobniej odpowiedziałbyś „podchodzę do bankomatu, wkładam kartę, wpisuję pin, podaję kwotę do wypłaty, bankomat wypłaca pieniądze, zabieram kartę, zabieram pieniądze i odchodzę.”
To jest główny scenariusz sukcesu, w którym zakładasz, że nic złego się nie wydarzy. A co się stanie jeśli PIN będzie nieprawidłowy, jak się wtedy ma zachować oprogramowanie bankomatu? Co jeżeli nie ma wystarczającej kwoty w bankomacie, co jeżeli kwota wpisana nie jest podzielna przez nominały, które znajdują się w bankomacie, co jeżeli nie możesz się połączyć z bankiem, żeby sprawdzić z saldo? Cała masa wyjątków, o których musi pomyśleć programista. To powoduje trudność, bo będzie do Ciebie wracał i pytał jak w każdym z przypadków ma zachować się oprogramowanie. Jeśli przewidzisz pewne wypadki wcześniej to będzie mniej frustracji i szybciej to zostanie zrobione.
Przy definiowaniu zakresu projektu, czyli to co mamy do zrobienia – pułapka widzenia tylko głównego scenariusza sukcesu sprawia, że nie widzisz tego co się kryje pod spodem. Nie oszacowujesz jak złożony jest projekt, ile na to potrzeba czasu i pieniędzy. Pewnie znacie sytuację, że wydawało się proste, a później okazało się, że tak nie jest. Use Case-y (Przypadki Użycia) są właśnie takim narzędziem, które umożliwia przewidzenie takich sytuacji, ocenić złożoność problemu odpowiednio wcześniej.
Use Case (Przypadki Użycia) na przykładzie otwierania drzwi
Pomyślcie chwilę, gdybyście mieli kogoś nauczyć otwierania drzwi, to w jaki sposób miałaby wyglądać instrukcja.
To co widzicie na poniższym obrazku to jest notacja. Jest pewien standard opisywania przypadków użycia, po to, że jak ktoś inny patrzy na wasze przypadki użycia, żeby był w stanie je zrozumieć.
Przypadek użycia ujęty jest w kształcie prostokąta z zaokrąglonymi bokami (może ktoś wie i napisze w komentarzu jak się ten kształt nazywa). Przypadek użycia opisujemy przez Scenariusz Akcji np.:
1. Podchodzę do drzwi
2. Naciskam klamkę
3. Pcham drzwi
4. Przechodzę
5. Wykonaj „Zamykam drzwi”
Pod spodem opisujemy wyjątki:
3a. Drzwi nie otwierają się (drzwi pomimo pchania, nie otwierają się)
W skrócie tak właśnie wygląda przypadek użycia – macie listę kroków po kolei do wykonania i listę wyjątków, które mogą się zadziać.
Kolejna rzecz bardzo ważna – mamy Aktorów. Aktor to najczęściej osoba, która w danym przypadku ma do odegrania jakąś rolę. W tym przypadku to osoba otwierająca drzwi. W jednym przypadku może brać udział więcej aktorów niż jeden.
Kolejna sprawa – mamy dwa rodzaje rozszerzenia głównego przypadku użycia:
Extend – rozszerzenie nasz główny przypadek użycia o „exceptions” czyli wyjątkowe sytuacje
Np. Wyjątek – warunkowy przypadek użycia Drzwi się nie otwierają
Główny scenariusz sukcesu:
- Pociągnij
- Jeżeli zadziałało wyjdź przez drzwi
- Sprawdź czy drzwi mają zamek
- Otwórz kluczem
- Wróć do „otwórz drzwi”
Exceptions – wyjątki
2.1.b Nie mam klucza (do tego też może być jakiś wyjątek)
Widzicie to? Proste przechodzenie przez drzwi wcale nie jest takim prostym algorytmem do oprogramowania.
Include – to drugie rozszerzenie głównego przypadku użycia
Zawsze przypadek zawiera konkretne działania, jest to na tyle złożone, że nie chcemy tego przypadku użycia rozpisywać na 629 stron bo byłby ciężki tylko niektóre elementy opisujemy jako osobny przypadek użycia
Np.: Funkcja – złożony przypadek użycia wykorzystywany jako część innego
Przechodzenie przez drzwi
- Uważaj na próg
- Uważaj na framugę
- Wykonuj kroki, aż miniesz próg
- Odwróć się by móc zamknąć drzwi
Jak rozpisujecie waszą, rzeczywistość to definiujecie jakie są główne przypadki użycia. Kto bierze w tym udział (rozpisujemy aktorów i łączymy z przypadkami użycia), a później przy rozpisywaniu przypadków użycia wychodzą nam wyjątki. Do wyjątków przypisujemy kolejne elementy. Jeśli chcesz wykorzystać to do rozpisania procesów w swojej firmie to też możesz korzystać z takiego podejścia
Tak może wygladać przykład rozpisanej firmy:
Mała firma IT, kilku aktorów i rozpisane główne przypadki użycia.
Klient korzysta z gotowego produktu, poniżej jak może wyglądać rozpisanie korzystania z produktu:
Może się okazać, że korzysta z produktu i proponuje zmiany do wdrożenia. W tym przypadku aktorem będzie klient, wsparcie i szef handlowiec, którzy przekazuje uwagi do szefa technicznego, tam dochodzi do doprecyzowania wymagań. Jeżeli wszystko jest ok, funkcjonalność przechodzi do wdrożenia – aktorem tu jest programista, szef techniczny i kierownik projektu. Później wdrażamy funkcjonalność do tego włączony jest aktor wsparcie, a jednym z elementów w ramach zdarzenia jest testowanie. Testowanie – aktor wsparcie.
Use case-y mają pokazać wam obszar, mapę w ramach, której się poruszacie. Osobiście korzystam z MindManagera przy tworzeniu przypadków użycia, jest całkiem ok.
Use Case (Przpadki użycia) –literatura
„Writting Effective Use Cases” Alistair Cockburn – świetna książka, dla władających angielskim numer 1 . Po jej przeczytaniu jesteś w stanie pisać use case-y od razu.
Mam nadzieję, że było to dla was przydatne. Moim zdaniem Use Case-y są niedoceniane, a są naprawdę świetnym narzędziem, korzystajcie?
Zarządzaj projektami – prosto, praktycznie i skutecznie!
Odbierz bezpłatny kurs “Poznaj metodę 12 Pytań KISS PM®”
ZOBACZ VIDEO!