Epic: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
(LinkTitles.)
m (cleanup bibliografii i rotten links)
 
(Nie pokazano 20 wersji utworzonych przez 2 użytkowników)
Linia 1: Linia 1:
{{infobox4
'''Agile''' epic jest ważnym elementem dla zespołów typu agile oraz DevOps, z uwagi na możliwość wykorzystania go do zarządzania zadaniami. Epic to zbiór pracy podzielony na konkretne zadania nazwane '''stories''' lub '''user stories''' i tworzony na podstawie potrzeb klientów lub użytkowników.
|list1=
<ul>
<li>[[Test driven development]]</li>
<li>[[Backlog produktu]]</li>
<li>[[Feature-Driven Development]]</li>
<li>[[Metodyka Extreme Programming]]</li>
<li>[[Testowanie w projekcie]]</li>
<li>[[Scrum of scrums]]</li>
<li>[[Redundancja]]</li>
<li>[[Manifest Agile]]</li>
<li>[[Programowanie strukturalne]]</li>
</ul>
}}


Kreowanie epica to sposób doskonalenia procesu realizacji pracy. Epic pomaga pracownikom dokończyć pracę oraz przerwać ją w odpowiednim momencie. Przyczynia się to do uzyskania możliwości kontynuacji pracy w celu osiągnięcia większego celu. Tworzenie epica nie należy do prostych zadań, istotne jest utrzymanie sprawności i opanowanie odpowiednich umiejętności pozwalających na jego kreację.


==TL;DR==
Agile epic jest ważnym narzędziem zarządzania zadaniami w metodyce agile i DevOps. Epics są zbiorem pracy podzielonym na konkretne zadania, tworzone na podstawie potrzeb klientów/użytkowników. Praca z epics opiera się na mapie drogi produktu i inicjatywach. Tworzenie epics wymaga utrzymania sprawności i opanowania odpowiednich umiejętności. Epics można zwizualizować za pomocą wykresów spalania.


'''Epic''' w '''Metodyce [[Scrum]]''' można zdefiniować jako dużą część pracy, mającą jeden wspólny cel.
==Teoria==
Może to być [[funkcja]], żądanie klienta lub wymagania biznesowe. Mówi zwięźle o ostatecznym wyniku potrzeb użytkowników. Na jego podstawie łatwiej jest planować strategię długofalową, czyli '''release'''. Epic nie powinien zawierać wszystkich szczegółów, nad którymi [[zespół]] musi pracować, te szczegóły są zdefiniowane w '''historyjkach użytkowników''' ([[user stories]]). Epic zazwyczaj wymaga więcej niż jednego '''sprintu''' i może się składać nawet z kilkunastu historyjek użytkowników (user stories).  
Epics tworzone są często przez wiele zespołów i są obecne w różnych projektach czy pracach. Epics są zwykle dostarczane przez serię sprintów. Dzieję się to wówczas, gdy zespoły informowane są o szczegółach epica, o prośbach, opiniach i potrzebach klientów/użytkowników. Poszczególne elementy mogą być elastycznie dodawane lub usuwane w odpowiedzi na zapotrzebowanie.


==Czym jest epic (epic story) w Metodyce Agile?==
Praca zespołów opiera się na zrozumieniu związku epica oraz innych struktur agile, tj.:
* '''Mapa drogowa produktu''' - plan określający działanie oraz kwestie związane z ewoluowaniem rozwiązania w czasie; wizualizowana jest za pomocą inicjatyw umieszczonych na osi czasu.
* '''Temat''' - cel organizacji napędzający kreowanie epica i innych inicjatyw.
* '''Inicjatywy''' - dzielone są na epics (epiki), które pomagają w utrzymaniu pracy zespołu; która z kolei wyrażona zostaje w mniejszych ‘’stories’’ i połączona jest z celami biznesowymi.
Zbiór zakończonych epics tworzy konkretną inicjatywę, która przyczynia się do rozwoju i ewoluowania produktu oraz sprostania wymaganiom stawianym przez rynek oraz użytkowników.
Rysunek 1 obrazuje epic w metodyce Agile.
[[Plik:EPIC.png|300px|right|thumb|Rys. 1 Epic w metodyce Agile]].


Podstawową jednostką pracy zdefiniowaną w '''Scrumie''' jest historyjka użytkownika (user story). Jednak bardzo często ta sama historyjka użytkownika (user story) rozszerza się tak bardzo, że nie mieści się ani w ciągu tygodnia, ani w czasie sprintu. W takim wypadku taką historyjkę użytkownika (user story) warto uznać się za Epica i zacząć ją dzielić na mniejsze historyjki użytkowników (user stories). W ten sposób zespoły '''Agile''' uzyskują mniejsze, ale konkretne wyniki w pojedynczym sprincie (Rys. 1).  
<google>n</google>
<google>t</google>
 
Do wizualnej prezentacji epica mogą być wykorzystywane '''Wykresy Spalania''' ([[Burndown]] charts), dzięki którym '''[[zespół deweloperski]]''' jest zmotywowany, a '''[[interesariusze]]''' poinformowane. Pokazuje wyraźnie, jaki postęp został osiągnięty przez zespół, a także w którym momencie [[praca]] została dodana lub usunięta przez '''właściciela produktu''' (product ownera).
==Przykład epica==
[[Plik:EPIC.png|300px|right|thumb|Rys. 1 Epic w metodyce Agile]].
Zdarza się, że ‘’story’’ jest zbyt obszerna, wówczas zostaje określona mianem epica i zostaje podzielona na mniejsze ‘’stories’’. Przykładem epica jest stwierdzenie: ‘’Użytkownik szuka pracy’’, które należy podzielić na przykładowe ‘’stories’’:
# Użytkownik może wyszukiwać oferty na przykład według lokalizacji, wysokości wynagrodzenia czy rodzaju firmy.
# Użytkownik może przeglądać informacje o wszystkich kolejnych zadaniach odpowiadających poszczególnym elementom wyszukiwania.
# Użytkownik może wyświetlić szczegółowe dane oraz informacje o przedsiębiorstwie, które opublikowało dane stanowisko<ref>M. Cohn, User Stories Applied for Agile Software Development, Addison-Wesley, 2009, s. 6</ref>
 
==Tworzenie agile epic==
Tworząc epic należy zwrócić uwagę na takie kwestie jak<ref>Atlassian - Epics</ref>:
* Raportowanie - istotne jest tworzenie epics w projektach, które menedżerowie będą w stanie kontrolować.
* Opowiadanie ‘’stories’’ - używanie w spójny sposób epica i ‘’story’’, co pozwala na określenie dotarcia do obecnego stanu produktu.
* Kultura organizacyjna - w tym kontekście musi dyktować wielkość oraz stopień szczegółowości epica.
* Czas - należy zwrócić uwagę na to jak długo zajmie realizacja epica. Okresu musi być dostosowany do indywidualnych wymagań każdego epica.


"'''Podstawowy [[cykl]] życia epica:'''
W celu skutecznego zrealizowania zadania, warto podzielić epic na mniejsze ‘’stories’’, gdyż to pomaga w utrzymaniu właściwego tempa oraz w całościowym zrozumieniu projektu. Opcjami, które warto rozważyć podczas tworzenia epica jest stworzenie unikatowego ‘’story’’ dla wszystkich potrzeb użytkownika. Następnie można podzielić proces na uporządkowane etapy i tworzyć mniejsze ‘’stories’’ dla każdego etapu.
* [[product owner]] definiuje user story,
* zespół stwierdza że user story jest [[zbyt]] duże, by je wyestymować realnie na jeden [[sprint]],
* product owner zmienia user story na epika - często pomaga mu w tym [[scrum master]],
* tworzone są mniejsze user story w zakresie odpowiadającym całemu epikowi,
* wszystkie user stories przechodzą swój cykl zycia,
* epic uznaje się za wykonany albo alternatywą jest usunięcie go po rozbiciu na mniejsze user stories " <ref>A. F. Kędziora, (2011), [[Metodyka]] scrum w małych i średnich projektach informatycznych, Poznań, s. 18.
</ref>.


'''Przykładowym Epiciem''' (epic story) może być: [[użytkownik]] chce mieć możliwość zarządzania reklamami pojawiającymi się w serwisie, aby uzyskiwać [[przychody]] od reklamodawców. Rozwiązaniem może być, na przykład, stworzenie systemu CMS. Takie wymaganie jest możliwe do wyobrażenia sobie przez '''[[zespół projektowy]]''' (team), czy '''właściciela produktu''' (product ownera), jednak samo w sobie może okazać się zbyt duże na jeden '''sprint''' i powinno być podzielone na zadania mniejsze. W trakcie podziału zadań wyłaniają się dokładniejsze specyfikacje poszczególnych ich części wynikowych oraz może się okazać, że [[wizja]], która była opisana na początku, zostaje wdrożona tylko w pewnym stopniu a inne elementy początkowo nieprzewidziane są dokładane w ich miejsce. Nie jest to sytuacja nadzwyczajna lub niebezpieczna.  
Nie istnieje uniwersalna definicja oddzielająca obszerną ‘’story’’ od epica. ‘’Stories’’ powinny być realizowane w ciągu godzin lub dni; epics natomiast powinny zostać zrealizowane w ciągu tygodni, w ramach podziału na krótsze ‘’stories’’.
Epics są podstawą działania związanego z programem agile; rozbijanie ich na mniejsze ‘’stories’’ nadaje rozpędu pracy zespołowej.


Innym sposobem wykorzystania '''epica''' (epic story) jest zastosowanie go jedynie po to żeby wiedzieć, że czymś czego jeszcze nie możemy dokładnie zdefiniować musimy się jednak zająć. Warto aczkolwiek jak najszybciej zamienić go na mniejsze, lepiej zdefiniowane epiki i historyjki użytkownika (user stories), a ten początkowy epic usunąć.
==Sposób prezentacji epica==
W celu zwizualizowania epics, możliwe jest użycie wykresów spalania. Służą one do motywowania oraz informowania interesariuszy na temat szacowanej i rzeczywistej ilości pracy pozostałej do wykonania. Wykresy spalania pozwalają na obrazowanie całkowitej pracy, prognozowanie możliwości osiągnięcia zamierzonego celu czy stopnia ukończenia zadania, na kontrolę postępów zespołu oraz na adekwatne reagowanie na zmiany.


==Bibliografia==
{{infobox5|list1={{i5link|a=[[Test driven development]]}} &mdash; {{i5link|a=[[Backlog produktu]]}} &mdash; {{i5link|a=[[Feature-Driven Development]]}} &mdash; {{i5link|a=[[Metodyka Extreme Programming]]}} &mdash; {{i5link|a=[[Testowanie w projekcie]]}} &mdash; {{i5link|a=[[Scrum of scrums]]}} &mdash; {{i5link|a=[[Redundancja]]}} &mdash; {{i5link|a=[[Manifest Agile]]}} &mdash; {{i5link|a=[[Programowanie strukturalne]]}} }}
* Cohn M., (2004), ''[http://athena.ecs.csus.edu/~buckley/CSc191/User-Stories-Applied-Mike-Cohn.pdf User Stories Applied for Agile Software Development], Addison-Wesley Professional
* Cohen, G., (2010), Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams, Super Star Pres.
* Kędziora F., (2011), [http://min.wmi.amu.edu.pl/wp-content/uploads/2011/04/PM_KEDZIORA_SCRUM.pdf Metodyka scrum w małych i średnich projektach informatycznych], Poznań
* Pichler, R., (2010), Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional.
* Sachdeva S., (2016), [https://www.academia.edu/26010951/Scrum_Methodology International Journal Of Engineering And Computer Science], nr5


==Przypisy==
==Przypisy==
<references />
<references />
{{a|Polina Ponochevna}}
 
[[Kategoria:Zarządzanie projektami]]
==Bibliografia==
<noautolinks>
* Cobb G. (2015), ''The project manager’s guide to mastering agile'', Wiley
* Cohen G. (2010), ''Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams'', Super Star Pres
* Cohn M. (2004), ''[https://athena.ecs.csus.edu/~buckley/CSc191/User-Stories-Applied-Mike-Cohn.pdf User Stories Applied for Agile Software Development]'', Addison-Wesley Professional
* Li P. (2015), ''Jira essentials'', Packt Publishing, Birmingham-Mumbai
* Lucassen G., Dalpiaz F., Van Der Werf J., Brinkkemper S. (2015), ''Forging high-quality user stories: towards a discipline for agile requirements'', 2015 IEEE 23rd international requirements engineering conference (RE)
* Munday L. (2019), ''Using Agile In Quality Driven Environment'', Seattle
* Pichler R. (2010), ''Agile Product Management with Scrum: Creating Products that Customers Love'', Addison-Wesley Professional
* Strona internetowa: ''[https://www.atlassian.com/agile/project-management/epics Agile epics: definition, examples, and templates]'', Atlassian
* Ulghani S. (2016), ''Scrum or not to scrum? The answer'', Xlibris
</noautolinks>
 
{{a|Klaudia Grucel}}
[[Kategoria:Techniki zwinne]]
 
{{#metamaster:description|Epic to zbiór pracy podzielony na konkretne zadania nazwane stories lub user stories i tworzony na podstawie potrzeb klientów lub użytkowników.}}

Aktualna wersja na dzień 01:10, 18 sty 2024

Agile epic jest ważnym elementem dla zespołów typu agile oraz DevOps, z uwagi na możliwość wykorzystania go do zarządzania zadaniami. Epic to zbiór pracy podzielony na konkretne zadania nazwane stories lub user stories i tworzony na podstawie potrzeb klientów lub użytkowników.

Kreowanie epica to sposób doskonalenia procesu realizacji pracy. Epic pomaga pracownikom dokończyć pracę oraz przerwać ją w odpowiednim momencie. Przyczynia się to do uzyskania możliwości kontynuacji pracy w celu osiągnięcia większego celu. Tworzenie epica nie należy do prostych zadań, istotne jest utrzymanie sprawności i opanowanie odpowiednich umiejętności pozwalających na jego kreację.

TL;DR

Agile epic jest ważnym narzędziem zarządzania zadaniami w metodyce agile i DevOps. Epics są zbiorem pracy podzielonym na konkretne zadania, tworzone na podstawie potrzeb klientów/użytkowników. Praca z epics opiera się na mapie drogi produktu i inicjatywach. Tworzenie epics wymaga utrzymania sprawności i opanowania odpowiednich umiejętności. Epics można zwizualizować za pomocą wykresów spalania.

Teoria

Epics tworzone są często przez wiele zespołów i są obecne w różnych projektach czy pracach. Epics są zwykle dostarczane przez serię sprintów. Dzieję się to wówczas, gdy zespoły informowane są o szczegółach epica, o prośbach, opiniach i potrzebach klientów/użytkowników. Poszczególne elementy mogą być elastycznie dodawane lub usuwane w odpowiedzi na zapotrzebowanie.

Praca zespołów opiera się na zrozumieniu związku epica oraz innych struktur agile, tj.:

  • Mapa drogowa produktu - plan określający działanie oraz kwestie związane z ewoluowaniem rozwiązania w czasie; wizualizowana jest za pomocą inicjatyw umieszczonych na osi czasu.
  • Temat - cel organizacji napędzający kreowanie epica i innych inicjatyw.
  • Inicjatywy - dzielone są na epics (epiki), które pomagają w utrzymaniu pracy zespołu; która z kolei wyrażona zostaje w mniejszych ‘’stories’’ i połączona jest z celami biznesowymi.

Zbiór zakończonych epics tworzy konkretną inicjatywę, która przyczynia się do rozwoju i ewoluowania produktu oraz sprostania wymaganiom stawianym przez rynek oraz użytkowników. Rysunek 1 obrazuje epic w metodyce Agile.

Rys. 1 Epic w metodyce Agile

.

Przykład epica

Zdarza się, że ‘’story’’ jest zbyt obszerna, wówczas zostaje określona mianem epica i zostaje podzielona na mniejsze ‘’stories’’. Przykładem epica jest stwierdzenie: ‘’Użytkownik szuka pracy’’, które należy podzielić na przykładowe ‘’stories’’:

  1. Użytkownik może wyszukiwać oferty na przykład według lokalizacji, wysokości wynagrodzenia czy rodzaju firmy.
  2. Użytkownik może przeglądać informacje o wszystkich kolejnych zadaniach odpowiadających poszczególnym elementom wyszukiwania.
  3. Użytkownik może wyświetlić szczegółowe dane oraz informacje o przedsiębiorstwie, które opublikowało dane stanowisko[1]

Tworzenie agile epic

Tworząc epic należy zwrócić uwagę na takie kwestie jak[2]:

  • Raportowanie - istotne jest tworzenie epics w projektach, które menedżerowie będą w stanie kontrolować.
  • Opowiadanie ‘’stories’’ - używanie w spójny sposób epica i ‘’story’’, co pozwala na określenie dotarcia do obecnego stanu produktu.
  • Kultura organizacyjna - w tym kontekście musi dyktować wielkość oraz stopień szczegółowości epica.
  • Czas - należy zwrócić uwagę na to jak długo zajmie realizacja epica. Okresu musi być dostosowany do indywidualnych wymagań każdego epica.

W celu skutecznego zrealizowania zadania, warto podzielić epic na mniejsze ‘’stories’’, gdyż to pomaga w utrzymaniu właściwego tempa oraz w całościowym zrozumieniu projektu. Opcjami, które warto rozważyć podczas tworzenia epica jest stworzenie unikatowego ‘’story’’ dla wszystkich potrzeb użytkownika. Następnie można podzielić proces na uporządkowane etapy i tworzyć mniejsze ‘’stories’’ dla każdego etapu.

Nie istnieje uniwersalna definicja oddzielająca obszerną ‘’story’’ od epica. ‘’Stories’’ powinny być realizowane w ciągu godzin lub dni; epics natomiast powinny zostać zrealizowane w ciągu tygodni, w ramach podziału na krótsze ‘’stories’’. Epics są podstawą działania związanego z programem agile; rozbijanie ich na mniejsze ‘’stories’’ nadaje rozpędu pracy zespołowej.

Sposób prezentacji epica

W celu zwizualizowania epics, możliwe jest użycie wykresów spalania. Służą one do motywowania oraz informowania interesariuszy na temat szacowanej i rzeczywistej ilości pracy pozostałej do wykonania. Wykresy spalania pozwalają na obrazowanie całkowitej pracy, prognozowanie możliwości osiągnięcia zamierzonego celu czy stopnia ukończenia zadania, na kontrolę postępów zespołu oraz na adekwatne reagowanie na zmiany.


Epicartykuły polecane
Test driven developmentBacklog produktuFeature-Driven DevelopmentMetodyka Extreme ProgrammingTestowanie w projekcieScrum of scrumsRedundancjaManifest AgileProgramowanie strukturalne

Przypisy

  1. M. Cohn, User Stories Applied for Agile Software Development, Addison-Wesley, 2009, s. 6
  2. Atlassian - Epics

Bibliografia

  • Cobb G. (2015), The project manager’s guide to mastering agile, Wiley
  • Cohen G. (2010), Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams, Super Star Pres
  • Cohn M. (2004), User Stories Applied for Agile Software Development, Addison-Wesley Professional
  • Li P. (2015), Jira essentials, Packt Publishing, Birmingham-Mumbai
  • Lucassen G., Dalpiaz F., Van Der Werf J., Brinkkemper S. (2015), Forging high-quality user stories: towards a discipline for agile requirements, 2015 IEEE 23rd international requirements engineering conference (RE)
  • Munday L. (2019), Using Agile In Quality Driven Environment, Seattle
  • Pichler R. (2010), Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional
  • Strona internetowa: Agile epics: definition, examples, and templates, Atlassian
  • Ulghani S. (2016), Scrum or not to scrum? The answer, Xlibris


Autor: Klaudia Grucel