Epic to taki twór, o którym słyszało co najmniej tyle samo osób co o User Story. Ale gdy zapytamy „Czym właściwie jest ten Epic?” odpowiedzi będą jeszcze bardziej po pokrętne niż w przypadku US-ów. Czas rozwiązać tę kwestię.
Czym jest Epic/Epik?
Epic to bardzo duża potrzeba biznesowa lub wymaganie, które jest zbyt skomplikowane aby móc jest zrealizować „na raz”. W szczególności, jest zbyt duże, żeby być zrealizowane od A do Z w jednym Sprincie lub iteracji.
Dwie najpopularniejsze definicje Epika to właśnie „User Story, którego realizacja zajmie więcej niż jeden Sprint” bądź równe popularne „kontener grupujący mniejsze wymagania”. Śmiem twierdzić, że obie te definicje są prawdziwe.
Jeżeli mamy jakąś skomplikowaną rzecz do zrobienia, to raczej nie ma szansy, żeby zmieściła się ona w jednej iteracji/jednym Sprincie. A skoro tak, to zgodnie z wszystkimi z innymi pomysłami dotyczącymi pracy na wymaganiach, będziemy chcieli je podzielić na mniejsze. Oznacza to, że tenże Epic sam w sobie jest „dużym wymaganiem”, ale jednocześnie staje się także kontenerem na te wszystkie wymagania, które z niego wydzieliliśmy. Mówiąc bardziej obrazowo: Epik jest wymaganiem i zawiera inne (bardziej szczegółowe) wymagania.
Epik w praktyce
W naszej zwinnej pracy najczęściej mamy do czynienia z podejściem top-down, gdzie od klientów, interesariuszy, „biznesu” otrzymujemy bardzo ogólne i wysokopoziomowe wymagania. Często zahaczają one „potrzebę biznesową”, a czasami bliżej im do marzeń. Przyjmujemy te wymagania (Epiki) i dekomponujemy na funkcjonalności i rzeczy do zrobienia. Te bardzo często zapisujemy już w formacie User Story.
Idąc dalej z najbardziej wyświechtanym przykładem z wprowadzeniem płatności BLIKIEM w naszym biznesie, to jeśli nasz Epic dotyczy właśnie tego, to pewnie nazywa się „Płatności BLIK”. Żeby jednak go zrealizować, będziemy musieli wprowadzić wiele różnych modyfikacji do naszego procesu – zintegrować się z systemem płatności, obsłużyć błędy, obsłużyć, zwroty i tak dalej. Te „mniejsze” wymagania zwykle będziemy zapisywać jako User Stories.
Idąc dalej, sama funkcjonalność zwrotów zwykle też jest zbyt skomplikowana, żeby zrealizować ją w jednym Sprincie. I tutaj wkracza dzielenie wymagań na jeszcze mniejsze. Zajmujemy się tym między innymi na naszym warsztacie dotyczącym wymagań i User Stories.
Wracając jednak do naszych płatności BLIKIEM – Epik o tej nazwie pewnie będzie widniało w naszym systemie do zarządzania wymaganiami. Gdy go otworzymy, zobaczymy nazwę, opis, kryteria akceptacji oraz listę User Stories, które go realizują. Bo pracując zwinnie, my nie implementujemy Epica, ale poszczególne US-y, który go realizują.
Epic w SAFe
Scrum sam sobie nie ma nic wspólnego z Epikami, ani nawet z User Stories. Ten framework nie zawiera szczegółów dotyczących konkretnych technik i narzędzi. Jednak jakoś się przyjęło, że większość ludzi pracujących w Scrumie jednocześnie pała uwielbieniem do User Stories. W sytuacji w których mnoży nam się US-ów i potrzebujemy je zgrupować w coś większego, możemy sięgnąć po Epic. Podobnie gdy mamy do czynienia z dekompozycją top-down (od ogółu do szczegółu), wtedy sięgamy wtedy po Epiki.
SAFe, abstrahując od jego zwinności, podchodzi do tematu zupełnie inaczej. Epic w SAFe to duża inicjatywa i przedsięwzięcie, które niesie ze sobą jakąś wartość, propozycję biznesową, określone MVP, budżet i wiele innych rzeczy. Jest elementem Portfolio i jest zarządzany przez dedykowaną grupę osób. Lekko naciągając, można powiedzieć, że jest to swego rodzaju inicjatywa. Ale żeby nie było tak łatwo, istnieją też Epiki na poziomie poszczególnych ART, które co do zasady bliższe są Epikom opisywanym w tym artykule.
Należy pamiętać, że poza SAFe, w większości przypadków mamy do czynienia z dwoma poziomami wymagań. I zwykle są to bardzo ogólne, duże wymagania (Epic), które zawierające pod sobą wymagania drugiego poziomu (User Story). SAFe dodaje do tego jeszcze twory pośrednie jak Capabilities i Features. W uproszczeniu, są to odpowiednio możliwości naszego produktu czy też systemu oraz poszczególne funkcjonalności. Niektórzy też podążają za tą strukturą i działają w modelu Epic – Feature – User Story.
Rozmiar Epika
Wróćmy jednak do naszych bardziej typowych zastosowań, gdzie mamy do czynienia z jednym bądź kilkoma zespołami, pracującymi nad rozwojem jednego produktu. Wtedy Epiki nie są aż tak skomplikowane.
Epic powinien być przede wszystkim „zrabialny”, czyli taki o którym możemy w końcu powiedzieć, że go skończyliśmy. To znaczy, że lepiej jest mieć więcej Epików niż mniej. Tu można zaobserwować dwie tendencje. Niektóre zespoły utożsamiają Epic z funkcjonalnością (Feature) i na przykład jednym Epikiem jest „płatność kartami kredytowymi”, a innym „Płatność BLIKiem”. Z kolei inne zespoły preferują, gdy Epic jest większy, obrazujący konkretny moduł albo nawet obszar. W takim przypadku będziemy widzieć Epiki typu „płatność online”, „zwroty”, „system rabatowy”.
Nie ma dobrej odpowiedzi na to, jakiej wielkości powinny być poszczególne Epiki. Dobrze wiemy, że odnoszenie sukcesów wpływa pozytywnie zarówno na zespół, jak i na tempo prowadzonych prac. Jako członek zespołu, nie chciałbym zajmować się jednym Epikiem dłużej niż przez kilka miesięcy.
I tu od razu ostrzeżenie, gorąco odradzam konstrukcje typu Epic „utrzymaniowy”, „worek na wymagania”, „zbiór błędów do poprawy”. Utrzymanie systemu czy poprawa błędów produkcyjnych to są działania ciągłe. Zgodnie z koncepcją Epika, musimy potrafić go skończyć, a zwykle rzeczy utrzymaniowe, poprawy błędów, itd. nie kończą się nigdy.
Jak pisać Epiki?
Jeżeli potrzebujesz więcej informacji o tym, w jaki sposób zapisywać Epiki zaproszę Cię w trzy miejsca. Po pierwsze, mamy tekst pod tytułem „Format zapisu Epika„, gdzie wyjaśniamy kwestię kryteriów akceptacji, sposobu zapisu, itp. Po drugie, zapraszam na naszą listę mailingową, gdzie rozsyłamy porady na różne tematy – w tym dotyczące wymagań, Epików, itd.
Wreszcie, serdecznie zapraszam na nasze szkolenia i warsztaty, w szczególności na bardzo praktyczny warsztat dotyczące Wymagań i User Stories. Dostępne jest ono także w formule otwartej, weekendowej – bez brania urlopu, ale też bez tracenia całego weekendu. Naprawdę warto!
