Epiki Agile: Definicja, przykłady i szablony

Podsumowanie: epik w Agile jest fragmentem prac, które można podzielić na konkretne zadania (tak zwane historyjki użytkowników) na podstawie potrzeb/wniosków klientów lub użytkowników końcowych. Epiki są ważną praktyką dla zespołów korzystających z metodyk Agile i DevOps.

Podczas wdrażania metodyk Agile i DevOps epik służy do zarządzania zadaniami. Jest to zdefiniowany fragment prac, który jest dzielony na konkretne zadania (zwane „historyjkami” lub „historyjkami użytkowników”) na podstawie potrzeb/wniosków klientów lub użytkowników końcowych. Szablon śledzenia zadań umożliwia zespołom efektywne organizowanie, ustalanie priorytetów i monitorowanie zadań.

Epiki są pomocnym sposobem na zorganizowanie prac i utworzenie hierarchii. Chodzi o to, aby rozbić prace na elementy do wykonania, tak aby można było faktycznie zrealizować duże projekty i nadal dostarczać wartość klientom na bieżąco. Epiki pomagają zespołom podzielić zadania oraz kontynuować prace na rzecz większego celu.

Utrzymanie zwinności podczas organizowania dużych zadań, takich jak epiki, nie jest łatwe. Dowiedz się, jak epiki są powiązane z prawidłowymi najlepszymi praktykami DevOps i Agile, stanowiąc niezbędną kompetencję bez względu na wielkość organizacji.

Epik to duża jednostka pracy, którą można podzielić na wiele mniejszych historyjek (stories). W systemie Jira bywają nazywane zgłoszeniami. Epiki często obejmują wiele zespołów, w wielu projektach, a nawet mogą być śledzone na wielu tablicach.

Na ukończenie epiku niemal zawsze składa się zbiór sprintów. Ponieważ zespół może dowiadywać się więcej na temat epików od programistów i poprzez opinie klientów, historyjki użytkowników są dodawane i usuwane w razie potrzeby. To jest klucz w przypadku epików Agile: zakres jest elastyczny, oparty na opiniach klientów i zespołu.

Załóżmy, że jest rok 2050 i pracujemy w firmie organizującej wycieczki kosmiczne. Mamy kilkanaście startów rocznie, więc pojedynczy start nie jest najpoważniejszym zadaniem w ciągu roku, ale wciąż jest daleki od rutyny i wymaga wielu osobogodzin. Ten rozmiar zadania jest odpowiedni do epiku.

Przykładowy epik „Start wycieczki kosmicznej w marcu 2050” zawiera historyjki dotyczące rutynowych elementów prac, a także historyjki mające na celu poprawę kluczowych aspektów startu statku, od kupowania biletów na wycieczki kosmiczne przez klientów po start samej rakiety. W związku z tym do realizacji epiku przyczyni się kilka zespołów, pracujących nad wieloma historyjkami.

Zespół pracujący nad oprogramowaniem do sprzedaży biletów na lot w marcu 2050 r. może zorganizować swój epik w następujących sposób:

Równocześnie zespoły odpowiadające za silniki rakietowe mogą dodać do tego samego epiku następujące historyjki:

Epik powinien dać zespołowi programistów wszystko, czego potrzebują, aby odnieść sukces. Z praktycznego punktu widzenia jest to najwyższy element w hierarchii ich prac. Jednak zrozumienie, jak epik odnosi się do innych struktur Agile, pozwala uzyskać ważny kontekst codziennych prac programistycznych.

• Plan rozwoju produktu określa, w jaki sposób produkt lub rozwiązanie będzie ewoluować z czasem.
• Temat to cel organizacji, który napędza tworzenie epików i inicjatyw.
• Plan rozwoju produktu jest wyrażany i wizualizowany jako zestaw inicjatyw na osi czasu.
• Podział inicjatyw na epiki pomaga dbać o zgodność codziennej pracy zespołu — wyrażonej w mniejszych historyjkach — z ogólnymi celami biznesowymi.

Zestaw ukończonych epików napędza konkretną inicjatywę, która pozwala na rozwój i ewolucję produktu wraz z wymaganiami rynku i klientów zgodnie z tematami organizacji.

W naszym przykładzie powyżej tematem byłoby zwiększenie liczby startów statków kosmicznych, plan rozwoju zmierzałby w kierunku zwiększenia liczby startów z 3 do 4 na kwartał, inicjatywy miałyby na celu obniżenie kosztów i zwiększenie sprzedaży biletów, a każdy epik przyczyniałby się do realizacji tych inicjatyw.

Podczas tworzenia nowego epiku rozważ inne narzędzia planowania i organizacji, które Twój zespół może już posiadać. Świetnym początkiem jest tworzenie epików wokół kwartalnych celów zespołu lub OKR-ów. Podczas tworzenia epików należy uwzględnić następujące kwestie:

• Raportowanie — twórz epiki w przypadku projektów, które będą chcieli śledzić menedżerowie i szefowie.
• Opowiadanie historii — użyj epików i tworzących ich historyjek do przedstawienia sposobu, w jaki doszliście do aktualnego stanu funkcji lub produktu.
• Kultura — kultura organizacyjna powinna determinować wielkość i szczegółowość epików.
• Czas — większość zespołów programistycznych opiera się na szacunkach, nie konkretnych terminach, ale warto zadbać, aby epiki trwały kilka tygodni. Nie za długo i nie za krótko.

Zobacz, jak działają epiki w systemie Jira.

Podział epiku na bardziej praktyczne historyjki pomaga w zrozumieniu projektu i utrzymaniu tempa, ale może to być trudne zadanie dla niewtajemniczonych. Nie ma jednego uniwersalnego rozwiązania, jeśli chodzi o tworzenie historyjek z epiku, ale jest wiele dobrych opcji do rozważenia:

• Rola lub persona użytkownika — stwórz unikalną historyjkę dla każdej persony użytkownika. „Szybsze logowanie dla nowych odwiedzających”, „szybsze logowanie dla powracających klientów” itp.
• Uporządkowane kroki — podziel proces i utwórz historyjkę na potrzeby każdego kroku.
• Kultura — zależnie od norm zespołowych historyjka może być krótkim zadaniem lub tygodniowym projektem.
• Czas — o ile nie istnieje inna uzgodniona konwencja, twórz historyjki, które można ukończyć w czasie jednego sprintu lub szybciej.

Nie ma uniwersalnej definicji, która wyznacza granicę między dużą historyjką a epikiem. Ogólnie rzecz biorąc, każdy zakres prac, którego wykonanie zespół szacuje na „tygodnie” (lub dłużej), a nie „godziny” lub „dni”, należy uznać za epik i podzielić na mniejsze historyjki.

Wykresy spalania mogą być wykorzystywane do wizualizacji epików i służyć do utrzymania motywacji zespołów oraz bieżącego informowania kierownictwa. Dobry wykres spalania epiku świadczy o zwinności organizacji.

Wykres spalania epiku pokazuje rzeczywistą i szacowaną ilość pracy do wykonania w sprincie lub epiku. Pozioma oś x na wykresie spalania pokazuje czas, a pionowa oś y pokazuje historyjki lub zgłoszenia.

Użyj wykresu spalania, aby monitorować łączną ilość pozostałej pracy do wykonania i prognozuj prawdopodobieństwo osiągnięcia celu sprintu. Dzięki śledzeniu pozostałej pracy w całej iteracji zespół może zarządzać swoimi postępem i odpowiednio reagować.

Monitorowanie wykresu spalania daje wgląd w postępy zespołu oraz pozwala zidentyfikować przeszkody. Widoczność tych punktów danych pozwala wszystkim być na bieżąco i ułatwia otwartą rozmowę na temat ewolucji produktu i prognoz ukończenia. Nie wspominając już o tym, że przejrzystość buduje zaufanie!

Dowiedz się, jak skonfigurować wykresy spalania w systemie Jira

Po opanowaniu sposobu tworzenia epików i historyjek możesz zoptymalizować procesy za pomocą automatyzacji. Oto trzy spośród najczęściej stosowanych reguł automatyzacji używanych w przypadku sprintów w systemie Jira.

1. Automatycznie dodaj trzy historyjki po utworzeniu epiku. Przejdź do reguły.
2. Automatycznie zamykaj historyjki, gdy epik zostanie oznaczony jako ukończony. Przejdź do reguły.
3. Zmień status epiku, gdy zmieni się status jednego z połączonych zgłoszeń. Przejdź do reguły.

Zapoznaj się z tymi regułami automatyzacji oraz setkami innych w bibliotece szablonów Jira Automation.

Przejdź do biblioteki

Epiki nie są bezwzględną podstawą programu Agile, ale praktycznymi czynnikami napędzającymi dla większości zespołów Agile i DevOps. Zrozumienie, gdzie pasują one do zdrowego programu Agile, pozwala określić kontekst prac, a podzielenie ich na historyjki umożliwia nadanie tempa pracom.