Format zapisu Epika

Szumne hasła na sztandarach – “październik miesiącem wymagań i User Stories”, a tutaj tekst o tych nieszczęsnych Epikach. Albo i “szczęsnych”, zależy kogo spytać. Skoro tu jesteśmy, to odpowiedzmy na pytanie, “W jakim formacie zapisywać Epiki?”

 

Epiki i User Stories

Nie da się powiedzieć, czym jest Epic, nie mówiąc czym jest User Story. US-y to specyficzny sposób zapisu wymagań lub potrzeb biznesowych. To stwierdzenie jest ważne, bo wyraźnie mówi nam, że nie powinniśmy podchodzić do tego tak samo, jak do klasycznie rozumianych zadań, które rozdzielamy w zespole. Nie może być tak, że zmieniamy typ issue w Jira z “Task” na “Story” i już. Nawet jeśli dostosujemy format zapisu, to nie da nam to za wiele.

W tekście “Wymagania, a nie zadania” szczegółowo poruszyliśmy ten problem. Podkreślmy więc jeszcze raz: zarówno Epiki, jak i User Stories to sposób zapisu potrzeb biznesowych bądź wymagań. Jak więc wygląda?

Format User Stories ma wiele wydań, ale w każdym z nich ma nazwę, opis w postaci słynnego “Jako… Chcę… Aby…” oraz listę kryteriów akceptacji. Nazwa daje nam możliwość łatwego odwoływania się do US-a. Opis zwraca nam uwagę na potrzebę i powód danego wymagania oraz wskazuje dla kogo coś robimy. Kryteria akceptacji to lista, która mówi nam o szczegółowych warunkach, jakie sposób realizacji wymagania powinien spełnić, żebyśmy byli usatysfakcjonowani. W teorii nie jest to więc nic skomplikowanego. A jednak…

Poza wspomnianą już”zadaniowością”, do najczęstszych błędów nagminnie popełnianych przy pisaniu User Stories należą: pomijanie korzyści (“aby”) oraz nieprecyzyjnie określeni lub wręcz nieludzcy aktorzy (“jako”). I oba z nich przekładają się na problemy z Epikami.

 

Format zapisu Epika

Co User Story ma wspólnego z Epikiem? Zależy kogo zapytać. Niektóre podejścia mówią, że Epik jest słowno-muzycznym zapisem myśli przewodniej, bardziej wizją niż konkretną potrzebą bądź wymaganiem. Inni powiedzą, że “to takie User Story, które nie mieści się w Sprincie”. Jeszcze inni powiedzą, że to definicja potrzeby biznesowej stawiająca jakąś hipotezę wraz z listą oczekiwanych korzyści.

Dalsza część tego tekstu to moje osobiste przekonanie o tym, czym jest Epik i jak powinien być zapisywany. Epik to jak najbardziej pewna grupa spójnych funkcjonalności, duża funkcjonalność bądź duże wymaganie, które dekomponujemy na zrabialne w jednej iteracji wymagania – User Stories. Epik jest więc zarówno “dużym User Story”, grupującym pewne wymagania, jak i potrzebą biznesową samą w sobie.

A skoro tak, to Epik powinniśmy zapisywać dokładnie w tym samym formacie. Nazwa + “Jako… Chcę… Aby…” + kryteria akceptacji. Jedyną różnicą będzie “Jako…”, gdzie raczej będziemy patrzeć z punktu widzenia klienta, niż użytkownika. Przegadaliśmy o tym z Łukaszem prawie cztery minuty jednego z naszych filmów.

Epik jako potrzeba opisuje “historyjkę” z perspektywy zamawiającego, płacącego bądź po prostu – klienta. User Stories dla odmiany prawie zawsze dotyczą użytkowników i beneficjentów naszego rozwiązania. Ot i różnica. Ale zasadnicza. Nie próbujmy opisywać Epików z punktu widzenia użytkownika końcowego, bo zwykle nam się to po prostu nie uda.

Jeżeli miałbym polecić rozszerzenie formatu Epika o jakieś dodatkowe elementy w porównaniu do US-ów, to byłyby to daty (początku i końca) oraz oczekiwane rezultaty biznesowe (mierniki). Te pierwsze, czysto informacyjnie, pomogą nam w ułożeniu Roadmapy. Z kolei oczekiwane rezultaty biznesowe bądź mierniki pozwolą nam sprawdzić, czy zrealizowanie danego Epika faktycznie przyniosło spodziewane korzyści.

Co prawda zmusi nas to do zastanowienia się, po co w ogóle chcemy zrealizować dany Epik i jak chcemy potem pokazać sukces, ale… to chyba dobrze?

 

Problemy z Epikami

Wróćmy więc do naszych problemów z zapisem Epika. Pierwszy z nich to niewłaściwie określone źródło wymagania. “Jako bank, chcę…”, “Jako dział marketingu, chcę…” – to bzdury. I to jeszcze bardziej szkodliwe niż słynne “Jako baza danych…”

Bank nic nie chce. Dział marketingu też nie. Ani jedno, ani drugie nie ma potrzeb. Potrzeby mają ludzie i jeżeli chcemy używać formatu User Story, to pamiętajmy, że zawsze historyjka dotyczy konkretnej osoby. Czasami ta osoba będzie wymieniona ze stanowiska bądź roli, a czasami będzie to Persona. Ale nigdy nie będzie to bezosobowa organizacja czy firma.

Zmuśmy się do zadania pytania “Komu na tym zależy?”, bądź alternatywnie “Komu będzie przeszkadzało, że tego nie zrobimy?” Po pierwsze, dostarczy to nam nowych i niewypowiedzianych wymagań, które możemy np. wpisać w kryteria akceptacji. Po drugie, pozwoli nam to kierować pytania i wątpliwości do właściwych osób. Nie wspominając już o tym, że patrząc z perspektywy konkretnej osoby (nawet jeśli to będzie np. dyrektor działu bezpieczeństwa) łatwiej nam będzie identyfikować korzyści.

Zastanówmy się więc solidnie, po co w ogóle mamy realizować dany Epik. Jakie mogą być korzyści? Jedna rzecz to oczywiście uzasadnienie w postaci “Aby…”. Zwróćmy szczególną uwagę, żeby nie powtarzać dokładnie tego samego co wpisaliśmy w “chcę…” Tu też z pomocą przyjdą nam oczekiwane rezultaty biznesowe bądź mierniki. Zastanówmy się, jak możemy udowodnić, że “coś” jest lepiej i następnie wpiszmy to jako nasze uzasadnienie.

Tylko tyle, i aż tyle. Zapisanie Epika w formacie User Story Plus, czyli opisanie go z perspektywy zamawiającego i dodanie mierników sukcesu bądź spodziewanych korzyści spowoduje, że wszyscy lepiej zrozumiemy po co coś robimy. A jeśli przeprowadzimy te ćwiczenie w gronie kluczowych interesariuszy, to możecie mocno się zdziwić, jak będą wyglądały ustalenia kryteriów akceptacji i mierników. I dobrze, lepiej to zrobić zanim zabierzemy się do pracy…

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: