Llega una petición de funcionalidad justo antes del lanzamiento: evalúa el cambio en Jira
Evalúa una petición tardía de funcionalidad en Jira examinando con Power Pack los cambios en los criterios de aceptación, las responsabilidades, los riesgos y el alcance de la revisión.
El portal del cliente se acerca al lanzamiento cuando alguien pide una capacidad más: permitir a los administradores del espacio de trabajo invitar a varios compañeros a la vez.
La petición se parece a algo que el equipo ya ha construido. Los administradores ya pueden invitar a compañeros. ¿Podría el equipo simplemente ampliarlo antes del lanzamiento?
Antes de estimar el cambio, examina el acuerdo que modificaría. Este recorrido utiliza Power Pack para ayudar al equipo a identificar el resultado para el cliente, las personas, los riesgos y las revisiones afectados antes de decidir cómo abordar la petición.
La petición de invitaciones masivas es una continuación ficticia de la demostración Customer Portal 2.0. Las capturas muestran el estado de ejemplo existente antes de este cambio propuesto; no muestran una función de invitaciones masivas ni una evaluación del cambio completada.
Anota la diferencia respecto al alcance actual
En la vista existente de Criterios de aceptación, «Los administradores del espacio de trabajo pueden invitar a compañeros y asignar roles de acceso» está marcado. Esa frase no indica si el equipo verificó invitaciones individuales, masivas o ambas.
El equipo comprueba primero su alcance original y las pruebas. En nuestro ejemplo, supongamos que cubrían una invitación cada vez. La nueva petición añadiría varias direcciones en una sola operación.
Pregunta ahora qué tendría que observar un revisor. ¿Puede el administrador elegir roles diferentes? ¿Qué debe ocurrir si una dirección no es válida? ¿Cómo debe explicarse un resultado parcial? Son preguntas abiertas para esta funcionalidad ficticia, no requisitos que ya aparezcan en la captura.
Registra los resultados propuestos por separado mientras el equipo considera la petición. No amplíes silenciosamente un criterio completado dejando que la marca antigua sugiera que el comportamiento añadido ha superado la comprobación.
Identifica de quién cambia el trabajo
La matriz de responsabilidades incluye la incorporación de clientes y el acceso seguro a cuentas. Ambos son puntos razonables para comenzar a hablar del impacto: la petición cambia una acción de incorporación y puede afectar a la asignación de roles.
Pregunta a quienes ejecutan el trabajo por la implementación y la verificación; después, a quien tiene la responsabilidad final por el resultado esperado y los plazos. Comprueba también si cambiarían las instrucciones de soporte o el trabajo de otro equipo.
Utiliza la conversación para crear o precisar el trabajo necesario en Jira. Una nueva fila o asignación de rol en Power Pack es un acuerdo de trabajo; no programa la tarea para el equipo.
Hablad de un escenario de fallo concreto
La cuadrícula de riesgos ofrece un lugar para considerar qué podría salir mal. La demostración actual muestra tres riesgos de ejemplo en una matriz de 3×3. Esas posiciones existentes no evalúan la nueva petición de invitaciones.
Una cuestión que investigar es si un lote parcialmente exitoso podría dejar al administrador sin saber quién recibió una invitación. Otra es si la nueva interacción podría facilitar asignaciones involuntarias de roles.
Describe el suceso plausible, su consecuencia y las pruebas necesarias para evaluarlo. El equipo debe valorar la probabilidad y el impacto a partir de su diseño real y sus hallazgos. El mapa de calor no puede aportar ese juicio a partir del título de la funcionalidad.
Elige un camino y actualiza el acuerdo
El equipo tiene varias respuestas posibles: incluir la petición con un alcance y una verificación revisados, ofrecer un cambio menor acordado o programarla para después del lanzamiento. Compara estas opciones con el trabajo y la incertidumbre descubiertos en la conversación.
Supongamos que este equipo ficticio elige una versión posterior. Registra el motivo, crea el trabajo de seguimiento y conserva el alcance de la versión actual. Si, en cambio, el equipo incluye el cambio, revisa conjuntamente los criterios afectados, las responsabilidades de entrega, el material de soporte y los ámbitos de revisión. Identifica las comprobaciones completadas o aprobaciones que ahora deban revisarse de nuevo.
El resultado útil es una decisión con consecuencias visibles. El equipo puede explicar qué cambiará, quién hará el trabajo y qué deberá revisarse otra vez.
Prueba este proceso con la próxima petición «pequeña» que llegue cerca del lanzamiento. Explora Power Pack para Jira y utiliza el contexto de la incidencia existente para concretar la conversación sobre el cambio antes de comprometerte a entregarlo.
Artículos relacionados
Cómo escribir criterios de aceptación en Jira, con ejemplos prácticos
Convierte una solicitud de funcionalidad de Jira en resultados claros y verificables con un ejemplo desarrollado de preferencias de notificaciones.
Haz un análisis premortem en Jira: detecta los riesgos del lanzamiento antes de que ocurran
Imagina que tu lanzamiento ha fallado y convierte las causas en acciones con responsables. Crea un premortem y una matriz de riesgos prácticos junto a una incidencia de Jira.
Gestiona las aprobaciones de las partes interesadas en Jira: aclara su estado
Da a cada revisión un alcance claro, una persona que apruebe y un estado visible. Mantén comprensibles las aprobaciones a medida que cambia el trabajo del lanzamiento.
Hablemos
¿Tienes preguntas sobre este artículo? Hablemos de tus objetivos técnicos.