Zaczęło się od próby opisania czym jest Epic. Ale dziś postawię się także w roli profesorów Bralczyka czy Miodka. I choć moja wiedza w zakresie niuansów języka polskiego w porównaniu z wymienionymi powyżej jest wręcz śmieszna, to zostałem poproszony o próbę zmierzenia się z tematem. #białko żadnej pracy się nie boi…
What is Epic, my dear?
Są takie terminy, którymi posługujemy się codziennie. Zanim ruszymy dalej, wypadałoby je wyjaśnić i uspójnić słownictwo. W kontekście agile’a największe zamieszanie zawsze powoduje metodologia, metodyka i metoda. To jednak kwestia naszej rodzimej semantyki. Przecież środowisko IT jest bardzo anglojęzyczne.
W naszym życiu codziennym też korzystamy z wielu zapożyczonych z angielskiego słów, jak np. taxi czy xero. Tak samo na projektach prowadzonych Scrumem opieramy się na Przewodniku po Scrum (ang. Scrum Guide). A ten, jak wiadomo naszpikowany jest wyrazami zapożyczonymi z języka angielskiego.
Wystarczy przywołać chociażby Product Backlog Refinement przetłumaczony jako Doskonalenie Backlogu Produktu, czy Product Backlog przetłumaczony na… Backlog Produktu. Dlaczego nie przetłumaczono słowa Backlog? Świetne pytanie, są przecież polskie odpowiedniki tego słowa…
User Story, Epic i inne zapożyczenia
Nie o słownictwo w Scrum Guide chodzi. Polskie brzmienie tego dokumentu zostało zaproponowane w tłumaczeniu Tomka Włodarka. Wszystkie definicje zostały więc w jakiś sposób usystematyzowane. Mamy jakiś punkt odniesienia, do którego jesteśmy w stanie sięgnąć, gdy używamy „fachowej” terminologii.
Inaczej rzecz ma się z zapożyczeniami, których w Przewodniku po Scrum nie znajdziemy. Przykładami takich słów są User Story czy Epic, które są odmieniane w każdej możliwej postaci. Przyznać należy, że czasem odmieniane są w sposób dziwny czy wręcz zabawny. O US-ach już pisaliśmy, czas więc na zmierzenie się z ich większym bratem.
Epic (ang. Epic)
Zacznijmy od definicji samego Epica, bo na naszym #białkowym blogu jeszcze się ona nie pojawiła. W ślad za uwielbianym przez jednych i znienawidzonym przez niektórych Atlassianem:
„Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories)” – Atlassian
Jeśli zaś należymy do grona ludzi, którzy na Atlassiana reagują alergicznie, to możemy poszukać definicji otoczeniu bardziej scrumowym:
„Epics resemble themes in the sense that they are made up of multiple stories. They may also resemble stories in the sense that, at first, many appear to simply be a „big story.” As opposed to themes, however, these stories often comprise a complete work flow for a user” – Scrum Alliance
Epic jest więc zbiorem User Story, które agreguje je do jednej, wspólnej „funkcjonalności”. Oznacza to, że wiele User Stories składa się na jeden byt o nazwie Epic. Epic jest więc w tej hierarchii nadrzędny.
Możemy go wykorzystać do „sprzedania” funkcjonalności menadżerom wyższego szczebla, których nie interesuje lista User Story wchodzących w jego skład. Możemy również wskazać go jako cel np. wydania czy fazy (ang. Release Goal), za którym zespoły deweloperskie powinny „pójść jak w ogień”. Epic posłużyć nam może też jako miernik stanu zaawansowania dewelopmentu – wykorzystując go nie musimy przechodzić po wszystkich wymaganiach znajdujących się w backlogu.
Epic Story czyli epicka historia
Skąd w ogóle powstała potrzeba takiego bytu jak Epic? Jeżeli mamy do czynienia ze zwinnym podejściem do pracy, to trudno podejrzewać, że popularność zyskało coś, co nie jest przydatne. Odpowiedź zawiera się w pytaniu, a konkretniej w iteracyjnym wytwarzaniu oprogramowania.
Ponieważ prace realizujemy małymi etapami, a na duży kawałek naszego systemu składać się będą dziesiątki lub nawet setki różnych User Story, to potrzebujemy w jakiś sposób wiedzieć, kiedy gotowa jest „całość”.
Na tę „całość” musimy spojrzeć oczami użytkownika końcowego. Już po pierwszym Sprincie otrzyma on do swoich rąk Minimum Viable Product. To wystarczy mu do pracy i zgłaszania kolejnych usprawnień, ale zapewne interesowało nas też będzie kiedy dany fragment systemu będzie „wystarczająco gotowy”, żeby zabrać się za inne.
Co wcale nie oznacza, że w przyszłości znów do niego nie wrócimy.
Jeden epic, dwa… epiki?
Przyjrzyjmy się sposobowi, w jaki Epic jest używany w języku polskim. Nie mamy problemu z odmianą tego terminu w liczbie pojedynczej, jest to najprostsza forma – po prostu Epic. Zdecydowanie większe trudności sprawia nam użycie tego słowa w liczbie mnogiej. Pojawiają się wtedy twory takie jak Epici, Epicy czy inne trudne to zrozumienia i wymówienia formy tego słowa.
Na przeciwległym biegunie leży User Story, z którym nie ma problemu zarówno jeśli chodzi o odmianę, jak i tłumaczenie. To po prostu historyjka użytkownika. Oczywiście, gdy pierwszy raz usłyszałem ten termin, nie mając jeszcze większego pojęcia o Scrum i Agile zinterpretowałem go błędnie, wydaje się jednak, że trafnie oddaje on swoje znaczenie.
Czy jest sens odmieniania go w języku polskim? Czy zapisanie w liczbie mnogiej „User Storiesów” czy w inny spolszczony sposób daje nam jakąś wartość dodaną? Nie. Nie ma sensu kaleczyć języka, powodując zamieszanie i problemy ze zrozumieniem, zapisaniem czy wymową.
Najlepsze praktyki (ang. best practices)
Najlepszym rozwiązaniem będzie stosowanie tak wielu polskich słów, jak to jest tylko możliwe. W dzisiejszym, potocznym języku mamy już wystarczająco dużo zapożyczeń z języka angielskiego. Doskonałymi przykładami są czelendże, kej-pi-aje czy inne „tworki” wkradające się do korporacyjnej nowomowy.
Są jednak słowa, które trudno przetłumaczyć jasno i zrozumiale na język polski, jak np. Epic. Inne zaś, są już głęboko zakorzenione w swojej angielskiej postaci, jak np. Scrum Master. Używajmy więc tych angielskich nazw, jednak nie twórzmy potworków w wyniku ich polskiej odmiany. Tak będzie higieniczniej – dla całego naszego otoczenia.
Jeżeli zaś chodzi o przydatność tytułowego Epica, to zależy ona od skali i samoorganizacji naszego projektu. W niektórych przypadkach pozwoli on na lepsze zarządzanie zakresem prac i łatwiejszą optymalizację dostarczanej wartości. W innych zaś będzie po prostu zbędny.
Jak zwykle wybór zależy od nas samych.
Epic, User Story i zarządzanie wymaganiami to główny, ale nie jedyny, temat naszego szkolenia Wymagania w projektach agile.
