INVEST: Różnice pomiędzy wersjami
m (Infobox update) |
(LinkTitles.) |
||
| Linia 16: | Linia 16: | ||
'''INVEST''' - jest to metoda wspierająca tworzenie [[User stories|historyjek użytkownika]] (ang. User stories). Skrót ten oznacza sześć cech, którymi charakteryzuje się każda poprawnie napisana historyjka: | '''INVEST''' - jest to [[metoda]] wspierająca tworzenie [[User stories|historyjek użytkownika]] (ang. User stories). Skrót ten oznacza sześć cech, którymi charakteryzuje się każda poprawnie napisana historyjka: | ||
* Independent – istnieje samodzielnie | * Independent – istnieje samodzielnie | ||
* Negotiable – negocjowalna | * Negotiable – negocjowalna | ||
| Linia 29: | Linia 29: | ||
Poprawnie napisana historyjka użytkownika powinna być niezależna od innych historyjek przygotowanych dla danego projektu. | Poprawnie napisana historyjka użytkownika powinna być niezależna od innych historyjek przygotowanych dla danego projektu. | ||
Historyjki wzajemnie niezależne można wdrażać w projekcie w dowolnej kolejności - wzajemne zależności pomiędzy historyjkami prowadzą natomiast do problemów w ustalaniu priorytetów oraz planowaniu implementacji poszczególnych historyjek<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 158</ref>. | Historyjki wzajemnie niezależne można wdrażać w projekcie w dowolnej kolejności - wzajemne zależności pomiędzy historyjkami prowadzą natomiast do problemów w ustalaniu priorytetów oraz planowaniu implementacji poszczególnych historyjek<ref>Chrapko M. (2015). ''[[Scrum]]. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 158</ref>. | ||
Jeżeli w trakcie tworzenia historyjek okaże się, że dwie lub więcej z nich jest wzajemnie powiązane, możliwe są dwa sposoby rozwiązania: | Jeżeli w trakcie tworzenia historyjek okaże się, że dwie lub więcej z nich jest wzajemnie powiązane, możliwe są dwa sposoby rozwiązania: | ||
| Linia 37: | Linia 37: | ||
Historyjki same w sobie nie są umową pomiędzy [[Product owner|product ownerem]] a [[Zespół deweloperski|zespołem deweloperskim]] – nie zawierają one wszystkich szczegółów niezbędnych do tego, aby być traktowane jako specyfikację wymagań<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 160</ref>. | Historyjki same w sobie nie są umową pomiędzy [[Product owner|product ownerem]] a [[Zespół deweloperski|zespołem deweloperskim]] – nie zawierają one wszystkich szczegółów niezbędnych do tego, aby być traktowane jako specyfikację wymagań<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 160</ref>. | ||
Historyjki powinny być napisane w taki sposób, aby możliwe było ich negocjowanie. Negocjacje historyjki prowadzone są pomiędzy Product ownerem (reprezentującym interesy przyszłych użytkowników) a zespołem deweloperskim. W trakcie negocjacji ustalane są wszystkie szczegóły niezbędne do implementacji historyjki. Obydwie strony powinny być otwarte na rozmowę, gotowe na ewentualne kompromisy, oraz mieć na względzie potrzeby drugiej strony. | Historyjki powinny być napisane w taki sposób, aby możliwe było ich negocjowanie. [[Negocjacje]] historyjki prowadzone są pomiędzy Product ownerem (reprezentującym interesy przyszłych użytkowników) a zespołem deweloperskim. W trakcie negocjacji ustalane są wszystkie szczegóły niezbędne do implementacji historyjki. Obydwie strony powinny być otwarte na rozmowę, gotowe na ewentualne kompromisy, oraz mieć na względzie [[potrzeby]] drugiej strony. | ||
==Valuable== | ==Valuable== | ||
Każda historyjka użytkownika powinna być wartościowa z punktu widzenia klienta oraz użytkownika tworzonego produktu<ref>Cohn M. (2009). [http://athena.ecs.csus.edu/~buckley/CSc191/User-Stories-Applied-Mike-Cohn.pdf ''User Stories Applied for Agile Software Development''], "Addison-Wesley", Reading 2009, s. 20</ref>. Nie powinno się na przykład tworzyć historyjek, które mają wartość tylko dla zespołu deweloperskiego – skupiających się na technologii czy rozwiązaniach programistycznych – nie mających faktycznej wartości dla docelowych użytkowników. | Każda historyjka użytkownika powinna być wartościowa z punktu widzenia klienta oraz użytkownika tworzonego produktu<ref>Cohn M. (2009). [http://athena.ecs.csus.edu/~buckley/CSc191/User-Stories-Applied-Mike-Cohn.pdf ''User Stories Applied for Agile Software Development''], "Addison-Wesley", Reading 2009, s. 20</ref>. Nie powinno się na przykład tworzyć historyjek, które mają [[wartość]] tylko dla zespołu deweloperskiego – skupiających się na technologii czy rozwiązaniach programistycznych – nie mających faktycznej wartości dla docelowych użytkowników. | ||
Dlatego też User stories powinny być pisane przez Product ownera, jako osoby będącej reprezentantem interesów użytkownika<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 163</ref>). | Dlatego też User stories powinny być pisane przez Product ownera, jako osoby będącej reprezentantem interesów użytkownika<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 163</ref>). | ||
== Estimable== | == Estimable== | ||
Estymacja oznacza określenie jej wielkości – zwykle poprzez podanie, ile mniej więcej czasu powinna zająć implementacja danej historyjki. | [[Estymacja]] oznacza określenie jej wielkości – zwykle poprzez podanie, ile mniej więcej czasu powinna zająć [[implementacja]] danej historyjki. | ||
Tak jak tworzenie historyjek jest odpowiedzialnością Product ownera, tak ich estymacja należy do zespołu deweloperskiego. | Tak jak tworzenie historyjek jest odpowiedzialnością Product ownera, tak ich estymacja należy do zespołu deweloperskiego. | ||
To, czy możliwe jest oszacowanie danej historyjki zależy od<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 163</ref>: | To, czy możliwe jest oszacowanie danej historyjki zależy od<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 163</ref>: | ||
* Konwersacji – jeżeli historyjka nie została wystarczająco omówiona z product ownerem, wówczas zespół nie posiada wystarczającej wiedzy biznesowej do przeprowadzenia estymacji. Zespół deweloperski musi rozumieć, przynajmniej na ogólnym poziomie, kontekst biznesowy danego user story. | * Konwersacji – jeżeli historyjka nie została wystarczająco omówiona z product ownerem, wówczas [[zespół]] nie posiada wystarczającej wiedzy biznesowej do przeprowadzenia estymacji. [[Zespół deweloperski]] musi rozumieć, przynajmniej na ogólnym poziomie, kontekst biznesowy danego user story. | ||
* Rozmiaru historyjki – jeżeli historyjka jest za duża, jej oszacowanie jest znacznie utrudnione. Najwygodniejsze do szacowania są takie historyjki, które można w całości zaimplementować w ciągu jednego [[sprint|sprintu]]<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice s. 164</ref>. Zbyt duże historyjki są na tyle ogólne, że zwykle brakuje wielu szczegółów istotnych dla prawidłowego ich oszacowania. | * Rozmiaru historyjki – jeżeli historyjka jest za duża, jej oszacowanie jest znacznie utrudnione. Najwygodniejsze do szacowania są takie historyjki, które można w całości zaimplementować w ciągu jednego [[sprint|sprintu]]<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice s. 164</ref>. [[Zbyt]] duże historyjki są na tyle ogólne, że zwykle brakuje wielu szczegółów istotnych dla prawidłowego ich oszacowania. | ||
* Zespołu deweloperskiego – szacowanie historyjki jest również w dużym stopniu zależne od wiedzy, doświadczenia oraz umiejętności zespołu deweloperskiego. Jeżeli np. Zespół nie ma doświadczenia w technologii, która zostanie użyta do implementacji, wówczas estymacja jest praktycznie niewykonalna. Tego typu problem można rozwiązać poprzez utworzenie pewnego rodzaju projektu badawczego - problematyczną historyjkę dzieli się na dwie części - pierwsza dotyczy analizy nieznanego zagadnienia, druga faktycznej funkcjonalności<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 165</ref>. | * Zespołu deweloperskiego – szacowanie historyjki jest również w dużym stopniu zależne od wiedzy, doświadczenia oraz [[umiejętności]] zespołu deweloperskiego. Jeżeli np. Zespół nie ma doświadczenia w technologii, która zostanie użyta do implementacji, wówczas estymacja jest praktycznie niewykonalna. Tego typu problem można rozwiązać poprzez utworzenie pewnego rodzaju projektu badawczego - problematyczną historyjkę dzieli się na dwie części - pierwsza dotyczy analizy nieznanego zagadnienia, druga faktycznej funkcjonalności<ref>Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice, s. 165</ref>. | ||
Podstawową korzyścią płynącą z całego procesu estymacji historyjek jest nie tyle faktyczne oszacowanie czasu trwania ich implementacji, a wykrycie wszystkich ukrytych założeń, brakujących kryteriów akceptacji, oraz upewnienie się, że wszyscy zaangażowani rozumieją daną historyjkę w ten sam sposób<ref>Leffingwell D., Behrens P. (2009). [https://scalingsoftwareagility.files.wordpres.com/2009/11/user-story-primer_1.pdf A User Story Primer], s. 9</ref>. | Podstawową korzyścią płynącą z całego procesu estymacji historyjek jest nie tyle faktyczne oszacowanie czasu trwania ich implementacji, a wykrycie wszystkich ukrytych założeń, brakujących kryteriów akceptacji, oraz upewnienie się, że wszyscy zaangażowani rozumieją daną historyjkę w ten sam sposób<ref>Leffingwell D., Behrens P. (2009). [https://scalingsoftwareagility.files.wordpres.com/2009/11/user-story-primer_1.pdf A User Story Primer], s. 9</ref>. | ||
Wersja z 23:17, 19 maj 2020
| INVEST |
|---|
| Polecane artykuły |
INVEST - jest to metoda wspierająca tworzenie historyjek użytkownika (ang. User stories). Skrót ten oznacza sześć cech, którymi charakteryzuje się każda poprawnie napisana historyjka:
- Independent – istnieje samodzielnie
- Negotiable – negocjowalna
- Valuable –wartościowa
- Estimable – estymowalna
- Small - mała
- Testable – testowalna
"INVEST” jest tym dla User stories, czym SMART dla celów. Akronim "INVEST” został stworzony przez Williama Wake`a, w 2003 roku[1].
Independent
Poprawnie napisana historyjka użytkownika powinna być niezależna od innych historyjek przygotowanych dla danego projektu.
Historyjki wzajemnie niezależne można wdrażać w projekcie w dowolnej kolejności - wzajemne zależności pomiędzy historyjkami prowadzą natomiast do problemów w ustalaniu priorytetów oraz planowaniu implementacji poszczególnych historyjek[2].
Jeżeli w trakcie tworzenia historyjek okaże się, że dwie lub więcej z nich jest wzajemnie powiązane, możliwe są dwa sposoby rozwiązania:
- połączenie wszystkich historyjek zależnych w jedną większą, niezależną,
- znalezienie innego sposobu na podział funkcjonalności między historyjkami[3].
Negotiable
Historyjki same w sobie nie są umową pomiędzy product ownerem a zespołem deweloperskim – nie zawierają one wszystkich szczegółów niezbędnych do tego, aby być traktowane jako specyfikację wymagań[4].
Historyjki powinny być napisane w taki sposób, aby możliwe było ich negocjowanie. Negocjacje historyjki prowadzone są pomiędzy Product ownerem (reprezentującym interesy przyszłych użytkowników) a zespołem deweloperskim. W trakcie negocjacji ustalane są wszystkie szczegóły niezbędne do implementacji historyjki. Obydwie strony powinny być otwarte na rozmowę, gotowe na ewentualne kompromisy, oraz mieć na względzie potrzeby drugiej strony.
Valuable
Każda historyjka użytkownika powinna być wartościowa z punktu widzenia klienta oraz użytkownika tworzonego produktu[5]. Nie powinno się na przykład tworzyć historyjek, które mają wartość tylko dla zespołu deweloperskiego – skupiających się na technologii czy rozwiązaniach programistycznych – nie mających faktycznej wartości dla docelowych użytkowników.
Dlatego też User stories powinny być pisane przez Product ownera, jako osoby będącej reprezentantem interesów użytkownika[6]).
Estimable
Estymacja oznacza określenie jej wielkości – zwykle poprzez podanie, ile mniej więcej czasu powinna zająć implementacja danej historyjki.
Tak jak tworzenie historyjek jest odpowiedzialnością Product ownera, tak ich estymacja należy do zespołu deweloperskiego. To, czy możliwe jest oszacowanie danej historyjki zależy od[7]:
- Konwersacji – jeżeli historyjka nie została wystarczająco omówiona z product ownerem, wówczas zespół nie posiada wystarczającej wiedzy biznesowej do przeprowadzenia estymacji. Zespół deweloperski musi rozumieć, przynajmniej na ogólnym poziomie, kontekst biznesowy danego user story.
- Rozmiaru historyjki – jeżeli historyjka jest za duża, jej oszacowanie jest znacznie utrudnione. Najwygodniejsze do szacowania są takie historyjki, które można w całości zaimplementować w ciągu jednego sprintu[8]. Zbyt duże historyjki są na tyle ogólne, że zwykle brakuje wielu szczegółów istotnych dla prawidłowego ich oszacowania.
- Zespołu deweloperskiego – szacowanie historyjki jest również w dużym stopniu zależne od wiedzy, doświadczenia oraz umiejętności zespołu deweloperskiego. Jeżeli np. Zespół nie ma doświadczenia w technologii, która zostanie użyta do implementacji, wówczas estymacja jest praktycznie niewykonalna. Tego typu problem można rozwiązać poprzez utworzenie pewnego rodzaju projektu badawczego - problematyczną historyjkę dzieli się na dwie części - pierwsza dotyczy analizy nieznanego zagadnienia, druga faktycznej funkcjonalności[9].
Podstawową korzyścią płynącą z całego procesu estymacji historyjek jest nie tyle faktyczne oszacowanie czasu trwania ich implementacji, a wykrycie wszystkich ukrytych założeń, brakujących kryteriów akceptacji, oraz upewnienie się, że wszyscy zaangażowani rozumieją daną historyjkę w ten sam sposób[10].
Small
Historyjka użytkownika powinna być na tyle mała, aby można ją było bez większych problemów zaplanować i oszacować, a jej implementacja powinna być wykonalna w ciągu jednego sprintu[11]. Jeśli historyjka okazuje się być za duża należy ją, w miarę możliwości, rozdzielić na mniejsze historyjki.
Historyjka nie może być również zbyt mała. Jeżeli członek zespołu stwierdza, że implementacja historyjki potrwa krócej, niż jej zapisanie czy szacowanie, oznacza to, że historyjka jest za mała[12]. W takim przypadku, jeżeli mamy do czynienia z kilkoma takimi małymi historyjkami, należy je połączyć w jedną (lub więcej, w zależności od wybranego sposobu łączenia).
Testable
Każda historyjka użytkownika powinna być możliwa do przetestowania. Sposób przetestowania każdej historyjki powinien być zawarty w testach akceptacyjnych, które powinny być opisane na odwrocie karteczki z opisaną historyjką. Wykonanie wszystkich zdefiniowanych testów akceptacyjnych oraz uzyskanie w każdym z nich pozytywnego wyniku powinno potwierdzać, że dana historyjka została poprawnie zaimplementowana, a otrzymane wyniki są zgodne z wynikiem opisanym w historyjce[13].
Bibliografia
- Wake B. (2003). INVEST in Good Stories, and SMART Tasks(dostęp: 18.05.2018).
- Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice
- Lai S.-T. (2017). A User Story Quality Measurement Model for Reducing Agile Software Development Risk, "International Journal of Software Engineering & Applications", cz 8, nr 2
- Leffingwell D., Behrens P. (2009). A User Story Primer
- Cohn M. (2009). User Stories Applied for Agile Software Development, "Addison-Wesley", Reading 2009
Przypisy
- ↑ Wake B. (2003). INVEST in Good Stories, and SMART Tasks(dostęp: 18.05.2018)
- ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 158
- ↑ Cohn M. (2009). User Stories Applied for Agile Software Development, "Addison-Wesley", Reading 2009, s. 18
- ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 160
- ↑ Cohn M. (2009). User Stories Applied for Agile Software Development, "Addison-Wesley", Reading 2009, s. 20
- ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 163
- ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 163
- ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice s. 164
- ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 165
- ↑ Leffingwell D., Behrens P. (2009). A User Story Primer, s. 9
- ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 166
- ↑ Cohn M. (2009). User Stories Applied for Agile Software Development, "Addison-Wesley", Reading 2009, s. 26
- ↑ Chrapko M. (2015). Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice, s. 167
Autor: Karolina Zasada
