Epic
| Epic |
|---|
| Polecane artykuły |
Epic w Metodyce Scrum można zdefiniować jako dużą część pracy, mającą jeden wspólny cel. 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).
Czym jest epic (epic story) 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). 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).
.
"Podstawowy cykl życia epica:
- 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 " [1].
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.
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ąć.
Bibliografia
- Cohn M., (2004), 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), 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), International Journal Of Engineering And Computer Science, nr5
Przypisy
- ↑ A. F. Kędziora, (2011), Metodyka scrum w małych i średnich projektach informatycznych, Poznań, s. 18.
Autor: Polina Ponochevna
