5 błędów popełnianych w tworzeniu User Story

5 błędów popełnianych w tworzeniu User Story

Autorem artykułu jest Krystian Kaczor

W podejściu zwinnym (agile) np. Scrum wymagania definiujemy w postaci User Story. Prosta forma, która ma adresować oczekiwania i potrzeby użytkowników często zespołom przysparza dużo problemów w implementacji. Szczególnie dużo pomyłek zdarza się w zwykle w zespołach zaczynających swoje doświadczenie w środowisku agile.

Dobrze skonstruowana User Story składa się z trzech części:

Jako (konkretny użytkownik systemu) chcę… (pożądana cecha lub problem, który trzeba rozwiązać) bo wtedy/ponieważ (korzyść płynąca z ukończenia story )Warunki Satysfakcji (Szczegóły dodane w formie testów akceptacyjnych)

Każdy z tych elementów jest ważny i gra rolę w zrozumieniu opisanego wymagania.

Spójrzmy teraz na 5 błędów najczęściej popełnianych w pisaniu User Stories.

1. Story dla Product Ownera

"Jako Product Owner chciałbym, żeby system pozwalał na usuwanie ogłoszeń, bo wtedy użytkownicy będą mieli możliwość usuwania ogłoszeń."

Popełniony błąd:
User Story nie może być pisane z punktu widzenia Product Ownera, ponieważ to nie on ma korzystać z systemu i to nie on ma potrzeby, które system powinien zaspokoić. W User Story pokazanej przykładzie nadal brakuje prawdziwej potrzeby użytkownika i typu użytkownika czy też roli jaką on pełni w systemie.

2. Story dla Programisty

"Jako deweloper chciałbym, żeby na środowisku produkcyjnym była zainstalowana 64-bitowa wersja Javy, bo wtedy w pełni wykorzystamy nowe maszyny."

Popełniony błąd:
To jest można powiedzieć sztandarowy przykład User Story dotyczącej aspektów technicznych i często należącej do zbioru "technical debt", czyli rzeczy, które trzeba wykonać z technicznego punktu widzenia ale nie dostarczają żadnych nowych funkcjonalności. Podobnie może wyglądać User Story dla refactoringu. I po raz kolejny elementami brakującymi tutaj jest korzyść dla użytkownika, rola lub rodzaj użytkownika i problem, który Story ma rozwiązać. Nie oznacza to, że tego typu potrzeby, czy wymagania nie mogą być zapisane jako User Story i maja być rozwiązywane w inny sposób. Można po prostu zapisać takie wymaganie z punktu widzenia korzyści dla użytkownika systemu. Na przykład: "Jako komercyjny użytkownik systemu chciałbym, żeby system działał szybciej, bo wtedy będę mógł wykonać więcej zapytań i szybciej znaleźć interesujące mnie ogłoszenia."

W warunkach satysfakcji umieszczamy przynajmniej "System odpowiada na przeciętne zapytanie w czasie poniżej 5 sekund."

I jednym z zadań w tej Story będzie: "Zainstaluj 64bitową wersję Javy."

3. Story dla Usera/Użytkownika

"Jako użytkownik chciałbym, żeby aplikacja umożliwiała zarządzanie ogłoszeniami, bo wtedy będę mógł usuwać nieaktualne i błędne ogłoszenia."

Popełniony błąd:
Taka Story jest zbyt ogólna. Kim jest nasz tajemniczy użytkownik i co on rozumie przez zarządzanie ogłoszeniami? Czy to jest administrator portalu, który chce mieć możliwość wyświetlania wszystkich ogłoszeń i ich moderacji lub czyszczenia bazy? Czy to jest ogłoszeniodawca prywatny, który chce mieć możliwość wyświetlania listy swoich aktywnych ogłoszeń i ich usuwania, kiedy przestają już być aktualne? Jak widać z punktu widzenia różnych rol czy person w systemie taka potrzeba może być różnie rozumiana.

4. Brak Korzyści

"Jako komercyjny użytkownik chciałbym mieć możliwość filtrowania ogłoszeń."

Popełniony błąd:
Nie wiadomo po co temu użytkownikowi możliwość filtrowania. Nie wiadomo też w jaki sposób ma się odbywać filtrowanie i po jakich kryteriach i przede wszystkim nie wiadomo co użytkownik rozumie przez filtrowanie. Co użytkownik chciałby osiągnąć?

5. Brak Warunków Satysfakcji/Acceptance Criteria

Tutaj można wziąć za przykład jedną z User Story pokazanych w poprzednich przykładach.

Popełniony błąd:
Jeżeli nie ma Warunków Satysfakcji, Story jest zdana na porażkę. Jest tutaj kilka powodów. Zadania deweloperskie mogą zostać źle zaplanowane. Story może nie przejść testów albo Przypadki Testowe nie będą odpowiadały faktycznej potrzebie, więc tak na prawdę zostanie przetestowane coś innego niż powinno. W czasie pozyskiwania Warunków Satysfakcji od użytkownika czy to w czasie trwania iteracji, Sprintu czy podczas Review może się okazać, że Story powinna być odrzucona lub oszacowanie było kompletnie nie poprawne i trzeba ta User Story ponownie zaplanować.

Po więcej artykułów na teamy związane ze Scrum i testowaniem oprogamowania zajrzyj na bloga http://kaczor.info/pl/articles.

---

Nie zwlekaj i już dzisiaj odwiedź mój blog o Scrum i testowaniu oprogramowania. Kliknij tutaj -> http://kaczor.info.

Artykuł pochodzi z serwisu www.Artelis.pl