Definició de finalització a Jira: acordeu què significa "acabat".

Un enginyer acaba un canvi i avança el tiquet de Jira. Un verificador descobreix que la nova pantalla funciona, però un flux existent s'ha trencat. El servei d'atenció al client s'assabenta del canvi d'un client confús. Tothom va utilitzar la paraula acabat, però cada persona volia dir alguna cosa diferent.

Una definició de finalització proporciona a l'equip un estàndard de finalització compartit. Fa visibles els controls de qualitat esperats abans de començar el treball, de manera que la revisió depèn menys de qui recordi fer la pregunta correcta.

En aquesta guia, crearem un exemple per a un equip de portal de client fictici, distingirem les comprovacions de qualitat compartides dels criteris d'acceptació específics de les funcions i les posarem ambdues al costat d'un tiquet de Jira mitjançant l'eina Definició de finalització i AC de Power Pack.

Què és una definició de finalització?

La Guia Scrum descriu la definició de finalització com l'estàndard de qualitat que ha de complir un increment. Proporciona una comprensió compartida del treball realitzat. Quan una organització ha establert un estàndard, aquest és el mínim per als seus equips Scrum. Consulteu la guia oficial de Scrum.

Per al nostre exemple pràctic, penseu-hi com un petit conjunt de preguntes que l'equip fa sobre cada canvi rellevant. S'ha revisat la implementació? Han passat els controls de verificació acordats? Està disponible la informació que la gent necessita per donar suport al canvi?

Les preguntes exactes depenen del producte i dels seus riscos. Un portal públic de clients, un informe intern i un sistema crític per a la seguretat necessiten estàndards diferents. Copiar la llista de comprovació d'un altre equip sense discussió pot deixar buits importants mentre s'afegeix un treball que no serveix per a res.

Un estàndard útil descriu un resultat observable. "Alta qualitat" expressa una ambició. "Les comprovacions de regressió acordades han passat, amb resultats vinculats al tiquet de Jira" descriu alguna cosa que un revisor pot inspeccionar.

Separeu la qualitat compartida del comportament de les funcions

El nostre equip fictici està afegint preferències de notificació. Els clients podran activar o desactivar un correu electrònic de resum setmanal. Els missatges importants del compte romanen fora d'aquesta preferència.

La característica necessita els seus propis criteris d'acceptació. Per exemple, una opció desada encara ha d'aparèixer després que el client tanqui la sessió i torni. Aquest requisit pertany a aquesta característica perquè descriu el que hauria d'experimentar el client.

La definició de finalització cobreix l'estàndard de finalització més ampli. La revisió de la implementació, la comprovació del comportament existent afectat i l'actualització de les instruccions d'assistència poden aplicar-se a molts canvis diferents.

Les dues llistes importen. Una funció pot comportar-se com es demana mentre falta un treball de qualitat essencial. De la mateixa manera, el codi revisat i les comprovacions de regressió aprovades no estableixen que la funció sol·licitada es comporta correctament.

Comenceu amb els buits que realment veu el vostre equip

Feu una breu discussió a les persones que construeixen, verifiquen i donen suport al producte. Utilitzeu un exemple recent de treball que semblava complet però que necessitava un seguiment inesperat.

El nostre equip del portal identifica tres problemes recurrents. Els comentaris de la revisió de vegades romanen sense resoldre. Les opcions de configuració del compte existents reben poca cobertura de regressió. Les instruccions d'assistència arriben després que la funció estigui disponible.

Aquests problemes suggereixen comprovacions útils. També donen a l'equip una raó per mantenir l'estàndard curt: cada entrada hauria d'evitar una fallada reconeixible o establir una condició de qualitat necessària.

Pregunteu com algú verificarà cada entrada proposada. Si ningú pot descriure l'evidència, milloreu la redacció abans d'adoptar-la. "Documentació completa" podria fer referència a notes de versió, notes de disseny intern o un article d'ajuda al client. Acordeu quina informació es necessita i on pertany.

Acordeu també qui normalment realitza les comprovacions. Aquesta conversa pot tenir lloc en el vostre procés de planificació habitual. Una llista de verificació per si sola no assigna un revisor ni reserva temps al calendari d'algú.

Elaborar una llista pràctica compartida

Aquí teniu el primer esborrany de l'equip del portal. És un acord de treball il·lustratiu, no una norma universal.

• La revisió de la implementació s'ha completat i s'han resolt els comentaris de revisió requerits.
• S'han verificat els criteris d'acceptació acordats del tiquet.
• Les comprovacions de regressió acordades per als fluxos de compte afectats s’han superat.
• Les comprovacions d’accessibilitat acordades per a les pantalles modificades s’han superat.
• La guia d'assistència reflecteix el canvi de comportament del client.
• Els resultats de la verificació i els enllaços de revisió rellevants es registren al tiquet de Jira.

Abans d'utilitzar aquesta llista de verificació, l'equip anota què inclouen les seves comprovacions de regressió i accessibilitat. En cas contrari, dues persones podrien marcar la mateixa frase després de fer un treball diferent.

Per al portal, el conjunt de regressió acordat inclou iniciar sessió, obrir la configuració del compte i actualitzar un camp de perfil existent. La revisió d'accessibilitat dels controls canviats inclou el funcionament del teclat, l'enfocament visible i etiquetes comprensibles. Aquests són exemples de les comprovacions escollides per aquest equip, no un estàndard d'accessibilitat complet.

L'entrada de suport també necessita una interpretació pràctica. Si un canvi no té efectes sobre el client, l'equip hauria d'establir un estàndard adequat per a aquest tipus de treball amb antelació. Eviteu fer que els revisors improvisin excepcions només per convertir una llista en verd.

Afegiu l'estàndard a un tiquet de Jira

Obriu el tiquet de Jira rellevant i cerqueu la targeta Definició de finalització i AC de Power Pack. Conté pestanyes separades de Criteris d'acceptació i Definició de finalització. Seleccioneu Definició de finalització abans d'afegir les comprovacions compartides.

Per obtenir una llista petita, introduïu el títol d'una comprovació i seleccioneu Afegeix o premeu Intro. Manteniu cada títol centrat en una condició revisable. Una frase llarga que conté tres comprovacions no relacionats fa que la finalització parcial sigui difícil de representar.

També podeu seleccionar Importació massiva i enganxar una llista de reducció. Per exemple, enganxeu les sis entrades de pic anteriors amb un guionet i un espai al començament de cada línia. Les entrades de caselles de selecció normals de Markdown són una altra opció compatible.

Importar afegeix entrades a la pestanya seleccionada. Comproveu la pestanya abans de confirmar i inspeccioneu la llista resultant després. Si torneu a importar el mateix contingut, podeu afegir entrades que ja existeixen, així que utilitzeu-lo deliberadament en lloc d'una acció d'actualització.

Utilitzeu entrades sense marcar per a treballs que encara no s'han verificat. Les entrades de la casella de selecció Markdown marcades s'importen tal com s'han fet; les marques de verificació copiades d'un tiquet anterior no haurien de substituir la revisió del canvi actual.

L’estàndard acordat s’ha d’afegir manualment a cada tiquet pertinent. Conserveu una còpia de referència a la documentació normal de l'equip i enganxeu les comprovacions adequades als tiquets nous. Aquest procés és una pràctica d'equip, no una connexió automàtica entre un estàndard central i cada tiquet.

Passa per una revisió real

Suposem que la funció de preferències de notificació està preparada per a la revisió. Maya comprova els resultats del client mentre Priya verifica el conjunt de regressió acordat. Leo resol els comentaris de revisió d'implementació restants i enllaça el registre de revisió.

La primera passada revela que la preferència es desa correctament, però el focus del teclat desapareix després de seleccionar Desa. L'equip deixa la comprovació d'accessibilitat incompleta, registra el problema a la seva discussió Jira normal i el soluciona abans de repetir la comprovació corresponent.

La guia de suport també està inacabada. Això segueix sent visible tot i que els criteris d'acceptació específics de les funcions estan complets. Les llistes separades ajuden a explicar per què l'equip encara té feina per fer.

Després d'haver passat una comprovació, seleccioneu el seu botó Fet. Torneu a seleccionar-lo si la informació nova significa que l’element hauria de tornar a l’estat Pendent. Enregistreu els resultats de les proves, els enllaços de revisió i les decisions importants mitjançant el procés normal de documentació o Jira de l'equip.

Un ítem completat registra el judici de l'equip. No realitza la comprovació, recull les seves proves ni estableix qui va realitzar la verificació. Si la identitat del revisor o el temps són importants, registreu aquesta informació explícitament al vostre procés de revisió habitual.

Llegiu atentament l'indicador de preparació

L'eina mostra els recomptes completats i totals per a cada pestanya. El seu indicador de preparació només mostra Preparat per al llançament quan ambdues llistes contenen almenys un element i tots els elements d'ambdues llistes estan fets. En cas contrari, es mostra En verificació.

Aquesta regla fa que l'indicador sigui útil per detectar entrades sense acabar. També explica per què una llista completada de Definició de finalització no produeix l'estat complet mentre que Criteris d'acceptació roman buit.

Tracteu la redacció com un resum de l'estat de la llista de verificació. No prova que els controls fossin suficients, que les proves fossin persuasives o que el producte sigui segur de llançar. Un equip pot marcar una comprovació mal escrit com a complet amb la mateixa facilitat que un de útil.

La llista de verificació tampoc bloqueja una transició Jira ni una fusió de sol·licitud d'extracció. Continueu utilitzant el procés de lliurament i llançament normal de l'equip per prendre aquestes decisions.

Mantenir l'estàndard útil a mesura que canvia el treball

Reviseu l'estàndard quan un defecte repetit exposa una comprovació que falta, quan el producte canvia substancialment o quan una comprovació existent deixa de proporcionar informació útil.

Per exemple, l'equip del portal pot descobrir que els canvis de preferències funcionen immediatament però que fallen després d'una sincronització retardada. Aquesta troballa podria conduir a una regla de verificació més àmplia per a funcions que depenen del processament retardat. L'equip ha de decidir primer a quins canvis s'aplica i quines proves demostraran l'èxit.

Actualitzeu l'estàndard de referència i discutiu com aplicar el canvi al treball que ja està en curs. Les llistes de tiquets existents no hereten aquesta revisió automàticament. Inspeccioneu els tiquets afectats i afegiu les comprovacions recentment acordades manualment, si escau.

Eviteu ampliar la llista de verificació després de cada error aïllat. De vegades, la millor resposta és un criteri d'acceptació específic, una tasca d'implementació més clara o un canvi en el procés de revisió. L'estàndard compartit hauria de seguir sent quelcom que l'equip pugui entendre i aplicar realment.

Proveu-ho amb un tiquet actual

Trieu un tiquet que s'aproxima a la revisió. Acordeu un breu estàndard de qualitat compartit, col·loqueu-lo a la pestanya Definició de finalització i afegiu els resultats específics per al client d’aquest tiquet a Criteris d'acceptació.

Recorreu les comprovacions junts i enllaceu les proves on el vostre equip les registra normalment. Marqueu les entrades com a fetes només després de la verificació i, a continuació, reviseu el treball restant mitjançant el vostre procés de lliurament habitual.

El resultat útil és una conversa més clara. Quan algú diu que s'ha acabat el canvi de preferències de notificació, l'equip pot explicar quins resultats funcionen, quins controls de qualitat s'han aprovat i d'on va sortir aquesta conclusió.

• La guia Scrum — Definició de finalització