Czy User Stories nadają się do dokumentowania wymagań?

W dwudziestym odcinku podcastu „Zwinne organizacje” Paweł Tomkiel opowiada o historyjkach użytkownika. Tłumaczy, czym jest user story, dlaczego je piszemy oraz jak dobrze używać historyjek użytkownika.

Transkrypcja podcastu

Paweł: Cześć, nazywam się Paweł Tomkiel i jestem agile coachem w Deloitte Digital.

Witam Cię w kolejnym odcinku podcastu. Odcinek, który dla mnie, personalnie jest dosyć ważny, żeby wyjaśnić pewne różnice w tym, jak była projektowana sama zwinność i metodyki agile, do czego właściwie służą, i jak to czasem bywa implementowane w rzeczywistości.

Zajmiemy się dzisiaj historyjkami użytkownika, czyli po angielsku „user story” i myślę, że większość z Was, którzy tego słuchacie, znacie to określenie, potraficie sobie wyobrazić jak wygląda user story i wiecie jak jest używane w Waszej organizacji. Tylko to, co zauważyłem ze swojego doświadczenia, to jak historyjki są używane w organizacjach, a jak powstały, jaka jest ich geneza, do czego były zaprojektowane – to są czasem dwie różne rzeczy. Zaczynamy.

Czym jest User Story?

Żeby powiedzieć o tym, czym jest user story, trzeba zrobić krok wstecz i zastanowić się, dlaczego właściwie piszemy user story. User story to jest nośnik jakiegoś wymagania względem systemu, względem oprogramowania, które chcemy spełnić, które chcemy dostarczyć. Czyli na samym początku mamy użytkownika, stąd też jest to historyjka użytkownika. Mamy użytkownika, który ma jakąś potrzebę, który ma jakiś cel do spełnienia i my chcemy mu pomóc ten cel osiągnąć, chcemy zrealizować tę potrzebę właśnie przez rozwój naszego oprogramowania, przez konkretną historyjkę użytkownika.

Historyjki użytkownika są najczęściej pisane po polsku w formacie, „jako ktoś”, „chcę coś”, „żeby zrealizować pewien cel”. Czyli mamy tutaj trzy zmienne: jako ktoś – jakaś rola, jakiś użytkownik, może jako menedżer, jakaś konkretna rola w naszym systemie, która istnieje; chcę – konkretną rzecz albo wykonać, albo konkretne rzeczy widzieć, czyli mam jakąś potrzebę, chcę tę potrzebę spełnić; żeby mój cel został osiągnięty – ten cel będzie różny w zależności od ról i ta potrzeba ma spełniać ten konkretny cel. To jest całość definicji user story, jaka powstała pierwotnie. Przykładem takiej historyjki może być: jako administrator, chcę mieć możliwość wysyłania smsów, żeby powiadomić użytkownika o planowanym wyłączeniu systemu. Czyli jako administrator – to jest rola, chcę mieć możliwość wysyłania smsów – to jest moja potrzeba, żeby powiadamiać użytkowników o planowanym wyłączeniu systemu – to jest mój cel, który chcę osiągnąć.

Inny przykład, który możecie odnieść do systemów synchronizacji plików do chmury to: jako użytkownik chcę móc wybrać, które foldery są synchronizowane na mój dysk, żeby nie przepełniać dysku plikami, których teraz nie potrzebuję. Czyli jako użytkownik – rola, chcę móc wybrać, które foldery są synchronizowane na mój dysk – to jest moja potrzeba, po to, żeby nie przepełniać dysku plikami, których teraz nie potrzebuję – to jest cel, który chcę osiągnąć przez tę konkretną funkcjonalność, przez tę konkretną potrzebę.

Ta definicja historyjki użytkownika, którą podałem, jest bardzo krótka, niesie dosyć mało informacji sama w sobie. Dlaczego tak jest, zaraz o tym powiem, ale chcę to teraz porównać do tego, jak widzimy to na rynku, jak to działa w zespołach programistycznych.

Najczęściej taka historyjka użytkownika nie kończy się na tym jednym zdaniu. Nie kończy się na zdaniu: jako- rola, chcę- potrzeba, żeby- cel. Raczej to jest pierwsze zdanie, po którym jest bardzo długa dokumentacja konkretnie tego jednego wymagania. Jak ma zostać zrealizowane, jakie ma wymagania funkcjonalne, niefunkcjonalne, jakie są diagramy bazy danych, absolutnie wszystko.

Dlaczego tak jest?

Wygląda na to, że historyjka użytkownika stała się standardem w zespołach deweloperskich, więc wszystkie to zaadoptowały, jednocześnie nie zmieniając procesów na zwinne. Więc nadal mamy analityków biznesowych, nadal mamy osoby, które dokonują tej analizy wstępnej, zbierają wymagania i opisują je w formie formalnych dokumentów, tylko zawierają to teraz w innej nazwie. Teraz jest to historyjka użytkownika, która jest bardzo długa, bo zawiera dokładnie te informacje, które zawierała kiedyś w takim standardowym podejściu do programowania, gdzie na początku zawsze mieliśmy analityków biznesowych. Nie mówię, że jest coś złego w posiadaniu analityków biznesowych, albo, że tworzenie takiej dokumentacji jest złe same w sobie. Raczej mówię, że to nie jest fragment zwinności, a jedynie wzięta z niej nazwa. To, że nazwiemy to user story, nie zwiększy zwinności zespołu, nie przyspieszy to procesu wytwarzania oprogramowania, jeżeli na samym początku będzie ta preanaliza wykonywana przez kogoś innego niż deweloperów. Bo w takim procesie, gdzie historyjki użytkownika są tworzone przez kogoś wcześniej, nawet często osobny zespół, a potek czyta je jakiś menedżer, który to akceptuje i dopiero są przekazywane do programistów – to deweloperzy widzą taką historyjkę użytkownika po raz pierwszy dopiero na końcu procesu. Oni nie uczestniczyli w procesie zbierania wymagania, nie rozmawiali z tym użytkownikiem, nie rozumieją go. Deweloper wykona dokładnie to, co dostał w wymaganiach. Czyli wracamy do takiego problemu, który zwinność chciała rozwiązać, żeby była ta interakcja między zespołem programistycznym a użytkownikiem końcowym systemu. Żeby rozumieli się nawzajem, rozmawiali o tym, jaka jest ich potrzeba i w taki iteracyjny sposób dostarczali oprogramowanie, badali czy to spełnia potrzeby użytkownika i na podstawie tej pętli informacji zwrotnej podejmowali kolejne decyzje, podejmowali kolejne kroki.

Kiedy w procesie jest analityk biznesowy to on zbierze te wymagania, on będzie rozmawiał z użytkownikiem, on to wszystko opisze, tylko, że on oraz opis tego, co powstało, czyli ta dokumentacja, nazwijmy to historyjką użytkownika, są jakimś pośrednim nośnikiem informacji do dewelopera. To znaczy, że deweloper dostając taką dokumentację albo ją zrozumie, albo jej nie zrozumie, być może trzeba będzie mu ją wytłumaczyć, tylko on nie będzie rozmawiał z użytkownikiem, on będzie rozmawiał z pośrednikiem w postaci analityka biznesowego.

Jako były programista zaryzykuję tu stwierdzenie, że programistom taki stan rzeczy jest całkiem na rękę, tzn. wygodniej jest dostać gotowy zestaw wymagań opisanych, praktycznie jak na tacy, co należy zrobić i po prostu to zakodować i oddać efekt swojej pracy. Z drugiej strony dla organizacji ten czas deweloperów jest poświęcony tylko i wyłącznie na kodowanie, czyli jest lepsza utylizacja programisty. Programista nie traci czasu na rozmowę z użytkownikiem. Tylko, że właśnie zwinność zakłada połączenie programistów z użytkownikami, po to, aby dostarczyć większą wartość. Jeżeli chcemy po prostu wykonać wymagania, chcemy po prostu stworzyć oprogramowanie to je stworzymy. W tym modelu będzie to działać dokładnie tak, że to oprogramowanie powstanie tak, jak zostało opisane, tylko wtedy nie zawsze może zostać osiągnięta ta wartość, która mogłaby powstać, gdyby po prostu programista porozmawiał z użytkownikiem końcowym.

Jak dobrze używać historyjek użytkownika?

Nie chcę powiedzieć, że to, co opisałem w poprzednim punkcie jest czymś złym, bo nie jest. To jest po prostu inny model działania, inny model wytwarzania oprogramowania. Chcę tylko powiedzieć, że to, co powstaje tam, takie bardzo ekstensywne, wielostronicowe historyjki użytkownika, które mają swoje dedykowane dokumenty to nie brzmi jak historyjka użytkownika, tzn. nie jestem przekonany czy to zwiększy faktycznie zwinność zespołu czy organizacji.

Bo ta historyjka użytkownika, którą opisałem na początku, ten format: „jako ktoś”, „chcę coś”, „aby zrealizować pewien cel”, ten format celowo nie jest ekstensywny. On celowo nie niesie ze sobą wszystkich informacji. On niesie tylko informacje o konkretnej potrzebie użytkownika, albo jakiejś roli w systemie i dlatego nie jest to takie szczegółowe, bo jest to, gdzieś widziałem ładne określenie na user story, bo jest to „zaproszenie do konwersacji”, tzn. dokładnie to jedno zdanie ma być punktem początkowym rozmowy między programistami, między inżynierami, a użytkownikami systemu. Po to, żeby na podstawie tej konkretnej historyjki użytkownika wypracować jak najlepsze rozwiązanie, które może się potem zamienić w formalne artefakty dokumentacji, choć najlepiej jakby się zamieniło po prostu w kod, żeby kod był samodokumentujący się.

Jeżeli chcesz korzystać z historyjek użytkownika tak, jak były do tego zaprojektowane to musisz zmienić model działania. To konwersacja, interakcja powinna być tą podstawą, na jakiej budujemy wartość. Nie jest to standard w dużych organizacjach. Duże organizacje, które są wyskalowane będą miały na pewno trudność ze zwiększeniem swojej zwinności, a szczególnie z pozbyciem się dokumentacji. Szczególnie tak jak my - Deloitte pracujemy z bankami czy instytucjami finansowymi, tam dokumentacja jest po prostu wymagana, ale jeśli możesz spróbować nie napisać wszystkiego w historyjce użytkownika, znaczy nie próbować zawrzeć wszystkich informacji, wyznaczyć tylko pewne granice, wtedy rozpoczynasz jakąś konwersację, wtedy dajesz tę obietnicę do konwersacji i na podstawie tej współpracy powstaje wartościowy produkt. To wartość dla użytkownika końcowego jest wtedy tą podstawą, na jakiej budujemy. Nie to, czy to spełnia nasze wymagania formalne, czy jest dobrze opisane, czy zostało zaakceptowane przez wszystkich, tylko chcemy szybko coś wdrożyć, dać to użytkownikowi końcowemu i zweryfikować czy to przyniosło mu realną wartość.

Czego nie dadzą historyjki użytkownika?

W takiej historyjce nie będzie zawarta informacja o wymaganiach niefunkcjonalnych, tzn. skupiamy się na tej funkcjonalności dla użytkownika, którą będziemy tworzyć. Nie ma informacji o wymaganiach niefunkcjonalnych. Taka historyjka użytkownika nie niesie też informacji o architekturze, o technologii. Ona jest tylko tym początkiem, tą inicjacją tych wszystkich dyskusji, które potem powstaną i tych decyzji, które zostaną podjęte i udokumentowane. Takie historyjki użytkownika nie dadzą też pełnego obrazu o tym, jak chcemy, żeby ten system wyglądał, szczególnie w projektach waterfall-owych, gdzie zakres powstanie na samym początku, zapisanie go tylko w takich zdaniach jak historyjki użytkownika może nie dawać pełnego obrazu.

Czy to źle, czy to dobrze? Przy zwinności nie ma z tym dużego problemu, ale jeżeli nasza organizacja działa w takim modelu to historyjki użytkownika się po prostu nie sprawdzą. Ostatnią rzeczą, do czego się nie nadadzą historyjki użytkownika to jest to, że one nie są stworzone do bycia nośnikiem jakiś formalnych porozumień, formalnej akceptacji, formalnych postanowień o kształcie systemu, to nie jest ten nośnik. Tutaj używamy pełnej dokumentacji, takiej, jaką mamy wypracowaną.

Historyjka użytkownika ma na celu zwiększyć zwinność, dostarczyć wartość, być tym początkiem, a wręcz obcięciem takiego wymagania ze wszystkiego, co jest nieesencjonalne, zostawia tylko tę esencję, czyli tę potrzebę użytkownika i ten cel, który on chce osiągnąć.

Czy to oznacza, że w historyjce użytkownika nie ma czegoś takiego jak kryteria akceptacji? Niekoniecznie, tzn. bardzo często te kryteria akceptacji są takimi dodatkowymi wskazówkami na temat tego, co jest dozwolone, a co nie jest dozwolone przy implementacji tej historyjki użytkownika. Tylko dobrze, jakby to zawrzeć w 5 punktach, a nie w kilku stronach dokumentacji. Po prostu kryteria akceptacji są dodatkiem do historyjki użytkownika, ale dobrze, gdyby były też esencjonalne, gdyby były tylko tą esencją, na której można się kupić, a skupienie daje nam zwinność, skupienie daje nam szybkość dostarczania.

Podsumowanie

Historyjka użytkownika jest punktem początkowym, który ma służyć do rozpoczęcia konwersacji pomiędzy użytkownikiem a kimś, kto będzie rozwijał system, kimś, kto będzie rozwijał oprogramowanie. Bardzo często na rynku historyjką użytkownika nazywane jest to, co de facto jest formalną dokumentacją, z całym kompletem dokumentów, z plikami, z tym formalnym procesem, w którym programista jest angażowany dopiero na koniec, kiedy taka historyjka zostanie zaakceptowana i do niego przekazana.

Żeby zwiększyć zwinność, należałoby wrócić do tego, co jest esencją historyjki użytkownika, czyli faktycznie postawić na interakcję i na współpracę z klientem końcowym, na odpuszczenie pewnej ilości kontroli, na rzecz tego, żeby dać większą wolność, większą możliwość bycia innowacyjnym, możliwość bycia kreatywnym i też szybkiej weryfikacji tego, czy to, co stworzyliśmy niesie realną wartość.

Historyjki użytkownika nie dadzą nam informacji o wymaganiach niefunkcjonalnych, nie będą niosły w sobie informacji o planowanej architekturze, nie będą też dobre do bycia takim nośnikiem formalnych ustaleń, ale one są inicjatorem konwersacji.

Dziękuję za Twoją uwagę i do następnego razu.