Historyjki użytkownika to zwinna technika definiowania funkcjonalności i wymagań produktu. Koncentrują się one na opowiedzeniu historii akcji, którą podejmie użytkownik i jakie są jego oczekiwania, gdy zakończy się ona sukcesem. Koncepcja historyjek użytkownika jest szeroko stosowana, ale opowiadanie dobrych historii może być dość trudne.

W ciągu ostatnich kilku lat historyjki użytkownika stały się jednak hitem, ponieważ są one nieco zbyt uproszczone i brakuje im empatii dla użytkownika.

Dobra wiadomość – jest lepszy sposób! Nazywają się korniszony, ale w przeciwieństwie do ogórków, nie są tu po to, by zepsuć ci życie. (Chyba, że jesteś miłośnikiem ogórków!) 🥒

TL;DR

Jeśli trochę ci się spieszy, oto TL;DR (chociaż zachęcam do dalszego czytania, aby uzyskać dostęp do szablonów!).

• Historyjki użytkownika koncentrują się na użytkowniku, a nie na produkcie.
• Nakreśl swoje persony, aby dodać kontekst.
• Dodaj empatię do swoich historii, aby zrozumieć działania i motywacje.
• Korniszony: lepszy sposób pisania historii.
• Użyj korniszonów, aby skupić się na wynikach, a nie tylko na rezultatach.

Czym są historie użytkownika?

Historyjki użytkownika to krótkie, proste opisy rozwiązania opracowanego przez zespół, opowiedziane z perspektywy osoby, która odtwarza interakcję. Są one częścią większej epopei, która opisuje rzeczywisty problem do rozwiązania i powód jego rozwiązania.

Kluczowym słowem jest tutaj użytkownik, co oznacza, że historia użytkownika skupia się na użytkowniku, a nie na produkcie.

Historia użytkownika zazwyczaj koncentruje się na trzech obszarach:

• Jako(kto)
• Chcę(co)
• Więc(dlaczego)

Po tym wszystkim zwykle następują kryteria akceptacji, które określają, w jaki sposób można stwierdzić, czy interakcja zakończyła się sukcesem.

Kto: Wykorzystanie person do tworzenia historyjek użytkownika

Jeśli jeszcze nie zdefiniowałeś lub nie zrozumiałeś swoich użytkowników, to naprawdę nie powinieneś pisać historyjek użytkownika. Zacznij najpierw od odkrycia, mapowania podróży klienta i tworzenia odpowiednich person użytkowników, które pomogą Ci zdefiniować te historie.

Persona może pomóc zrozumieć i zapewnić kontekst „kto” w historii użytkownika – innymi słowy, kto przeprowadza tę interakcję.

Jest to ważne, ponieważ nieuchronnie będziesz mieć różne segmenty klientów, role i uprawnienia, więc zdefiniowanie tych interakcji, aby zaspokoić te różne typy użytkowników, jest ważne.

Co: Interakcje z historiami użytkowników

„Co” w historii użytkownika koncentruje się na samej interakcji. Trudną rzeczą jest upewnienie się, że „co” koncentruje się na tym, co użytkownik musi zrobić, a nie na tym, co użytkownik chce zrobić, i tutaj typowy szablon historii nieco się rozpada.

Aby dodać nieco empatii do samej historii, ważne jest, aby podkreślić, jak użytkownik może się czuć podczas interakcji z konkretną akcją.

Na przykład nikt nie chce wprowadzać skomplikowanego hasła z wielką literą, znakami specjalnymi i minimalną długością – ale wie, że powinien. W tym przypadku jest to coś, co użytkownik musi zrobić.

Dlaczego: powód działania historyjki użytkownika

Trzecia część szablonu historii użytkownika to „dlaczego” – to znaczy, dlaczego użytkownik chce (lub jest zobowiązany) wykonać określoną czynność.

Wracając do naszego poprzedniego przykładu wprowadzania haseł:

Jako administrator muszę utworzyć skomplikowane hasło, aby moje konto było bezpieczne.

Teraz rozumiemy, kto, co i dlaczego w tej historii – ale jest tu pewien problem. Wciąż brakuje empatii i kontekstu, ponieważ bądźmy szczerzy, nikt nie chce, aby skomplikowane hasła były wymogiem, ale wszyscy chcemy bezpiecznych kont.

Podczas testowania zespół QA po prostu zatrzymałby się na sprawdzeniu, czy hasło jest bezpieczne, a nie czy proces był frustrujący dla użytkownika.

Wprowadź szablon historii użytkownika Gherkin

Korniszony to sposób na dodanie do historyjek użytkownika i przedstawienie pełnego scenariusza, który pomoże programistom i testerom zrozumieć zarówno wynik, jak i rezultat konkretnej interakcji użytkownika.

1. Scenario – zachowanie, które zamierzasz opisać
2. Given – stan początkowy scenariusza
3. When – konkretne działanie podejmowane przez użytkownika
4. Then – testowalny wynik, zwykle spowodowany działaniem w When
5. And – w razie potrzeby kontynuuje dowolną z pozostałych trzech operacji

Biorąc pod uwagę wcześniej opisany scenariusz z hasłem:

1. Podczas ustawiania hasła (Scenario),
2. Given że jestem administratorem konta,
3. WhenWprowadzam hasło w polu hasła,
4. ThenPowinienem zostać ostrzeżony o wymaganiach dotyczących hasła,
5. And Powinienem mieć możliwość natychmiastowego wprowadzenia poprawek,
6. Then że mogę utworzyć bezpieczne konto.

Mamy teraz pełny obraz tego, kto wykonuje określone działania i jakie są wymagania dotyczące kryteriów akceptacji, a zespół wie, jakie mogą być potencjalne frustracje, dzięki czemu może zapewnić płynniejszy przebieg procesu.

Ogólnie rzecz biorąc, menedżer produktu lub właściciel produktu jest odpowiedzialny za pisanie historii Gherkin, tworząc w ten sposób lepszą komunikację między resztą zespołu i upewniając się, że wszyscy koncentrują się na wynikach, a nie tylko na wynikach.

Jakie są Twoje ulubione sposoby tworzenia zarysów historii? Daj mi znać! ✌️