User stories w praktyce

Opowieści użytkownika są kojarzone z samoprzylepnymi karteczkami

Mogłoby się wydawać (szczególnie z perspektywy młodych programistów), że praca nad projektem informatycznym rozpoczyna się w momencie napisania początkowych linijek kodu lub rozrysowania na kartce komponentów, z których będzie się składał program. Jednak, start produkcji oprogramowania ma miejsce o wiele, wiele wcześniej i niekoniecznie muszą w nim uczestniczyć osoby zajmujące się kodem źródłowym i technikaliami. Co więcej, inicjacja nie dotyczy również momentu, w którym graficy i projektanci interfejsu tworzą pierwsze makiety o niskiej wierności (czym one są – o tym innym razem) i są one dyskutowane z klientem. Fundamentem dla każdego projektu są rozmowy z klientem o tym, co właściwie oprogramowania ma robić.

W ten sposób dochodzimy do tematu wymagań, które same w sobie są na tyle obszernym zagadnieniem, że można zająć nimi cały przedmiot na specjalności związanej z inżynierią oprogramowania na Wydziale Informatyki Politechniki Poznańskiej. Będziemy do nich co jakiś czas wracać, natomiast dzisiaj skupimy się na składnikach, które mówią nam o tym, co aplikacja ma robić. Fachowo nazywamy je wymaganiami funkcjonalnymi (w skrócie FR) i ich opisanie jest głównym celem powstania dokumentu SRS, czyli specyfikacji wymagań oprogramowania (ang. Software Requirements Specification). Oczywiście, wynikają one z rozmów i analizy oczekiwań klienta oraz potencjalnych użytkowników. Można je zapisywać w kilku formach, z których najbardziej przystępną i popularną wydają się opowieści użytkownika (ang. user stories).

Koncepcja wywodzi się od żółtych, samoprzylepnych karteczek, na których krótko i szybko zapisywało się wymaganie wobec systemu, przyklejało na tablicę z zadaniami, a potem ściągano, gdy ktoś się tym zajął. Przynajmniej, tak by to mogło wyglądać, gdyż opowieści użytkownika wydają się pewnym rozwinięciem tej idei i pozwalają treściwie opisać oczekiwania użytkownika (i nie tylko) dotyczące tworzonego oprogramowania. Jest to sposób częściej wybierany w porównaniu z przypadkami użycia (ang. use cases), które są bardziej sformalizowane, opisują sesję w krokach i mimo przystępności są jednak bardziej uciążliwe w tworzeniu oraz utrzymywaniu niż opowieści użytkownika. Mają jednak tę zaletę, że dzięki nim wymaganie może być opisane dokładniej i pozostawia mniej miejsca na interpretację. Jak zatem poradzić sobie z tym kłopotem w przypadku user stories?

Sekret tkwi w tym, że nie jest powiedziane, iż opowieści muszą składać się z jednego zdania. Owszem – powinny, ale równie dobrze jedna historyjka może faktycznie być… historyjką i składać się z kilku zdań tworzących akapit. Nie zmienia to faktu, że każde {i}story{/i} zaczyna się bardzo charakterystycznie:

Jako {aktor} chcę/oczekuję/mogę…

To, czym jest aktor, to temat na dłuższe rozważania – na potrzeby tego wpisu możemy przyjąć, że jest to pewna klasa użytkowników systemu. Każde wymaganie powinno dotyczyć określonego aktora lub systemu, dzięki czemu programiści wiedzą, w jakim kontekście mają zaimplementować daną funkcjonalność. Aby ułatwić „identyfikowanie się” z odbiorcą wymagania, najczęściej zapisuje się je w pierwszej osobie liczby pojedynczej. Oczywiście, potem następuje meritum, czyli to, co właściwie ten użytkownik może zrobić lub czego spodziewa się od systemu. Poniżej przykłady zarówno krótszej, jak i dłuższej formy.

Jako student chcę zobaczyć moje oceny wystawione w dowolnym semestrze, na którym studiowałem.

Jako klient chciałbym móc edytować moje jeszcze niezrealizowane zamówienie. W tym celu mogę wybrać listę moich zamówień, następnie znaleźć to żądane i rozpocząć jego edycję. Po modyfikacji nazwy, liczby oraz rodzaju produktów i/lub daty dostawy, mogę potwierdzić swoje zmiany, które natychmiast pojawią się w systemie. Jeśli sie rozmyśliłem, mogę anulować swoją edycję.

Jak widać, o ile pierwsza forma jest dużo szybsza w zapisie i pozwala od razu zapisać to, co chcemy osiągnąć, o tyle druga podaje zdecydowanie więcej informacji. Używane słownictwo jest dość obrazowe, ale to nie oznacza, że nie jest konkretne – jak najbardziej powinna zostać zachowana terminologia projektowa, obejmująca np. właściwe nazwy aktorów czy obiektów biznesowych. Dodatkowo, dłuższa opowieść może posłużyć do dalszej dekompozycji wymagań, co pomaga we właściwej analizie potrzeb klienta i podziale zadań w zespole. Same opowieści użytkownika są również łatwiej przyswajalne przez osoby nietechniczne, a co za tym idzie – nasz klient może szybciej je zrozumieć, ocenić i zaakceptować lub zgłosić poprawki, dzięki czemu oprogramowanie będzie jeszcze bardziej odpowiadało jego oczekiwaniom.

Tagi: ,

mindseater