Com escriure criteris d'acceptació a Jira, amb exemples pràctics

"Els clients poden canviar les seves preferències de notificació" sembla un tiquet clar de Jira fins que algú comença a crear-lo. Un canvi es guarda immediatament? Què passa si no es pot desar? La preferència encara hi serà demà? Quins correus electrònics es veuen afectats?

Els criteris d'acceptació converteixen aquestes preguntes obertes en resultats observables i acordats. Ajuden a les persones que sol·liciten, construeixen i revisen un canvi a treballar des de les mateixes expectatives.

En aquesta guia, desenvoluparem criteris per a una funció de portal de clients fictici, millorarem els requisits vagues i afegirem una llista de verificació pràctica a l'eina Definició de finalització i AC de Power Pack. No necessiteu un format d'escriptura especial per començar. Les condicions i els resultats clars són suficients.

Quins són els criteris d'acceptació?

Els criteris d'acceptació descriuen les condicions que ha de complir una obra concreta per ser acceptada. Es centren en el resultat esperat d'aquest article. Atlassian els distingeix de la Definició de finalització, que descriu l'estàndard de qualitat més ampli per al treball acabat. Consulteu la guia de criteris d'acceptació de Atlassian.

Per al nostre exemple, "Una opció de notificació desada roman seleccionada després que el client torni a iniciar sessió" és un criteri d'acceptació. "La implementació s'ha revisat" pertany a la Definició compartida de finalització.

Aquesta distinció fa que cada llista sigui útil. Els criteris d'acceptació expliquen si aquesta característica fa el que l'equip va acordar. La Definició de finalització explica si el treball compleix l'estàndard de finalització més ampli de l'equip.

Cap llista ha de contenir tots els passos d'implementació. "Crear un camp de base de dades" pot ser una tasca d'enginyeria necessària, però no indica a un client o revisor si la preferència es comporta correctament.

Comenceu amb un resultat del client

El nostre tiquet fictici s'anomena "Permet que els clients controlin el correu electrònic de resum setmanal". El resultat previst és que un client que hagi iniciat la sessió pugui triar si vol rebre un resum setmanal sense canviar els missatges essencials del compte.

Abans d'escriure els criteris, l'equip accepta algunes decisions d'abast. La configuració té un botó Desa explícit. El client només canvia la seva pròpia preferència. La preferència afecta els resums que encara no s'han posat a la cua. Els missatges que ja estan a la cua estan fora de la regla de lliurament d’aquest tiquet.

Aquests detalls estan inventats per a l'exemple. El vostre equip hauria de decidir el seu comportament real en lloc de copiar-los com a requisits del producte.

Una nota d'abast petit pot evitar que una llista de verificació llarga contingui tot el context. A la descripció de Jira, l'equip registra que aquest tiquet cobreix una preferència a la pàgina de configuració del compte. L'elecció dels dies de lliurament, el canvi d'adreces de correu electrònic i la gestió de les preferències d'altres clients són feina independent.

Ara els criteris es poden concentrar en els resultats que estableixen si aquest canvi en concret funciona.

Escriu primer el camí normal

Comenceu amb l'experiència que espereu que segueixin la majoria dels clients. Indiqueu la condició inicial, l'acció i el resultat observable en llenguatge ordinari.

Per exemple: "Quan un client que ha iniciat la sessió desactiva els resums setmanals i desa correctament, la reobertura de la configuració del compte mostra els resums setmanals desactivats". Un revisor pot crear l'estat inicial, realitzar l'acció i inspeccionar el resultat.

Aquesta frase és més útil que "Les preferències es guarden correctament". Especifica quina preferència canvia, quan entra en vigor el canvi i com algú pot comprovar-ho.

L'equip també necessita la direcció inversa. Un control que desactiva correctament els resums però que no els pot activar està incomplet. Escriu un criteri separat quan el comportament invers mereixi la seva pròpia verificació.

No forçar resultats no relacionats en una sola entrada. L'emmagatzematge, el funcionament del teclat, l'enviament del correu electrònic i la gestió d'errors poden importar, però un criteri enorme fa que sigui difícil mostrar quina part encara necessita atenció.

Afegiu casos d'error i límit

El camí normal suposa que el desament té èxit. Pregunteu què ha de veure el client quan aquesta suposició és falsa.

El nostre equip tria aquesta regla: si la sol·licitud de desat falla, la pàgina mostra un error i no mostra una confirmació d'èxit. En tornar a obrir la pàgina, la preferència desada anteriorment es manté al seu lloc. Això ofereix al revisor un cas concret de fallada per exercir-lo a l'entorn de prova de l'equip.

A continuació, inspeccioneu el límit de la funció. La configuració del resum setmanal no ha d'aturar un correu electrònic de restabliment de la contrasenya. L'elecció del client també ha de sobreviure a una nova sessió d'inici de sessió. Aquestes són preocupacions diferents, de manera que reben criteris separats.

Eviteu escriure "Tots els casos marginals gestionats". Anomena els casos importants. Una discussió útil sovint comença amb tres preguntes: què pot fallar, què no s'ha de veure afectat i què passa després?

Si l'equip no es pot posar d'acord amb un resultat esperat, registreu la decisió no resolta abans que la implementació avanci massa. Una pregunta sense resposta no es converteix en un criteri utilitzable només perquè s'ha col·locat en una llista de verificació.

Una llista de verificació de criteris d'acceptació treballada

Aquí teniu el primer esborrany complet del número de ficció. Cada entrada descriu un resultat que l'equip pot verificar per separat.

• L'obertura de la configuració del compte mostra la preferència de resum setmanal desada actualment del client.
• Després de desactivar els resums setmanals i desar correctament, en tornar a obrir la configuració del compte es mostra la preferència desactivada.
• Després d'activar els resums setmanals i desar correctament, la reobertura de la configuració del compte mostra la preferència activada.
• Després d'un desat satisfactori, tancar la sessió i tornar a iniciar la sessió conserva la preferència desada.
• Si el desament falla, es mostra un error, no apareix cap confirmació d'èxit i la reobertura de la configuració mostra la preferència desada anteriorment.
• Un client la preferència del qual està desactivada no rep cap resum setmanal que s'hagi posat a la cua després del desament correcte.
• Un client la preferència del qual està activada continua sent apte per al següent resum setmanal segons les regles de programació existents.
• Desactivar els resums setmanals no impedeix que aquest client rebi un correu electrònic de restabliment de la contrasenya sol·licitat.

Les entrades de lliurament depenen de la decisió de l'abast dels missatges a la cua. L'equip registra aquest context juntament amb el tiquet, de manera que el revisor no assumeix que la configuració retiri els correus electrònics que ja s’estan enviant.

Aquests criteris també necessiten un enfocament de verificació viable. Pel que fa al comportament de lliurament, l'equip identifica com activar o observar un resum al seu entorn de prova. Un criteri pot estar escrit amb claredat però difícil de verificar si ningú té accés al compte o a les proves de lliurament necessàries.

Millora els criteris vagues abans d'afegir-los

Una revisió ràpida de la redacció sovint evita desacords més llargs més tard. Llegeix cada entrada i pregunta si dues persones podrien interpretar l'èxit de manera diferent.

L'últim exemple no demostra la usabilitat per si mateix. Substitueix una frase vaga per una comprovació útil i limitada. Els objectius d'usabilitat més amplis poden necessitar investigació o diverses observacions consensuades.

Aneu amb compte també amb la precisió inventada. Afegir un requisit de resposta de dos segons sembla mesurable, però crea un compromís real. Acordeu les condicions i el motiu d'un llindar de rendiment abans d'incloure-lo.

Posa els criteris a Power Pack

Obriu el tiquet de Jira i cerqueu la targeta Definició de finalització i AC. Seleccioneu la pestanya Criteris d'acceptació. La seva llista és independent de la pestanya Definició de finalització, així que comproveu la pestanya seleccionada abans d'introduir contingut.

Per afegir un sol criteri, escriviu-ne el títol i seleccioneu Afegeix o premeu Intro. Utilitzeu títols concisos que encara conserven el resultat esperat. Si un criteri necessita un context ampli, manteniu aquest context a la descripció Jira o a la documentació enllaçada de l'equip.

Per a diverses entrades, seleccioneu Importació massiva i enganxeu una llista de vinyetes Markdown. Podeu copiar les entrades d'exemple anteriors, col·locant un guionet i un espai abans de cadascuna. També s'admeten les llistes de caselles de selecció de reducció.

Reviseu les entrades resultants després de la importació. L'acció s'afegeix a la llista actual, de manera que importar de nou la mateixa llista de verificació pot crear entrades ja presents. Les entrades de la casella de selecció Markdown marcades arriben marcades com a fetes; començar amb entrades no marcades tret que els resultats del tiquet actual hagin estat realment verificats.

Si una entrada és incorrecta, reviseu la redacció de substitució amb l'equip, afegiu l'entrada corregida i suprimiu l'obsoleta mitjançant el seu missatge de confirmació. Mantingueu clara la discussió de suport del tiquet quan un canvi afecti l'abast acordat.

Reviseu els resultats abans de marcar-los com a fets

Abans de la implementació, demaneu a algú implicat en la verificació que passi els criteris proposats. Poden detectar condicions inicials que falten o un resultat que no es pot observar amb la configuració de prova disponible.

Després de la implementació, verifiqueu cada resultat i registreu proves mitjançant el procés normal de documentació o Jira de l'equip. Seleccioneu el botó Fet d'un element quan hagi passat el resultat acordat. Si el tornes a seleccionar, torna a l’estat Pendent si una troballa posterior reobre la comprovació.

Per exemple, la preferència pot sobreviure a una recàrrega de la pàgina, però es restableix després d'un nou inici de sessió. El criteri de reobertura de la pàgina pot passar mentre el criteri de persistència de sessió segueixi incomplet. Les entrades separades conserven aquesta distinció útil.

Power Pack fa un seguiment de la finalització de la llista de verificació; no executa les proves ni estableix automàticament qui les va revisar. Si la revisió requereix una verificació amb nom o un resultat datat, registreu aquests detalls de manera explícita en el vostre procés normal.

Utilitzeu els dos recomptes sense confondre'ls com a prova

Els criteris d'acceptació i la definició de finalització mostren cadascun dels seus propis recomptes completats i totals. L'indicador de preparació només mostra Preparat per al llançament quan les dues llistes no estan buides i totes les entrades d'ambdues estan fetes. En cas contrari, es mostra En verificació.

Aquest és un resum de l'estat de la llista de verificació introduït. No pot establir que els criteris cobreixen tots els comportaments importants o que l'evidència de suport sigui sòlida. Tampoc fa complir les transicions de flux de treball de Jira ni les combinacions de bloqueig.

És possible que el nostre tiquet de notificació tingui tots els vuit criteris d'acceptació complets, mentre que la guia d'assistència continua sense acabar a Definició de finalització. Els resultats de les funcions han passat, però l'acord de finalització més ampli de l'equip encara té un tema obert.

Comenceu amb un proper tiquet de Jira. Escriviu el resultat del client, acordeu les condicions i resultats importants i, a continuació, afegiu els criteris a Power Pack juntament amb la definició compartida de fet. Reviseu la llista amb les persones que crearan i verificaran el canvi. El benefici és que hi hagi menys suposicions que s'amaguen darrere d'una frase que inicialment sonava evident.

• Atlassian — Què són els criteris d'acceptació?