Epic: Różnice pomiędzy wersjami
m (Infobox update) |
(LinkTitles.) |
||
| Linia 16: | Linia 16: | ||
'''Epic''' w '''Metodyce Scrum''' można zdefiniować jako dużą część pracy, mającą jeden wspólny cel. | '''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). | 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?== | ==Czym jest epic (epic story) w Metodyce Agile?== | ||
| Linia 23: | Linia 23: | ||
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). | 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>t</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). | 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). | ||
[[Plik:EPIC.png|300px|right|thumb|Rys. 1 Epic w metodyce Agile]]. | [[Plik:EPIC.png|300px|right|thumb|Rys. 1 Epic w metodyce Agile]]. | ||
"'''Podstawowy cykl życia epica:''' | "'''Podstawowy [[cykl]] życia epica:''' | ||
* product owner definiuje user story, | * [[product owner]] definiuje user story, | ||
* zespół stwierdza że user story jest zbyt duże, by je wyestymować realnie na jeden sprint, | * 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, | * 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, | * tworzone są mniejsze user story w zakresie odpowiadającym całemu epikowi, | ||
* wszystkie user stories przechodzą swój cykl zycia, | * 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. | * 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>. | </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. | '''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ąć. | 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ąć. | ||
Wersja z 19:19, 19 maj 2020
| 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
Autor: Polina Ponochevna
