Nawet najprostsze rzeczy da się skomplikować, a przykładem tego są tzw. epiki (ang. epics), jakimi posługują się rozliczne Zespoły pracujące w metodach zwinnych, w tym i w Scrumie.

Czym są wspomniane epiki? Zobaczmy, jak definiuje je firma Atlasian, która na tej stronie umieszcza taki opis:

An agile epic is a body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers and end-users.

Wychodzi na to, że epik jest zbiorem rzeczy do zrobienia, który można – uwzględniając potrzeby lub oczekiwania klientów i użytkowników – podzielić na zadania, nazywane tu historyjkami użytkownika. Inaczej mówiąc, jest to duża rzecz do zrobienia, wymagająca przed realizacją dekompozycji na mniejsze kawałki. Brzmi sensownie?

Dla wielu organizacji i Zespołów w nich tak, bo dokładnie tak używają epików. Sądzę nawet, że ten opis powstał na podstawie obserwacji sposobu działania Zespołów korzystających z narzędzia budowanego przez Atlasian, czyli Jiry.

Typowa obsługa epików w wielu Zespołach

Jak to wygląda w praktyce? Pojawia się jakaś potrzeba dokonania zmiany w produkcie, która zostaje zapisana jako epik, bo jest duża i bardzo ogólnie zdefiniowana. Następnie ciężkim wysiłkiem chłopa i robotnika epik ten zostaje doprecyzowany, wyceniony, zaopatrzony w kryteria akceptacji, odpowiedzi na wszystkie pytania, niezbędne makiety, projekty, plany, analizy i diabli wiedzą co jeszcze, co ludzie uznają za potrzebne, zanim uznają, że już wszystko jest jasne.

Oczywiście ta pielęgnacja miewa różny zakres i intensywność i zależy od specyfiki Zespołów. Niektóre poświęcą na nią mnóstwo czasu i dążyć będą do ustalenia najdrobniejszych szczegółów, inne – moim skromnym zdaniem rozsądniejsze – ograniczą wysiłki pielęgnacyjne do niezbędnego minimum.

A że to epik, to konieczny jest jego podział na mniejsze części. Można to zrobić na mnóstwo sposobów, lepiej lub gorzej, ale nie będę w tym artykule wnikał w zasady dekompozycji i potencjalne błędy, jakie można przy tym popełnić. Przyjmijmy, że epik został jakoś podzielony, czyli jeden element na jakiejś liście rzeczy do zrobienia (np. w Backlogu Produktu) zastąpiony zostanie kilkoma mniejszymi, stanowiącymi efekt dekompozycji.

Co wtedy dzieje się z samym epikiem? W jakiejś formie musi przetrwać, bo przecież tylko on łączy szereg nowych małych elementów (tych, które Atlasian nazywa historyjkami użytkownika – jeszcze do tego wrócę) i nie bardzo można o nim zapomnieć. Można by oczywiście umieścić opis skopiowany z epika w każdym kawałku, który powstał w wyniku jego podziału, ale nie ułatwi to wynajdywania ich wszystkich, zwłaszcza jeśli lista rzeczy do zrobienia jest naprawdę długa. A może się taka stać, jeśli na początku tworzyło ją kilka epików, z których każdy poddany został dekompozycji na kilka lub kilkanaście małych elementów.

Każdy problem doczekuje się rozwiązania, więc i ten nie pozostał bez odpowiedzi ze strony dostawców oprogramowania takiego jak Jira. Oryginalny epik znika z listy, ale nie jest całkowicie kasowany, tylko staje się wygodnym filtrem, za pomocą którego można pogrupować i łatwo wyświetlić wszystkie elementy, jakie powstały po jego podzieleniu. Ba, można sprawdzić, ile z nich zostało już zrealizowanych, więc pojawia się też informacja o postępie prac. Czyż to nie piękne i użyteczne?

Podobne mechanizmy, choć opatrzone różnymi nazwami (np. feature zamiast epic), stosowane są właściwie we wszystkich alternatywach dla Jiry, na której przykładzie omawiam typowy sposób radzenia sobie z dużymi wymaganiami w wielu firmach.

Problemy, problemy…

Przeprowadźmy analizę konsekwencji posłużenia się opisanym powyżej sposobem pracy z epikami. Stwarza on kilka poważnych problemów, które mogą spowodować, że zastosowanie niektórych metod (np. Scruma) stanie się utrudnione lub nawet niemożliwe.

Wielowymiarowa lista

Posłużenie się mechanizmem grupowania elementów za pomocą epików powoduje, że lista rzeczy do zrobienia nie jest już jedna i jednowymiarowa. A dokładniej rzecz ujmując, jest taka wyłącznie formalnie, ponieważ do zarządzania jej elementami niezbędne zaczyna być korzystanie z filtrów, jakimi są epiki i to w znacznym stopniu poprzez widok, jaki one zapewniają, ustalana zaczyna być zawartość i kolejność elementów.

Oznacza to w praktyce, że osoba zarządzająca listą (np. Product Owner zarządzający Backlogiem Produktu w Scrumie), posługuje się dwoma różnymi widokami listy: jednym przy ustalaniu, co ma na tej liście się znaleźć i w jakiej kolejności, a drugim do prezentowania efektów podjętych decyzji. To zdecydowanie nie sprzyja przejrzystości i może prowadzić do błędów decyzyjnych.

Nieprzejrzysty stan elementów listy

Przejrzystość obniża też informacja o postępie prac nad poszczególnymi epikami. Tak, to nie pomyłka – obniża, zamiast ją podnosić. Bo o ile stan ten być może daje jakiś głębszy wgląd w to, co dzieje się z konkretnym epikiem, o tyle przy rozważaniu całej ich listy, do tego wymieszanej z mniejszymi rzeczami do zrobienia, które nie przynależą do żadnego epika, wprowadza zamieszanie.

Żeby zrozumieć, na czym ono polega, trzeba zastanowić się, jak działałaby lista, gdyby nigdy nie trafiały na nią rzeczy wymagające podziału (czyli nieszczęsne epiki). Otóż składałaby się ona wyłącznie z rzeczy, które oczekują na realizację. Inaczej mówiąc, jeśli coś znajdowałoby się na takiej liście, to znaczyłoby, że prace nad tym czymś jeszcze się nie rozpoczęły, ani tym bardziej nie zakończyły.

A teraz wróćmy do idei grupujących epików. Czy ich stan będzie zawsze równie jednoznaczny? Oczywiście, że nie. Sytuacja będzie jasna tylko wtedy, gdy żaden z elementów, na które epik został podzielony, nie został jeszcze podjęty do realizacji. Wtedy cały epik będzie oczekiwał na podjęcie prac nad nim.

Natomiast jeśli nad choćby jednym elementem pochodnym od epika zaczną się prace (czyli gdy zniknie on z listy rzeczy do zrobienia), to epik będący filtrem grupującym mniejsze kawałki, automatycznie też znajdzie się w realizacji.

Żeby nie było za łatwo, ten stan (np. „w realizacji”) będzie utrzymywał się nadal również w momencie, gdy połowa elementów, na jakie został podzielony, została już zrealizowana, a druga połowa wciąż oczekuje na podjęcie prac nad nimi. Mimo że aktualnie nikt nad epikiem nie pracuje, jego status będzie wskazywał, że realizacja jest w toku.

Praca ciągnąca się w nieskończoność

Sam spadek przejrzystości wynikający z potencjalnie mylących stanów epików to niejedyny problem. Ponieważ wiele z nich będzie wymagało podziału na sporą liczbę elementów, których realizacja będzie trwać przez długi czas. W przypadku posługiwania się przez Zespół metodami iteracyjnymi, takimi jak Scrum, może to doprowadzić do powolnego zacierania się granic tych iteracji, bo z punktu widzenia zarządzającego listą rzeczy do zrobienia (np. Product Ownera w Scrumie), ale też i całego Zespołu, ważniejszy może być postęp prac nad epikiem niż nad jego elementami składowymi. W skrajnym przypadku nikt nie będzie się przejmował, że w iteracji (Sprincie w Scrumie) niewiele udało się zrobić; grunt, żeby jakiś postęp w spalaniu epika nastąpił…

Koszmar aktualizacji

A kolejne problemy się mnożą. Ta dość typowa strategia pracy z epikami, jaką opisuję, skutkuje szybkim rozrostem listy rzeczy do zrobienia. Łatwo wyobrazić sobie, że początkowych dziesięć epików zostaje podzielonych na dziesięć mniejszych kawałków każdy i lista wydłuża się dziesięciokrotnie. Od pewnego momentu dla osoby, która tym zarządza, możliwość grupowania i filtrowania w kontekście epików zaczyna być niezbędna. Jestem przekonany, że Atlasian zaimplementował mechanizmy Jiry w taki, a nie inny sposób właśnie po to, by dostarczyć narzędzie, którego domagali się użytkownicy (managerowie produktu, kierownicy projektu, Product Ownerzy).

Natomiast pojawia się też problem z aktualizacjami zarówno epików, jak i małych elementów, które na nie się składają. Ze względu na rozproszenie informacji na przestrzeni całej listy, rośnie ryzyko, że modyfikacje, które trzeba wprowadzić np. ze względu na zmianę potrzeb interesariuszy, będą dokonywane zbyt wolno, niekonsekwentnie, niespójnie albo wręcz nie będą dokonywane wcale (bo wiązać się z tym będzie za dużo pracy).

A już niemal na pewno nie będzie łatwo podjąć decyzji o innym sposobie podziału epika po tym, jak początkowo został on poszatkowany na mniejsze kawałki. Przy dużej liczbie epików, podzielonych na sporą liczbę małych rzeczy do zrobienia, zadanie może okazać się naprawdę karkołomne. Zespół może pozostać przy pierwotnym podziale, nawet jeśli nie jest on najlepszy i wprowadzi zmiany tylko wtedy, jeśli naprawdę będzie musiał.

Kotwiczenie

Kotwiczeniem jest opisane powyżej trzymanie się sposobu podziału dużego epika na mniejsze kawałki, ale jest nim w istocie każdego trzymanie się jakiejś pierwotnej wizji, która może się zdezaktualizować i wymagać przedefiniowania wszystkiego, co się na niego składa. Im bardziej rozproszona jest informacja o tym, czego dotyczy epik, tym trudniej będzie ludziom dostrzec, że jakieś zmiany są konieczne. Nie chodzi nawet o brak ochoty do podejmowania wysiłku, ale o obiektywną trudność, jaką sprawi przetwarzanie informacji rozsianej w wielu różnych elementach jakiejś listy, wymiksowanych ze sobą.

Lepsza obsługa epików

Czy można to zrobić lepiej? Tak, ale konieczna jest zmiana podejścia nie tyle do sposobu pracy z epikami, ile przede wszystkim zdefiniowanie ich w inny sposób.

Epik, czyli np. historyjka użytkownika

Czym zatem powinny być epiki? Na początek nic się nie zmienia. To po prostu duża rzecz do zrobienia. Potrzeba, której zaspokojenie będzie wymagało sporo wysiłku. Problem, którego nie da się łatwo i szybko rozwiązać. Coś, nad czym trzeba się napracować, czego być może nie da się od razu dobrze zdefiniować.

Wróćmy na moment do definicji epika, którą zaczerpnąłem ze stron firmy Atlasian. Epik należy wedle niej dzielić na zadania, czyli historyjki użytkownika. To oczywista bzdura, bo user stories nie są formą zapisu zadań – to technika zbierania informacji o potrzebach i problemach użytkowników. Ten fragment świadczy o umiarkowanym zrozumieniu, czym historyjki użytkownika być powinny (niestety, podobne nieporozumienia są codziennością całej rzeszy Zespołów).

Drugą, mniej oczywistą bzdurą jest traktowanie epików i historyjek użytkownika jako różnych rzeczy. Te drugie powstają rzekomo na skutek podziału tych pierwszych. Tymczasem bardzo wiele prawdziwych historyjek użytkownika (czyli nie zadań, ale opisów potrzeb użytkowników) to coś dużego, z czym nie można sobie poradzić szybko i łatwo. One wszystkie są epikami. To nie rodzaj elementu na liście czyni niektóre z nich epikami, ale nakład pracy, jakiego wymagają.

Dekompozycja odłożona w czasie

Ponieważ epik jest czymś dużym, wymaga podziału na kilka elementów – to też się nie zmienia. Dyskusja na temat dekompozycji jest niezbędna, natomiast podział wcale nie musi nastąpić od razu po jej zakończeniu. Zaryzykowałbym wręcz twierdzenie, że nie powinien. Dzięki rozmowie na temat różnych sposobów podziału dużej rzeczy zaangażowani w dyskusję ludzie zyskują zwykle lepsze zrozumienie całości i jest to równie ważne, jeśli nie ważniejsze, niż ustalenie zasad dekompozycji.

Gdy już jasne się stanie, że trzeba rozpocząć realizację epika, zamiast zastępować go szeregiem nowych mniejszych elementów, wystarczy wyciągnąć z niego jeden – ten, od którego praca nad epikiem się zacznie. Całą resztę można zostawić w całości.

Ten mały wydzielony kawałek może być nową historyjką użytkownika, o ile sam epik nią był i o ile da się z opisanej w nim potrzeby wydzielić mniejszą potrzebę składową. Jeśli nie, tworzenie pseudohistoryjki na siłę, która tak naprawdę będzie zadaniem albo opisem rozwiązania, nie ma sensu. A nie każda potrzeba da się podzielić na mniejsze potrzeby. Napiszmy wtedy po prostu zadanie albo klasyczne wymaganie, albo cokolwiek innego, co spowoduje, że będzie jasne, co należy zrobić. I koniecznie zamieśćmy w tym kawałku referencję do epika, z którego został wyciągnięty – żeby było jasne, po co praca jest wykonywana.

W tym modelu obsługi epików nie znikają one z listy rzeczy do zrobienia ani nie są przenoszone do jakiejś równoległej listy. Są zjadane powoli i pozostają na liście dopóty, dopóki można coś dalej z nich wydzielać, albo do momentu, gdy ostatni kawałek stanie się na tyle mały, że podjęty zostanie do realizacji w całości.

Nie ma potrzeby wprowadzania grupowania lub filtrowania, bo epik albo wciąż jest w jednym kawałku, albo wydzielana jest z niego jedna mała rzecz, która już wkrótce będzie realizowana. Nie ma wtedy większego problemu ze znalezieniem obu części, bo też i lista rzeczy do zrobienia nie rozrasta się w tempie reprodukcji jurnych króliczków.

Gdy już jeden element wydzielony z epika zostanie zrealizowany, łatwo wrócić do pozostałego w jednym kawałku ciągu dalszego i zastanowić się, czy wymaga aktualizacji, czy plan dalszego podziału jest wciąż sensowny, co powinno być wydzielone w następnej kolejności itd. Może też okazać się, że ciąg dalszy jest zbędny i po prostu zostanie usunięty. Przykładowo, epik mógł opisywać duży problem, który pierwsze proste rozwiązanie usunęło na tyle skutecznie, że dalszy jego rozwój nie jest potrzebny. Mimo ukończenia prac tylko nad jednym niewielkim kawałkiem z przewidywanych kilku, cały epik może być potraktowany jako zrealizowany.

Większa przejrzystość

Ten sposób pracy z epikami podnosi przejrzystość listy rzeczy do zrobienia (np. Backlogu Produktu w Scrumie), bo pozostaje ona jednowymiarowa, tempo pojawiania się nowych elementów jest ograniczone, pozwala też jednoznacznie określić stan każdego z nich.

Zaraz, zaraz! Jak to jednoznacznie?! Przecież jeśli wydzielony zostanie z epika mały kawałek i zaczną się nad nim prace, to mimo iż reszta (czyli epik) pozostaje na liście, to będzie już de facto realizowana! Gdzie ta obiecana przejrzystość?!

Odpowiedź jest prosta: po wyciągnięciu z epika czegoś małego do zrobienia na początek, cała reszta, choć nie jest dalej dzielona, najczęściej zostanie od razu przedefiniowana, by odzwierciedlać to, co w niej pozostało. Z faktu, że wydzielona mała rzecz jest aktualnie realizowana, albo nawet, że prace nad nią się już zakończyły, nie wynika żadna zmiana stanu tego, co wciąż pozostało do wykonania i aktualnie wykonywane przecież nie jest.

Zresztą, gdyby oryginalnego epika nikt nie zmodyfikował po tej częściowej dekompozycji, praca odbywająca się nad małym wydzielonym elementem z definicji nie pozwoli na zaspokojenie potrzeby ani rozwiązanie problemu opisanego tym epikiem. Ten ciąg dalszy (czyli oryginalny epik) istnieje wciąż na liście właśnie dlatego, że coś wciąż pozostaje do zrobienia. Inaczej mówiąc, gdy bieżące prace się zakończą, epik (to, co w nim się aktualnie mieści) wciąż będzie oczekiwać na realizację. Nie ma żadnego powodu, by w momencie rozpoczęcia prac nad wydzielonym małym kawałkiem zmieniać stan samego epika (np. na „w realizacji”) tylko po to, by po ich zakończeniu powracać do stanu początkowego (np. „do zrobienia”).

Prognozowanie mimo braku dekompozycji

Jednym z powodów, dla których dekomponowane są epiki, jest potrzeba sporządzenia realistycznych i w miarę dokładnych prognoz terminu zakończenia prac nad nimi. Wydaje się, że proponowany przeze mnie sposób traktowania epików, uczyni prognozy mało wiarygodnymi, a być może uniemożliwi ich przygotowanie. Bo jakże wyszacować ogromny epik w całości? Skali może na niego zabraknąć, ot co!

O tym napiszę w jednym z kolejnych artykułów. Teraz podpowiem jedynie, że dekompozycja opiera się zawsze na różnych założeniach, które często są błędne. Podział dokonywany już na początku ma szansę być mocno nietrafiony, zwłaszcza w porównaniu do dekompozycji następującej stopniowo, w miarę jak rośnie zrozumienie tego, co rzeczywiście kryje się w epiku. Wiara, że dzięki wczesnej dekompozycji szybciej uda się „dobrze wycenić” ilość pracy nad epikami i sporządzić „dobre prognozy”, jest sama oparta o nieprawdziwe założenie, że nastąpi „właściwy podział”. Jeśli zaś tak się nie stanie, zarówno wyceny jak prognozy mogą okazać się mało wiarygodne.

Może zresztą należałoby najpierw sporządzić prognozę tego, na ile kawałków epik trzeba będzie podzielić, zanim zostanie w pełni zrealizowany?