Una sol·licitud de funció tardana arriba abans del llançament: avalueu el canvi a Jira
Avalueu una sol·licitud de funció tardana a Jira examinant els criteris d'acceptació canviats, les responsabilitats, els riscos i l'abast de la revisió amb Power Pack.
El portal del client s'acosta al llançament quan algú demana una capacitat més: deixeu que els administradors de l'espai de treball convidin diversos companys d'equip alhora.
La sol·licitud s’assembla a una cosa que l'equip ja ha creat. Els administradors poden convidar companys d'equip avui. L'equip podria simplement ampliar-lo abans del llançament?
Abans d'estimar el canvi, inspeccioneu l'acord que alteraria. Aquest tutorial utilitza Power Pack per ajudar un equip a identificar el resultat del client afectat, les persones, els riscos i les revisions abans de triar com gestionar la sol·licitud.
La sol·licitud d'invitació massiva és una continuació fictícia de la demostració del Portal del client 2.0. Les captures de pantalla mostren l'estat de mostra existent abans d'aquest canvi proposat; no mostren una funció d'invitació massiva ni una avaluació de canvis completada.
Anoteu la diferència amb l'abast actual
A la visualització de Criteris d'acceptació existent, està marcat "Els administradors de l'espai de treball poden convidar companys d'equip i assignar rols d'accés". Aquesta frase no ens diu si l'equip va verificar invitacions individuals, invitacions massives o totes dues.
L'equip comprova primer el seu abast i evidència originals. Per al nostre exemple, suposem que els cobreixen una invitació a la vegada. La nova sol·licitud afegiria diverses adreces en una operació.
Ara pregunteu què hauria d'observar un revisor. L'administrador pot triar diferents rols? Què hauria de passar si una adreça no és vàlida? Com s'ha d'explicar un resultat parcial? Aquestes són preguntes obertes per a aquesta funció de ficció, no els requisits que ja es mostren a la captura de pantalla.
Captureu els resultats proposats per separat mentre l'equip considera la sol·licitud. No amplieu silenciosament un criteri completat i deixeu que la marca de verificació antiga impliqui que el comportament afegit ha passat.
Identificar la feina de qui canvia
La matriu de responsabilitat inclou la incorporació del client i l'accés segur al compte. Tots dos són llocs assenyats per començar la discussió sobre l'impacte: la sol·licitud modifica una acció d'incorporació i pot afectar la manera com s'assignen els rols.
Pregunteu a les persones responsables sobre el treball d'implementació i verificació i, a continuació, pregunteu al responsable final sobre el resultat previst i el moment. Comproveu també si les instruccions de suport o el treball d'un altre equip canviarien.
Utilitzeu la discussió per crear o perfeccionar el treball Jira necessari. Una nova fila o assignació de rol a Power Pack és un acord de treball; no programa la tasca per a l'equip.
Discutiu un escenari concret de fallada
La graella de riscos ofereix un lloc per considerar què podria sortir malament. La demostració actual mostra tres riscos de mostra en una matriu 3×3. Els llocs existents no valoren la nova sol·licitud d'invitació.
Una qüestió a investigar és si un lot parcialment reeixit podria deixar l'administrador incert sobre qui va rebre una invitació. Una altra és si la nova interacció podria facilitar les assignacions de rols no desitjades.
Descriu l'esdeveniment plausible, la seva conseqüència i l'evidència necessària per avaluar-lo. L'equip hauria d'avaluar la probabilitat i l'impacte del seu disseny i conclusions reals. El mapa de calor no pot proporcionar aquest judici a partir del títol de la funció.
Trieu un camí i actualitzeu l'acord
L'equip té diverses respostes possibles: incloure la sol·licitud amb abast revisat i verificació, oferir un canvi acordat més petit o programar-lo després del llançament. Compareu aquestes opcions amb el treball i la incertesa descobertes a la discussió.
Suposem que aquest equip de ficció tria un llançament posterior. Enregistreu per què, creeu el treball de seguiment i preserveu l'abast de la versió actual. Si l'equip inclou el canvi, reviseu els criteris afectats, les responsabilitats de lliurament, el material de suport i reviseu els àmbits conjuntament. Identifiqueu qualsevol comprovació o aprovació completada que ara necessiti una altra mirada.
El resultat útil és una decisió amb conseqüències visibles. L'equip pot explicar què canviarà, qui farà la feina i què s'ha de revisar de nou.
Proveu aquest procés a la següent sol·licitud "petita" que arribi prop del llançament. Exploreu Power Pack per a Jira i utilitzeu el context del tiquet existent per concretar la discussió del canvi abans de comprometre's amb el lliurament.
Articles relacionats
Com escriure criteris d'acceptació a Jira, amb exemples pràctics
Converteix una sol·licitud de funció Jira en resultats clars i comprovables amb un exemple de preferències de notificació treballat.
Executeu un pre-mortem a Jira: cerqueu riscos de llançament abans que passin
Imagineu que el vostre llançament ha fallat i, a continuació, convertiu els motius en accions pròpies. Creeu una graella de risc i pre-mortem pràctica juntament amb un tiquet de Jira.
Gestioneu les aprovacions de les parts interessades a Jira: deixeu clar l'estat d'aprovació
Doneu a cada part interessada la revisió d'un abast clar, un aprovador designat i un estat visible. Manteniu les aprovacions comprensibles a mesura que canvia el treball de llançament.
Parlem-ne
Tens preguntes sobre aquest article? Parlem dels teus objectius tècnics.