Od historii do systemów: opanowanie Use-Case 2.0 w rozwoju zorientowanym na Agile i z wykorzystaniem sztucznej inteligencji

Wprowadzenie

W szybko zmieniającym się środowisku rozwoju oprogramowania napięcie między elastycznością a strukturą od dawna stanowiło kluczowy wyzwanie. Przez dekady zespoły oscylowały między ciężkimi dokumentami zapewniającymi kompletność, ale hamującymi szybkość, a lekkimi historiami użytkownika promującymi prędkość, ale często pozbawiającymi kontekstu. W miarę jak systemy stają się bardziej złożone, a zapotrzebowanie na szybkie wdrażanie wzrasta, żadna z tych ekstremów nie wystarcza samodzielnie.

Wprowadźmy Use-Case 2.0: nowoczesna ewolucja inżynierii wymagań, która zamyka tę przerwę. Powstała na podstawie podstawowych zasad tradycyjnych przypadków użycia, ale ponownie zinterpretowana w kontekście metodologii Agile takich jak Scrum i Kanban. Use-Case 2.0 oferuje lekkie, ale skalowalne podejście do zapisywania potrzeb użytkowników. Łączy prostotę historii użytkownika z kompleksową strukturą przypadków użycia, zapewniając zespołom jasny plan od celów najwyższego poziomu po szczegółową realizację.

Ten studium przypadku bada, jak Use-Case 2.0 przekształca zbieranie wymagań, projektowanie i rozwój. Analizując jego podstawowe zasady, praktyczne zastosowania oraz zgodność z nowoczesnymi narzędziami wspomaganymi przez sztuczną inteligencję, pokazujemy, jak ta metodyka pozwala zespołom budować właściwą system skutecznie, zapewniając dostarczanie wartości w każdym inkrementie.

---

Ewolucja inżynierii wymagań

Przez prawie trzydzieści lat przypadki użycia były fundamentem inżynierii wymagań, pomagając zespołom zrozumieć, jak użytkownicy oddziałują na systemy w celu osiągnięcia swoich celów. Inspirowały wiele nowoczesnych technik, w tym historie użytkownika. Ale w ostatnich latach stało się coś niezwykłego – inspiracja przepływa w drugą stronę.

Use-Case 2.0 to nowe pokolenie rozwoju opartego na przypadkach użycia – lekkie, zorientowane na Agile i skromne – inspirowane historiami użytkownika oraz metodologiami Agile takimi jak Scrum i Kanban. Reprezentuje znaczącą ewolucję wobec tradycyjnych praktyk przypadków użycia, łącząc prostotę i skupienie historii użytkownika z kompleksową strukturą i skalowalnością, które przypadki użycia zawsze oferowały.

„Use-Case 2.0 zawiera wszystkie popularne wartości z przeszłości – nie tylko wspierające wymagania, ale także architekturę, projektowanie, testowanie i doświadczenie użytkownika – oraz odgrywa kluczową rolę w modelowaniu biznesowym i ponownym wykorzystaniu oprogramowania.”

Czym Use-Case 2.0 różni się od innych?

Tradycyjna metoda przypadków użycia polegała na tworzeniu szczegółowych dokumentów przypadków użycia, które zapisywały zachowanie systemu, w tym krótkie opisy, warunki wstępne, warunki końcowe oraz interakcje aktorów. Choć skuteczna, ta metoda często stawała się nadmiernie dokumentowana i miała trudności z dostosowaniem się do szybkiego cyklu iteracji w rozwoju Agile.

Use-Case 2.0 opiera się na tej podstawie, wprowadzając kilka innowacji:

• Zgodność z Agile: Płynna integracja z metodologiami Agile, ułatwiająca zespołom rozwojowym współpracę z interesariuszami, rozkładanie wymagań oraz szybką iterację

• Integracja historii użytkownika: Wprowadzenie historii użytkownika jako lekkiego sposobu na zapisanie potrzeb użytkownika i budowanie wspólnego zrozumienia

• Kawałki przypadków użycia: Rozbijanie skomplikowanych przypadków użycia na mniejsze, zarządzalne jednostki, które mogą być niezależnie realizowane i testowane

• Modele wizualne: Nacisk na schematy przepływu, diagramy działań i diagramy sekwencji w celu kompleksowego zrozumienia systemu

• Rozwój iteracyjny: Testowanie każdego komponentu w momencie jego budowy, umożliwiając wczesne wykrywanie problemów

W centrum Use-Case 2.0 pojawia się kluczowy nowy koncept: kawałek przypadku użycia. Kawałek to starannie wybrana część przypadku użycia, którą można pracować niezależnie – przekrój przechodzi nie tylko przez wymagania, ale także projektowanie, implementację, przypadki testowe i wyniki testów.

Rysunek 1: Wizualne przedstawienie struktury Use-Case 2.0 pokazujące relacje między aktorami, przypadkami użycia i kawałkami.

---

Sześć zasad Use-Case 2.0

Ivar Jacobson, Ian Spence i Kurt Bittner zidentyfikowali sześć podstawowych zasad, które stanowią fundament pomyślnej implementacji przypadków użycia:

1. Uprość to, opowiadając historie

Opowiadanie historii to najprostszy i najskuteczniejszy sposób komunikowania, co system powinien robić. Przypadki użycia zapisują cele systemu, a historie pokrywają sposób osiągnięcia tych celów oraz sposób radzenia sobie z problemami, które pojawiają się w trakcie. Dzięki temu wymagania można łatwo zapisywać, dzielić się nimi i rozumieć.

2. Zrozumienie dużego obrazu

Nie ma znaczenia, czy twój system jest duży czy mały, zrozumienie całego obrazu jest kluczowe. Bez takiego przeglądowego spojrzenia zespoły nie mogą poprawnie podejmować decyzji dotyczących zakresu, kosztów czy wartości. Diagram przypadków użycia oferuje prosty sposób przedstawienia przeglądu wymagań systemu – pokazuje wszystkie sposoby, w jakie system może być używany, kto inicjuje interakcję oraz jakie inne strony są zaangażowane.

Rysunek 2: Przykładowy diagram przypadków użycia ilustrujący aktorów i ich interakcje z systemem.

3. Skup się na wartości

Wartość powstaje wyłącznie wtedy, gdy system jest faktycznie używany. Zamiast skupiać się na długich listach funkcji lub cech, przypadki użycia skupiają się na tym, jak system będzie używany w celu osiągnięcia konkretnych celów dla określonych użytkowników. Podstawowy przepływ opisuje najprostszy sposób osiągnięcia celu, podczas gdy przepływy alternatywne dodają opcje i obsługę błędów. Zespoły mogą najpierw wysłać podstawowy przepływ, a opcje dodawać później – to zasada dodawania od samego początku.

4. Buduj system w kawałkach

Większość systemów wymaga obszernych prac przed staniem się użytecznymi. Błąd polega na próbie zbudowania takiego systemu od razu. Zamiast tego systemy powinny być budowane w kawałkach, z których każdy przynosi jasną wartość użytkownikom.

Sposób jest prosty:

1. Zidentyfikuj najbardziej przydatną rzecz, jaką system musi wykonać

2. Podziel ją na cieńsze, łatwiejsze do zarządzania kawałki

3. Zdefiniuj przypadki testowe reprezentujące akceptację tych kawałków

4. Wybierz najbardziej centralny kawałek, który przechodzi przez całą koncepcję

5. Oszacuj to zespołowo i zacznij budować

5. Dostarczaj system w iteracjach

Systemy oprogramowania ewoluują przez wiele generacji i wydań. Każda iteracja powinna zapewniać demonstrowalną lub użyteczną wersję systemu. Use-Case 2.0 wspiera to, dzieląc przypadki użycia na elementy pracy, które mogą być złożone w iteracje i w końcu w wydania.

6. Dostosuj się do potrzeb zespołu

Nie ma uniwersalnego rozwiązania w rozwoju oprogramowania. Różne zespoły i sytuacje wymagają różnych stylów i poziomów szczegółowości. Use-Case 2.0 może być tak lekka, jak tylko się chce – małe, współpracy zespoly mogą używać lekkich narracji przypadków użycia na prostych kartkach, podczas gdy duże rozproszone zespoły mogą używać bardziej szczegółowych dokumentów.

---

Anatomia Use-Case 2.0: Kawałki, scenariusze i zadania

Trzy kluczowe pojęcia definiują, jak Use-Case 2.0 działa w praktyce:

Kawałki przypadków użycia to mniejsze, łatwiejsze do zarządzania elementy przypadku użycia. Zamiast definiować cały przypadek użycia w jednym dokumencie, Use-Case 2.0 dzieli go na kawałki, które są łatwiejsze do projektowania, tworzenia i testowania. Każdy kawałek reprezentuje określoną funkcjonalność, jaką system musi wykonać w celu wspierania konkretnej czynności lub celu użytkownika.

Scenariusze reprezentują różne ścieżki, które użytkownicy mogą przejść, aby ukończyć zadania w ramach kawałka:

• Ścieżka normalna: Oczekiwana lub standardowa sekwencja operacji (tzw. „szczęśliwa droga”)

• Ścieżki alternatywne: Warianty lub inne sposoby osiągnięcia tego samego celu

• Ścieżki wyjątkowe: Błędy lub nietypowe sytuacje, które mogą wystąpić

Zadaniato konkretne czynności, które użytkownicy muszą wykonać w ramach scenariusza, aby osiągnąć cel. Odpowiadają one poszczególnym krokom tworzącym scenariusz.

Na przykład w przypadku fragmentu przypadku użycia „Przeglądanie produktów” na platformie e-commerce:

• Ścieżka normalna: Użytkownik wyszukuje, przegląda wyniki, wybiera produkt, dodaje do koszyka i przechodzi do płatności

• Ścieżka alternatywna: Użytkownik wybiera inny sposób płatności (PayPal zamiast karty kredytowej)

• Ścieżka wyjątkowa: Płatność jest odrzucana z powodu niewystarczających środków lub nieprawidłowego adresu rozliczeniowego

 

Rysunek 3: szczegółowy podział fragmentu przypadku użycia pokazujący ścieżki normalne, alternatywne i wyjątkowe.

---

Przypadki użycia w porównaniu do historii użytkownika: dlaczego oba mają znaczenie

To właśnie w tym miejscu Use-Case 2.0 oferuje przekonującą odpowiedź na powszechny wyzwanie Agile.

Historia użytkownika to samodzielny element — nie ma wbudowanej relacji do innych historii. Backlog produktu z 200 historiami użytkownika staje się trudny do przewijania bez dodatkowych mechanizmów grupowania, takich jak epiki lub tematy. Historie mogą tracić kontekst, a zespoły często piszą testy akceptacyjne zbyt późno.

Przypadek użycia jest inny. Grupuje wszystkie powiązane historie pod jednym celem, z:

• Jasnym celem (sam przypadki użycia)

• Krok po kroku (przepływ podstawowy)

• Zdefiniowane warianty (przepływy alternatywne)

• Kryteria akceptacji (przypadki testowe)

Gdy patrzysz na przypadek użycia, widzisz całościową wizję sposobu, w jaki użytkownik osiąga określony cel, a nie tylko pojedynczy fragment.

Rysunek 4: Wykres porównawczy podkreślający różnice i wzajemne uzupełnianie się historii użytkownika i przypadków użycia.

---

Use-Case 2.0 w praktyce Agile: Przykłady z rzeczywistego życia

Use-Case 2.0 zapewnia strukturę dla zespołów Agile, które napotykają typowe wyzwania:

Platforma e-commerce: Przypadki użycia dla systemu zakupów online obejmują przeglądanie produktów, wyszukiwanie produktów, dodawanie do koszyka, przejście do płatności i dokonywanie płatności. Wczesny diagram przypadków użycia ujawnia brakujące przepływy — takie jak „Kupowanie jako gość” — które można dodać przed zaakceptowaniem sprintu, zapobiegając problemom z opuszczeniem koszyka w środowisku produkcyjnym.

Aplikacja mobilna do bankowości: Dokumentowanie przepływów alternatywnych, takich jak „nieprawidłowe dane logowania → przejście do zabezpieczenia wieloskładnikowego”, pozwala wczesnie wykryć luki w zabezpieczeniach, unikając kosztownych aktualizacji po wydaniu i budując zaufanie użytkowników.

Usługa współdzielenia przejazdów: Przycinanie przypadków użycia napędza rozwój MVP — zacznij od żądania, akceptacji i płatności; następnie dodaj oceny i skargi w kolejnych iteracjach. Pozwala to na szybkie dostarczanie wartości z jasną priorytetyzacją.

Platforma rezerwacji wizyt medycznych: Przegląd przypadków użycia przez stakeholderów ujawnia wymagania dotyczące obsługi „braków na wizytach”. Można dodać automatyczne przeprowadzanie ponownych wizyt, co potencjalnie zmniejszy liczbę nieodbytych wizyt.

Rysunek 5: Przykład zespołu agilnego wykorzystującego przycinanie przypadków użycia do planowania sprintów.

---

Połączenie z AI: Use-Case 2.0 spotyka się z rozwojem wspomaganym przez AI

Use-Case 2.0 został pierwotnie opracowany w 2011 roku, dawno przed pojawieniem się asystentów do programowania opartych na AI. Jednak jego zasady okazują się doskonałym dopasowaniem do rozwoju wspomaganego przez AI.

Asystenci do programowania opartych na AI działają najlepiej przy jasnych, strukturalnych specyfikacjach. Przypadek użycia zapewnia:

• Jasny cel dla AI, aby go zrozumieć

• Krok po kroku przepływ, który AI może zaimplementować

• Zdefiniowane warianty, które AI może obsłużyć

• Kryteria akceptacji, które AI musi spełnić

Cztery fazy rozwoju wspomaganego przez AI naturalnie odpowiadają zasadom Use-Case 2.0:

• Początek → „Zrozumienie dużego obrazu” — tworzenie wymagań biznesowych i początkowych diagramów przypadków użycia

• Ustalenie szczegółów → „Skupienie się na wartości” — tworzenie specyfikacji z podstawowymi i alternatywnymi przepływami

• Budowanie → „Budowanie systemu w kawałkach” — przy użyciu AI jednostką pracy może być cała specyfikacja przypadku użycia, a nie tylko kawałek

• Przejście → „Dostarczanie systemu w iteracjach” — test akceptacji użytkownika potwierdza, że przypadki użycia spełniają potrzeby stakeholderów

Rysunek 6: Ilustracja sposobu, w jaki asystenci AI integrują się z przepływami Use-Case 2.0.

---

Wprowadzenie do Use-Case 2.0

Nie musisz od razu przyjąć całej praktyki Use-Case 2.0. Zacznij od trzech rzeczy:

1. Narysuj diagram przypadków użycia — Zidentyfikuj aktorów i przypadki użycia dla Twojego systemu. Zajmie to 30 minut i da Ci duży obraz sytuacji.

2. Napisz jeden opis przypadku użycia — Wybierz najważniejszy przypadek użycia. Napisz podstawowy przepływ jako punktowany szkic. Na początku podaj tylko nazwy wariantów.

3. Zaimplementuj swój pierwszy przypadek użycia — Niezależnie od tego, czy używasz rozwoju ręcznego, czy pomocy AI, pozwól przypadkowi użycia kierować Twoją implementacją.

Można śledzić przypadki użycia na prostym arkuszu kalkulacyjnym lub na kartkach typu post-it. Nie potrzeba specjalnego oprogramowania, aby rozpocząć pracę z Use-Case 2.0.

---

Wnioski

Use-Case 2.0 nie jest zastępstwem historii użytkownika — to uzupełnienie. Przypadki użycia dają Ci duży obraz i strukturę. Przypadki testowe dają Ci jasną definicję gotowości. W przypadku rozwoju ręcznego, fragmenty zapewniają odpowiednio dobraną wielkość zadań.

Kluczową przesłanką jest to, że przypadki użycia zawierają techniki oferowane przez historie użytkownika, jednocześnie oferując znacznie więcej w przypadku większych systemów, większych zespołów i bardziej złożonych rozwojów. Są tak lekkie jak historie użytkownika, ale mogą się skalować w sposób płynny i strukturalny, umożliwiając uwzględnienie dowolnej ilości szczegółów. Najważniejsze, że napędzają i łączą wiele innych aspektów rozwoju oprogramowania.

W erze, gdy sztuczna inteligencja przekształca sposób budowania oprogramowania, Use-Case 2.0 zapewnia strukturalną, skupioną na użytkowniku podstawę, która gwarantuje, że budujemy system właściwego — nie tylko system, który działa. Przyjmując tę ewoluowaną metodologię, zespoły mogą osiągnąć większe przejrzystość, wydajność i dostarczanie wartości w swoich drogach Agile.

---

Bibliografia

1. Use-Case 2.0: Ewolucja wymagań w podejściu Agile: Kompleksowy przegląd zasad i praktyk Use-Case 2.0.

2. Integracja przypadków użycia z metodologiami Agile: Przewodnik dotyczący łączenia przypadków użycia z Scrum i Kanban.

3. Siła fragmentów przypadków użycia: szczegółowe wyjaśnienie technik dzielenia przypadków użycia w Use-Case 2.0.

4. Rozwój wspomagany przez AI i strukturalne wymagania: Badanie, jak narzędzia AI korzystają z zorganizowanych przypadków użycia.

5. Modelowanie wizualne w projektach Agile: Najlepsze praktyki dotyczące używania diagramów w środowiskach Agile.