Dacă sunteți implicat în dezvoltarea de software, trebuie să fi auzit de poveștile utilizatorilor. Poate chiar le scrieți în calitate de manager. Sau poate că sunteți client și dezvoltatorul de software dorește să încadrați solicitările de caracteristici ca povești de utilizator.

În această postare, veți găsi tot ce ați vrut vreodată să știți despre poveștile de utilizator.

Ce este o poveste de utilizator în dezvoltarea de software?

O poveste de utilizator este un format pentru încadrarea caracteristicilor și/sau cerințelor software. După cum sugerează partea de „utilizator”, poveștile de utilizator sunt scrise la persoana întâi singular și descriu o caracteristică așa cum este percepută de utilizatorul aplicației.

O poveste de utilizator tipică urmează această structură (dacă vorbim despre procesul de dezvoltare Agile):

Ca un ,
Vreau ,
Așa că .

Prima parte (ca un….) specifică rolul utilizatorului în cadrul aplicației, care este în mod normal asociat cu ceea ce are voie să facă cineva acolo.

A doua parte (caracteristica) indică bucata de funcționalitate care este utilizată în acest caz.

A treia parte (rezultatul dorit) este valoarea pe care utilizatorul dorește să o obțină din caracteristica respectivă. Iată câteva exemple.

Exemplu 1

În calitate de utilizator înregistrat,
vreau să fiu notificat atunci când un prieten merge la un eveniment în apropiere
pentru a putea reacționa la știri sau pentru a mă alătura evenimentului.

Exemplu 2

În calitate de călător,
vreau să primesc o reducere de 10% la fiecare a zecea călătorie
pentru a fi recompensat pentru că am cheltuit în mod constant bani pe acest serviciu.

Există motive întemeiate pentru acest tip de structură. Atunci când managerii de produs/proiect au de-a face cu cerințe software care provin dintr-o varietate de surse, este uneori dificil pentru ei să atingă uniformitatea. Ce categorie de utilizatori acoperă caracteristica sau unde se află valoarea comercială poate fi, de asemenea, neclară. Formatul user story ajută la captarea acestor detalii critice.

Abordări pentru compunerea user stories

User stories pot fi scrise într-o varietate de moduri, în funcție de cine va lucra cu ele.

The Gherkin Way

Gherkin este un limbaj de text simplu care descrie comportamentul fără a specifica implementarea acestuia. Iată un exemplu simplu de sintaxă Gherkin:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

După cum probabil ați observat, indentarea definește structura în Gherkin. Parametrii de bază sunt Given/When/Then, iar aceștia pot fi adăugați de mai multe And-uri dacă este necesar. Totuși, sintaxa merge dincolo de acești parametri de bază. Dacă sunteți cu adevărat hotărâți să stăpâniți Gherkin, iată un tutorial drăguț.

În timp ce Gherkin poate să nu fie cea mai bună alegere atunci când adunați cerințele inițiale pentru proiect, poate fi benefic (în special pentru echipa de asigurare a calității) atunci când dezvoltați în continuare povestirile utilizatorilor. Poveștile de utilizator scrise în Gherkin sunt ușor de convertit în cazuri de testare.

The Agile Way

Multe aplicații de management de proiect Agile oferă o funcționalitate pentru introducerea poveștilor de utilizator. De exemplu, am folosit aplicația Taiga în unele dintre proiectele noastre interne. Aceasta vă ajută să organizați munca în jurul poveștilor de utilizator care pot fi împărțite în sarcini individuale în backlog.

Sursa: Interfața Taiga.io

Dacă vă gândiți la asta, este perfect logic să aveți povești de utilizator ca elemente de backlog și apoi să adăugați mai multe sarcini la o poveste de utilizator. De ce? Pentru că, să spunem, aveți o caracteristică (= poveste de utilizator) și trei persoane care lucrează la ea; veți avea nevoie de sarcini separate pentru aceste persoane. Veți avea nevoie de un designer pentru a proiecta interfața, de un programator HTML/JavaScript pentru a programa interfața și de DevOps pentru a lansa interfața în producție.

Alte instrumente, cum ar fi Pivotal Tracker (care introduce conceptul de „epopee” pentru a grupa povești conexe), vă permit, de asemenea, să creați povești care pot fi de diferite tipuri: Funcționalități, Sarcini, Bug-uri sau Lansări.

Sursa: PivotalTracker.com

În afară de diferitele abordări folosite de diverse companii, nu uitați că există un mod simplu și direct de a redacta poveștile utilizatorilor – exemple pe care le-ați văzut la începutul acestei postări.

Cine ar trebui să scrie povești ale utilizatorilor?

Acum, a cui este responsabilitatea de a scrie povești ale utilizatorilor? Ei bine, depinde. Dacă echipa dvs. a fost de acord să captureze caracteristici sub formă de povești de utilizator, este foarte probabil ca acestea să vină de la acționari prin intermediul Product Owner. Așadar, este posibil ca PO să fie cel care le notează efectiv.

De asemenea, ar putea fi un manager de proiect sau un QA care poate, de asemenea, să lucreze cu clientul pentru a discuta caracteristicile și cerințele. Sau, poate că sunteți un startup de 15 persoane și voi sunteți CEO, CTO și CMO? În acest caz, ați putea da un exemplu și ați putea începe să folosiți povești de utilizator pentru a documenta caracteristicile.

Mulți din IT vorbesc, de asemenea, despre „dezvoltarea poveștilor de utilizator”, care este procesul de înregistrare mai întâi a detaliilor de nivel înalt (de exemplu, începând cu o listă simplă de caracteristici) și apoi de dezvoltare a acestora în povești mai detaliate prin adăugarea de sarcini, scenarii etc.

În concluzie

La sfârșitul zilei, formularea caracteristicilor sub forma unor povești de utilizator vă ajută să rămâneți concentrat pe obiectivele de afaceri. De asemenea, vă ajută să faceți cerințele complete. Și, așa cum s-a spus, șablonul/câmpurile exacte pe care le folosiți ar putea fi diferite, în funcție de situație.

.