INVEST: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (cleanup bibliografii i rotten links)
m (Czyszczenie tekstu)
Linia 15: Linia 15:


'''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
* Valuable –wartościowa
* Valuable - wartościowa
* Estimable – estymowalna
* Estimable - estymowalna
* Small - mała
* Small - mała
* Testable – testowalna
* Testable - testowalna


"INVEST” jest tym dla User stories, czym [[Zasada SMART|SMART]] dla [[Klasyfikacja celów i funkcji|celów]]. Akronim "INVEST” został stworzony przez Williama Wake`a, w 2003 roku<ref>Wake B. (2003).</ref>.
"INVEST” jest tym dla User stories, czym [[Zasada SMART|SMART]] dla [[Klasyfikacja celów i funkcji|celów]]. Akronim "INVEST” został stworzony przez Williama Wake`a, w 2003 roku<ref>Wake B. (2003).</ref>.
==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.
Linia 35: Linia 36:
* 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>.
==Negotiable==
==Negotiable==
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 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 – 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), 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 – 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), s. 163</ref>:
To, czy możliwe jest oszacowanie danej historyjki zależy od<ref>Chrapko M. (2015), 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) 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) 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), 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), 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). 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 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>.

Wersja z 12:34, 2 lis 2023

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].

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[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].

Przypisy

  1. ↑ Wake B. (2003).
  2. ↑ Chrapko M. (2015), s. 158
  3. ↑ Cohn M. (2009), s. 18
  4. ↑ Chrapko M. (2015), s. 160
  5. ↑ Cohn M. (2009), s. 20
  6. ↑ Chrapko M. (2015), s. 163
  7. ↑ Chrapko M. (2015), s. 163
  8. ↑ Chrapko M. (2015) s. 164
  9. ↑ Chrapko M. (2015), s. 165
  10. ↑ Leffingwell D., Behrens P. (2009), s. 9
  11. ↑ Chrapko M. (2015). s. 166
  12. ↑ Cohn M. (2009)., s. 26
  13. ↑ Chrapko M. (2015)., s. 167

Bibliografia


Autor: Karolina Zasada


Źródło: „https://mfiles.pl/pl/index.php?title=INVEST&oldid=157000”