Menú

Què és la història de l'usuari i els criteris d'acceptació (exemples)

what is user story acceptance criteria

Proveu El Nostre Instrument Per Eliminar Problemes

Una guia perfecta per als criteris d'acceptació de la història de l'usuari amb escenaris de la vida real:

A la indústria del desenvolupament de programari, la paraula 'Requisit' defineix quin és el nostre objectiu, què necessiten exactament els clients i què farà que la nostra empresa augmenti el seu negoci.

Ja sigui una empresa de productes que fabriqui productes de programari o una empresa de serveis que ofereixi serveis en diversos camps de programari, la base principal per a tots ells és el requisit i l’èxit es defineix pel grau de compliment dels requisits.

El terme 'requisit' té diferents noms en diferents metodologies de projecte.

En Cascada , es coneix com ' Document de requisits / especificacions ', Dins Àgil o SCRUM se l’anomena ‘Epic’, ‘User Story’.

Història de l

Segons el model Waterfall, els documents de requisits són enormes documents de 200 pàgines o més, ja que tot el producte s’implementa en una fase. Però aquest no és el cas d'Agile / SCRUM, perquè en aquestes metodologies es donen els requisits per a petites funcionalitats o funcions, ja que el producte es prepara pas a pas.

En aquest article, he fet tot el possible per compartir els meus 4 anys d’experiència en treballar amb històries d’usuaris i els seus criteris d’acceptació relacionats, juntament amb escenaris de la vida real fàcils i senzills per a una millor comprensió.

Tornem a visitar els fonaments primer.

Què aprendreu:

Què és una història d'usuari?

Una història d’usuari és un requisit per a qualsevol funcionalitat o característica que s’escrigui en una o dues línies i que pugui tenir un màxim de 5 línies. Una història d’usuari sol ser el requisit més senzill possible i tracta d’una i només una funcionalitat (o una característica).

A continuació s’indica el format estàndard més utilitzat per a la creació de User Story:

Com un

Exemple:

Com a usuari de WhatsApp, vull una icona de càmera al quadre d’escriptura del xat per capturar i enviar fotografies de manera que pugui fer clic i compartir les meves fotos simultàniament amb tots els meus amics.

Història de l

Què són els criteris d'acceptació?

Un criteri d'acceptació és un conjunt de condicions o regles empresarials acceptades que la funcionalitat o la funció haurien de complir i complir per tal que el propietari del producte / les parts interessades les accepti.

Aquesta és una part molt important de la realització de la història dels usuaris i el propietari de producte i l’analista d’empreses l’haurien de estudiar molt minuciosament perquè la manca d’un criteri únic pot costar molt. Aquesta és una llista numerada o amb pics senzilla.

El seu format és el següent:

' Tenint en compte algunes condicions prèvies quan faig alguna acció, espero el resultat '.

tipus de proves en desenvolupament de programari

Exemple (w.r.t a la història de l'usuari superior):

  • Considerem que estic xerrant amb un amic i hauria de poder fer una foto.
  • Quan faig clic a una imatge, hauria de poder afegir un títol a la imatge abans d’enviar-la.
  • Si hi ha algun problema en iniciar la càmera del telèfon, es mostrarà un missatge d'error com ara 'No s'ha pogut iniciar la càmera'. etc., s’ha de mostrar en conseqüència.

Per tant, la història de l’usuari defineix el requisit de qualsevol funcionalitat o característica, mentre que els criteris d’acceptació defineixen la ‘Definició de fet’ per a la història de l’usuari o el requisit.

Com a control de qualitat, és molt important entendre profundament la història de l’usuari i els seus criteris d’acceptació, sense que quedi ni un sol dubte al ‘començament de les proves’. Per avançar, entenem per què és extremadament important aprofundir en les històries dels usuaris i els criteris d’acceptació.

Aprofundint en les històries dels usuaris

Per començar, entenguem primer la importància d’un estudi ‘en profunditat’ d’una cosa bàsica i fonamental, és a dir, Històries d'usuaris.

Els casos següents són les meves pròpies experiències reals.

Cas núm. 1:

Abans de 3 anys, estava treballant en un Projecte d'aplicacions mòbils i el producte era una aplicació dissenyada per als proveïdors.

Hauríeu vist com un repartidor venia al vostre lloc per lliurar-lo. I tenen un telèfon mòbil en què us demanen que doneu la vostra signatura després del lliurament. Aquesta signatura es reflecteix al portal dels proveïdors de serveis de missatgeria com DTDC, FedEx, etc.

Imaginem que l’aplicació mòbil s’acaba de llançar i que els seus portals ja existeixen i actualitzen.

Problema: Per a un Sprint, el propietari del producte té una història d'usuari per a aquesta aplicació mòbil que 'Com a administrador del portal, hauria de poder veure la signatura que ha pres el lliurador en el moment del lliurament' . Aquí es modifica i actualitza el portal (aplicació web) en conseqüència per reflectir la signatura.

Com a control de qualitat, heu de verificar si la signatura capturada a l'aplicació mòbil reflecteix el que s'esperava al portal.

Si mireu aquesta història d'usuari, sembla simple, però hi ha un requisit ocult que 'per a les entregues històriques, no hi havia cap funcionalitat de reflexió de signatura, de manera que què hauria de passar si els nois del portal veien les entregues històriques?' S’han d’esborrar les dades històriques? Hauríem de permetre bloquejos o errors per a aquestes dades?

Per descomptat, en absolut, s’hauria de tractar amb gràcia.

Solució: Quan s’actualitzen les taules de bases de dades respectives per afegir una nova columna per a la ubicació de la signatura, les dades antigues haurien de tenir un valor NULL o 0 que s’haurien de comprovar i s’hauria de mostrar un missatge que indiqués ‘No hi ha signatura’.

El propietari del producte o l’analista d’empreses ho poden anomenar com a faltes, però això s’ha de fer. La implementació d’una característica amb èxit, però no és desitjable per als clients trencar alguna cosa amb ella. Cal fer-ho juntament amb la mateixa història d’usuari i en el mateix sprint.

Cas núm. 2

Fa 6 anys, estava treballant en una sol·licitud de finançament per a la planificació de la jubilació (sense cap BA) que era una aplicació global on gent de finances com CA, assessors financers podien utilitzar-la per a diferents monedes per projectar els plans d’inversió, l’estalvi, etc. gran període per als seus clients.

Problema: El propietari del producte us proporciona una història d'usuari que 'Com a assessor, vull veure l'informe del meu client en funció de les dades financeres proporcionades'.

Aquí hi havia 2 requisits ocults i jo ho diria com una història incompleta perquè:

a) Els informes haurien de tenir en compte el tipus de conversió diària diària i no l'històric, tal com es mostra a l'últim informe i

b) Si es modifica la moneda després d’haver proporcionat les dades financeres del client, els informes s’han de mostrar en la moneda modificada.

Solució: Vaig plantejar aquesta preocupació directament amb el nostre propietari de producte i li vaig fer saber que tots dos havien de fer-se el més aviat possible. Va estar d'acord amb mi i va crear 2 històries diferents per als propers sprints amb prioritat.

Emportar: Es van capturar perquè tots coneixíem molt bé els productes, el seu disseny, estructura, etc. Aquest coneixement només es pot aconseguir comprenent completament el producte, comprenent la interoperabilitat dels mòduls i estudiant a fons la història de l’usuari, encara que sigui un 2 folre.

Preneu notes per fer les coses més fàcils i parleu amb els BA i els desenvolupadors sobre el seu pensament.

Aprofundiment en els criteris d'acceptació

Entendre els criteris d’acceptació i totes les altres condicions i regles de manera exhaustiva és encara més important que subestimar la història d’un usuari. Com que si un requisit és incomplet o imprecís, es pot reprendre en el següent sprint, però si es perd un criteri d’acceptació, la història de l’usuari no es pot publicar.

Suposo que tots hauríem utilitzat la banca neta en algun moment i la majoria de nosaltres l’utilitzem cada dia i descarrego molt les meves declaracions històriques. Si ho observeu detingudament, hi ha algunes opcions específiques disponibles per descarregar-les.

Hi ha una opció per seleccionar el tipus de fitxer per descarregar la vostra declaració. Hi ha una opció per triar si voleu baixar només els Crèdits / Dèbit / tots dos.

Imagineu ara que el propietari del producte us ofereix aquesta història d'usuari: 'Com a client, vull descarregar l'extracte del compte per poder veure totes les meves transaccions realitzades durant un període específic'.

Amb els següents criteris d'acceptació:

  • Tenint en compte que estic a la pàgina de descripció de la declaració històrica, hauria de seleccionar el període durant el qual vull descarregar la declaració.
  • Tenint en compte que estic a la pàgina de descàrregues de la declaració històrica, hauria de seleccionar el compte per al qual vull descarregar la declaració.
  • Tenint en compte que estic a la pàgina de descàrregues de la declaració històrica, no se m'hauria de permetre la descàrrega de l'extracte per a la data futura 'A'.
  • Tenint en compte que estic a la pàgina de la declaració històrica de baixades, no se m'hauria de permetre seleccionar la data 'De' des de fa 10 anys.
  • Tenint en compte que descarrego la meva declaració, hauria de poder veure el fitxer descarregat.
  • Tenint en compte que estic a la pàgina de descripció de la declaració històrica, hauria de poder descarregar la meva declaració en formats doc, excel i pdf.

Si feu aquesta acceptació, hi falten tres coses:

  • Nom i format del nom del fitxer que es descarregarà.
  • Quina informació (noms de columna) es mostrarà al fitxer.
  • La llista d’opcions per seleccionar quin tipus de transacció vol el client, és a dir, només deutes o només crèdits o tots dos.

Aquests casos poden ocórrer de tant en tant, tot i que encara estudieu bé els criteris d’acceptació i intenteu visualitzar-los fent referència a la història de l’usuari. Com més estudieu profundament sobre les condicions i les regles empresarials, més coneixereu la funció.

Els errors trobats a l'etapa inicial no costen res en comparació amb el que podria costar a l'etapa de 'proves'.

Criteris d

Importància de trobar discrepàncies en els criteris d’acceptació i història de l’usuari

Sempre és important fer una immersió profunda en les històries de l'usuari i els criteris d'acceptació en una etapa inicial fins i tot abans que comenci el desenvolupament o les proves.

Perquè implica:

# 1) Malbaratament de temps:

Si es troben discrepàncies o errors en la història de l’usuari / criteris d’acceptació quan es desenvolupa o s’estan realitzant proves, és possible que s’hagi de fer molta reelaboració en el temps de sprint restant.

No passa que, fins i tot si el propietari del producte va perdre poques coses, traslladaria la història de l’usuari al proper sprint. El 95% és probable que demani a l’equip la implementació necessària i la publiqui al mateix sprint.

Per tant, es converteix en un malson per a l’equip, ja que han de passar temps extra, venir els caps de setmana o treballar tard a la nit. Això es pot evitar estudiant i discutint la història de l'usuari / criteris d'acceptació en la primera etapa possible.

# 2) Desaprofitament d’esforços:

Els desenvolupadors i QA han de tornar a revisar el codi implementat i provar de nou els casos. Actualitzar, afegir i eliminar segons els requisits no és una tasca fàcil. Es fa massa dolorós ja que ja hi ha una pressió per complir amb temps.

En aquesta situació, hi ha probabilitats d'errors en l'etapa de desenvolupament o proves. Si us trobeu amb aquesta situació, aneu per 'DevQA Pairing'. Com a guinda del pastís, és possible que no obtingueu cap compensació pel treball addicional.

Discrepàncies de la història de l

Conclusió

La comprensió profunda de User Story i els criteris d’acceptació només s’aconsegueix dedicant un temps immens a estudiar-la.

No hi ha cap eina o curs específic disponible al mercat per fer-ho, ja que es tracta de pensament lògic, experiència i coneixement sobre el producte.

Participar activament a la reunió prèvia al pla, parlar amb el BA, estudiar pel vostre compte només us pot ajudar a aconseguir-ho. Com més esforços feu, més apreneu i creireu.

Ja siguin els controladors de qualitat o els desenvolupadors, tothom ha d’estar a la mateixa pàgina sobre les històries dels usuaris i els seus criteris d’acceptació, només així les expectatives del client es poden assolir amb èxit.

Té alguna cosa nova que compartir amb nosaltres sobre les seves experiències en treballar amb User Stories? Si us plau, expressi els seus pensaments a continuació !!

Lectura recomanada

^