Przy każdym procesie odkrywczym istnieje ryzyko, że ktoś coś źle zrozumie, że poznanie biznesu, i dalej w konsekwencji tego, jego zrozumienie będzie narażone w wielu miejscach na błąd. Mam tu na myśli sytuację gdzie z jednej strony są eksperci od swojej działki w pracy a z drugiej np. programiści – czyli osoby, które mają coś stworzyć, wykreować. Pół biedy jak zespół inżynierów jest pochodzenia tej samej organizacji co zespół ekspertów – gorzej jak spotykają się to nowe osoby – gorzej dla sprawy. Stworzenie prostej funkcjonalności być może nie stanowi wielkiego problemu – ale wyobraźmy sobie, że wykreowanie czegoś ma obejmować złożony system, gdzie partycypować musi wiele osób z wielu działów czy też departamentów. W tym krótkim wpisie postaram się zwrócić uwagę na fakt, iż powszechnie znane metody zbierania wymagań mogą zakrzywić obraz projektu systemu lub jego części.

• co to jest user stories
• gdzie i kiedy najczęściej wykorzystać user stories
• co może pójść nie tak podczas zbierania wymagań

Co to jest user stories?

Jak podaje wikipedia user stories to “metoda opisywania wymagań przy tworzeniu oprogramowania w metodykach zwinnych. Historyjki są zazwyczaj pisane z perspektywy użytkownika końcowego. Stosowany jest prosty język, który jest zrozumiały zarówno przez programistów, jak i osoby nietechniczne (np. analitycy, projektanci, menedżerowie).” Autorami takiego opisywania wymagań są Kent Beck i Martin Fowler. Parafrazując, to jest opowieść użytkownika systemu: co chce osiągnąć pracując na tym systemie. Wszyscy doświadczeni i mniej doświadczeni z branży IT, powinni spotkać na swojej drodze zawodowej historyjki w praktyce, śmiem twierdzić że często to się dzieje nieświadomie. W tej metodzie, najważniejszy jest kontekst użytkownika, to on nam przedstawia jako aktor historyjki co tak naprawdę chce osiągnąć. Stworzona do tego została stała konstrukcja, która ma ułatwić tworzenie opisów. 

Jako – Kto? – chcę wykonać – Co? – aby – Dlaczego?

Odpowiadając na te trzy pytania możemy uzyskać esencję, tego na czym zależy użytkownikowi w działaniu omawianej funkcjonalności. Internety i książki mówią jeszcze, że każda historyjka składa się z takich elementów jak: karta, konwersacja i konfirmacja. Na karcie zapisujemy samą historyjkę – to pomaga planować późniejszą pracę, jest to tylko forma prezentacji wymagania. Konwersacja – to nic innego jak rozmowa o danej historyjce. Sama w sobie nic nie mówi, ale powinna być bodźcem do zgłębiania tematu i uzyskiwania większej liczby szczegółów. Konfirmacja to potwierdzenie poprzez testy akceptacyjne.

Z teorii każde user stories powinno być tworzone z myślą o cechach, które nadadzą wartości historyjce. A oto te cechy:

istniejąca samodzielnie (ang. Independent),

negocjowalna (ang. Negotiable),

wartościowa (ang. Valuable),

estymowalna (ang. Estimable),

mała (ang. Small),

testowalna (ang. Testable).

Jak już mamy spisane user stories, i wszyscy członkowie zespołu mają pełną świadomość zrozumienia co do opisu wymagań, to powinno się dokonać dekompozycji tych opowieści do zadań. A potem odpalić sprint i czekać aż coś wybuchnie 😉 Nie zawsze tak się dzieje, ale ryzyko że inne funkcjonalności zupełnie nie współpracują z tymi co były opisywane w zupełnie innej historyjce jest duże.

Kiedy najczęściej wykorzystać user stories?

Historyjki użytkowników są najczęstszym narzędziem do zbierania wymagań. Moim zdaniem, często nieświadomie osoby z różnych środowisk i organizacji wykorzystują to narzędzie do przekazania wiedzy co ma zostać zrobione. Dzieje się tak, ponieważ jest to prosta forma językowa, nie wymagająca specjalnego przeszkolenia, może ją używać każdy. No właśnie nie do końca… Okazuje się, że kłopot tkwi w szczegółach – o tym będę pisał w ostatniej części tego wpisu. Ale faktycznie ta forma ekspresji wymagań jest dobrym zaczątkiem do głębszej analizy, może inicjować rozmowy gdzie po jakimś czasie można doszukiwać się szczegółów wymagań. Jest też dobrym bodźcem do angażowania grupy warsztatowej. Generalnie prawie zawsze od niej się zaczyna zbieranie wymagań. 

User stories może być wykorzystywane najczęściej z sukcesem w adaptacyjnych metodykach prowadzenia projektów. Pojedyncze funkcjonalności, złożone systemy, procesy rozciągające się na wiele obszarów zawierać będzie jakieś historyjki. To w tych miejscach najlepiej jest stosować to narzędzie do wyciągania wiedzy od zleceniodawców. Trzeba tylko pamiętać o jednej rzeczy – user stories nie są pojedynczą informacją wyrwaną z kontekstu. 

Warto zwrócić szczególną uwagę na stosowanie tego narzędzia w grupie na warsztatach, gdzie celem jest zrozumienie co ma wykonać IT. Jeśli jesteś osobą, która się podejmuje analizy i masz przed sobą słabo rozgadany biznes, to dzięki bodźcowaniu ich przykładami historyjek możesz spowodować, że ktoś z grupy sam zacznie opowiadać co chce uzyskać w formie bardziej przyjaznej niż odpowiedzi na twoje pytania.

Co może pójść nie tak podczas zbierania wymagań ?

Userier stories to jakaś opowieść. Ale złożone funkcjonalności albo całe systemy posiadają bardziej skomplikowane logiki niż przypadkowa kolejność historyjek. Nie możemy traktować historyjek jako odkrycie domeny biznesowej, ponieważ aby zrozumieć o co chodzi w danym obszarze,  musimy dokładnie wiedzieć co ma się wydarzyć, w jakiej kolejności, kto, kiedy i jak ingeruje w dane zdarzenie itp. Analizowanie domeny w sposób impresjonistyczny, czyli wyrywkowo, bez kontekstu na pewno spowoduje, że na końcu system może nie spełniać oczekiwań. Przypadkowa kolejność historyjek jako obrazu całego systemu czy procesu wyłoży się na testach albo co najgorsze na produkcji.

Wyobraźmy sobie że takie historyjki trafiają od razu do backlogu projektu i są podejmowane w kochanych sprintach. W mojej opinii od tego momentu zaczyna się budowanie nieprzemyślanego systemu. Złudne może okazać się też to, że każda historyjka może przejść UATy, ale osobno – brak holistycznego spojrzenia na testy (tym samym na system) może powodować kłopoty. System to są procesy, połączone ze sobą lub nie, a częścią procesu jest jakieś user stories, dlatego aby tworzenie historyjek było kaloryczne, należy mieć na względzie zawsze cały proces. 

Innym zagrożeniem w tej metodzie jest jej prostota. Jeśli coś jest proste to wydaje się, że każdy może tego używać. Czy to oznacza, że każdy może przeprowadzić warsztat gdzie będą spisywane historyjki – no nie. Na koniec dnia możemy otrzymać listę wymagań, którą można porównać do koncertu życzeń. Zbudowanie z tego systemu = mission impossible. Aby osiągnąć cel (odkryć domenę biznesową) należy zastosować inne narzędzia jak np: Event Storming, można się wspierać User Story Map, określić słownik pojęć używanych. To wymaga kompetencji oraz doświadczenia. 

Oczywiście ten tekst to są moje przemyślenia i refleksje. Możesz się z nimi zgadzać bądź nie 🙂 Jeśli nie to chętnie się dowiem dlaczego.