INVEST: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (cleanup bibliografii i rotten links) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 11 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''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 | * Independent - istnieje samodzielnie | ||
* Negotiable | * Negotiable - negocjowalna | ||
* Valuable | * Valuable - wartościowa | ||
* Estimable | * Estimable - estymowalna | ||
* Small - mała | * Small - mała | ||
* Testable | * Testable - testowalna | ||
"INVEST" jest tym dla User stories, czym [[Zasada SMART|SMART]] dla [[Klasyfikacja celów i funkcji|celów]]. | |||
==TL;DR== | ==TL;DR== | ||
Metoda INVEST jest sposobem na tworzenie wartościowych i testowalnych historyjek użytkownika. Historyjki powinny być niezależne, negocjowalne, wartościowe, estymowalne, małe i możliwe do przetestowania. INVEST jest odpowiednikiem zasady SMART dla celów i funkcji. | Metoda INVEST jest sposobem na tworzenie wartościowych i testowalnych historyjek użytkownika. Historyjki powinny być niezależne, negocjowalne, wartościowe, estymowalne, małe i możliwe do przetestowania. INVEST jest odpowiednikiem zasady SMART dla celów i funkcji. | ||
==Independent== | ==Independent== | ||
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. | ||
| Linia 35: | Linia 20: | ||
* połączenie wszystkich historyjek zależnych w jedną większą, niezależną, | * połączenie wszystkich historyjek zależnych w jedną większą, niezależną, | ||
* znalezienie innego sposobu na podział funkcjonalności między historyjkami<ref>Cohn M. (2009), s. 18</ref>. | * znalezienie innego sposobu na podział funkcjonalności między historyjkami<ref>Cohn M. (2009), s. 18</ref>. | ||
<google>n</google> | |||
==Negotiable== | ==Negotiable== | ||
Historyjki same w sobie nie są umową pomiędzy [[Product owner|product ownerem]] a [[Zespół deweloperski|zespołem deweloperskim]] | 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), 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), s. 20</ref>. Nie powinno się na przykład tworzyć historyjek, które mają [[wartość]] tylko dla zespołu deweloperskiego | Każda historyjka użytkownika powinna być wartościowa z punktu widzenia klienta oraz użytkownika tworzonego produktu<ref>Cohn M. (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), 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), s. 163</ref>). | ||
== Estimable== | ==Estimable== | ||
[[Estymacja]] oznacza określenie jej wielkości | [[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), s. 163</ref>: | To, czy możliwe jest oszacowanie danej historyjki zależy od<ref>Chrapko M. (2015), s. 163</ref>: | ||
* Konwersacji | * 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 | * 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) 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 | * 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), 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), 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), s. 9</ref>. | ||
==Small== | ==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<ref>Chrapko M. (2015). | 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<ref>Chrapko M. (2015). s. 166</ref>. 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<ref>Cohn M. (2009)., s. 26</ref>. 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). | 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<ref>Cohn M. (2009)., s. 26</ref>. 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== | ==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<ref>Chrapko M. (2015)., s. 167</ref>. | 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<ref>Chrapko M. (2015)., s. 167</ref>. | ||
{{infobox5|list1={{i5link|a=[[GERT]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Estymacja czasu trwania zadań]]}} — {{i5link|a=[[PERT]]}} — {{i5link|a=[[Behavior driven development]]}} — {{i5link|a=[[User stories]]}} — {{i5link|a=[[Testowanie w projekcie]]}} — {{i5link|a=[[Planning poker]]}} — {{i5link|a=[[Zarządzanie programem]]}} }} | |||
==Przypisy== | ==Przypisy== | ||
| Linia 66: | Linia 59: | ||
==Bibliografia== | ==Bibliografia== | ||
<noautolinks> | <noautolinks> | ||
* Chrapko M. (2015) | * Chrapko M. (2015), ''Scrum: o zwinnym zarządzaniu projektami'', Wydawnictwo Helion, Gliwice | ||
* Cohn M. ( | * 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 | ||
* Lai S | * Lai S. (2017), ''[https://aircconline.com/ijsea/V8N2/8217ijsea05.pdf 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) | * Leffingwell D., Behrens P. (2009), ''A User Story Primer'' | ||
</noautolinks> | </noautolinks> | ||
{{a|Karolina Zasada}} | {{a|Karolina Zasada}} | ||
[[Kategoria: | [[Kategoria:Techniki zwinne]] | ||
{{#metamaster:description|INVEST to metoda tworzenia wartościowych historyjek użytkownika - niezależność, negocjowalność, wartość, estymowalność, nieduża skala i możliwość przetestowania.}} | {{#metamaster:description|INVEST to metoda tworzenia wartościowych historyjek użytkownika - niezależność, negocjowalność, wartość, estymowalność, nieduża skala i możliwość przetestowania.}} | ||
Aktualna wersja na dzień 22:54, 17 sty 2024
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.
TL;DR
Metoda INVEST jest sposobem na tworzenie wartościowych i testowalnych historyjek użytkownika. Historyjki powinny być niezależne, negocjowalne, wartościowe, estymowalne, małe i możliwe do przetestowania. INVEST jest odpowiednikiem zasady SMART dla celów i funkcji.
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[1].
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[2].
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ń[3].
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[4]. 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[5]).
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[6]:
- 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[7]. 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[8].
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[9].
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[10]. 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[11]. 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[12].
| INVEST — artykuły polecane |
| GERT — Feature-Driven Development — Estymacja czasu trwania zadań — PERT — Behavior driven development — User stories — Testowanie w projekcie — Planning poker — Zarządzanie programem |
Przypisy
- ↑ Chrapko M. (2015), s. 158
- ↑ Cohn M. (2009), s. 18
- ↑ Chrapko M. (2015), s. 160
- ↑ Cohn M. (2009), s. 20
- ↑ Chrapko M. (2015), s. 163
- ↑ Chrapko M. (2015), s. 163
- ↑ Chrapko M. (2015) s. 164
- ↑ Chrapko M. (2015), s. 165
- ↑ Leffingwell D., Behrens P. (2009), s. 9
- ↑ Chrapko M. (2015). s. 166
- ↑ Cohn M. (2009)., s. 26
- ↑ Chrapko M. (2015)., s. 167
Bibliografia
- Chrapko M. (2015), Scrum: o zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice
- Cohn M. (2004), User Stories Applied for Agile Software Development, Addison-Wesley Professional
- Lai S. (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
Autor: Karolina Zasada
