INVEST: Różnice pomiędzy wersjami
mNie podano opisu zmian |
m (cleanup bibliografii i rotten links) |
||
| Linia 67: | Linia 67: | ||
<noautolinks> | <noautolinks> | ||
* Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice | * Chrapko M. (2015). ''Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone'', Wydawnictwo Helion, Gliwice | ||
* Cohn M. (2009). [ | * Cohn M. (2009). [https://athena.ecs.csus.edu/~buckley/CSc191/User-Stories-Applied-Mike-Cohn.pdf ''User Stories Applied for Agile Software Development''], "Addison-Wesley", Reading 2009 | ||
* Lai S.-T. (2017). [ | * Lai S.-T. (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). A User Story Primer | * Leffingwell D., Behrens P. (2009). A User Story Primer | ||
* Wake B. (2003). [https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ ''INVEST in Good Stories, and SMART Tasks''](dostęp: 18.05.2018) | * Wake B. (2003). [https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ ''INVEST in Good Stories, and SMART Tasks''](dostęp: 18.05.2018) | ||
Wersja z 22:57, 29 paź 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
- ↑ Wake B. (2003).
- ↑ 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 wydanie II rozszerzone, Wydawnictwo Helion, Gliwice
- Cohn M. (2009). User Stories Applied for Agile Software Development, "Addison-Wesley", Reading 2009
- 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
- Wake B. (2003). INVEST in Good Stories, and SMART Tasks(dostęp: 18.05.2018)
Autor: Karolina Zasada
