Jaka jest różnica między historiami użytkownika a wymaganiami?

Chociaż większość nowych funkcji powinna być definiowana z perspektywy użytkownika, w praktyce, gdy definiujemy wymagania, które zespoły programistyczne muszą zbudować, często pomijamy „dlaczego” z perspektywy użytkownika. Nacisk w historii użytkownika spoczywa na doświadczeniu – czego użytkownik produktu chce osiągnąć. Tradycyjne wymagania skupiają się na funkcjonalności – co produkt powinien robić. Pozostałe różnice dotyczą subtelnych, ale kluczowych list „kto”, „jak” i „kiedy”.

Historie użytkownika powinny być pisane w jednym lub dwóch zdaniach, oddając, kim jest użytkownik, czego chce i dlaczego. Prosta struktura definiowania funkcji lub historii użytkownika wygląda następująco:

Jako ______, chcę ______, aby móc ______.

Przykład:

Jako użytkownik, chcę zresetować hasło, aby móc ponownie uzyskać dostęp do systemu, jeśli je zapomnę.

Mimo różnych celów, zarówno historie użytkownika, jak i wymagania mają na celu stworzenie produktu, którego klienci kochają.

Co to jest historia użytkownika?

Historie użytkownika to wymagania wyrażone z perspektywy końcowego użytkownika. Historie użytkownika mogą również nazywać się epikami, tematami lub funkcjami, ale wszystkie one podlegają tej samej strukturze.

W istocie, historia użytkownika to jasno sformułowane wymaganie. Z wielu powodów format historii użytkownika stał się najpopularniejszą metodą wyrażania wymagań w Agile:

• Skupia się na perspektywie osoby korzystającej z rozwiązania lub na nią wpływającej.
• Definiuje wymagania językiem zrozumiałym dla tej roli.
• Pomaga wyjaśnić prawdziwy cel założonego wymagania.
• Pomaga zdefiniować wymagania najwyższego poziomu bez zbyt wcześniejszego zagłębienia się w szczegółowe detale.

Określ cele użytkownika i od razu rozważ wartość biznesową każdego wymagania zawartego w historii użytkownika.

Historie użytkownika są zazwyczaj uważane za zawierające trzy elementy — 3C:

• CARD – Powinna być zapisana na kartce lub notesie.
• CRozmowa – uzyskaj szczegółowe informacje od właściciela produktu (Właściciel produktu).
• CPotwierdzenie – upewnij się, że została poprawnie zaimplementowana. Musi spełniać kryteria akceptacji użytkownika.

Format historii użytkownika

Format historii użytkownika wygląda następująco:

Jako <rola>, Chcę <cel>, aby <korzyść>

Te dwa przykłady ilustrują historie użytkownika na różnych poziomach, ale z wykorzystaniem tej samej formatki:

Na poziomie projektu:

Jako <dyrektor ds. marketingu>, Chcę <poprawić obsługę klienta>, aby <utrzymujemy naszych klientów>.

• Pisz cele SMART i kryteria INVEST dla historii użytkownika
• Temat vs Epyk vs Historia użytkownika vs Zadanie
• Co to jest DEEP w Backlogu produktu?
• Jak napisać wizję produktu dla projektu Scrum?
• Jak używać tablicy Scrum do rozwoju agilnego?
• Kto tworzy elementy Backlogu produktu lub historie użytkownika w Scrum?
• Co to jest szacowanie agilne?
• Co to jest punkt historii w agilności? Jak szacować historię użytkownika?
• Dzielenie historii użytkownika – pionowy cięciu vs poziomy cięciu