Estándar de Proceso de Uso Aplicativo JIRA
 Warning: | IMPORTANTE: Este apartado explica el flujo de proceso y gestión de actividades a través de JIRA. No explica el funcionamiento de esta herramienta. Si desconoce los conceptos o necesita ampliar información, por favor acudir a la página oficial de JIRA https://es.atlassian.com/software/jira |
El JIRA es el software empleado para la gestión, seguimiento y control de las actividades de desarrollo y pruebas de un proyecto.
En el se puede registrar el avance que tiene cada miembro del equipo sobre las actividades del proyecto, en tiempo real, así como monitorear el esfuerzo realizado en cada una de estas actividades. Esto a fin de poder calcular su eficiencia en el desarrollo, generar evaluaciones sobre la capacidad de análisis de cada equipo, así como comparaciones de tiempos planificados vs el tiempo real para estimación de costos reales de los proyectos.
Las tareas/incidencias de JIRA son gestionadas únicamente por PM y QA, y la resolución de estas tareas/incidencias son responsabilidad exclusiva del equipo de desarrollo asignado al proyecto.
 | NOTA: Los nuevos ingresos (DEV/QA) podrán acceder al JIRA una vez estén activos en Proyecto, estos accesos son gestionados únicamente por PM. |
Sumario
- 1 Software estándar a utilizar
- 2 Flujo de proceso
- 2.1 1. Registro de Actividades y Activación de Sprint:
- 2.2 2. Actualización de Actividades en Tablero:
- 2.3 3. Registro de Tiempos en Actividades
- 2.4 4. Finalización de Desarrollo de HU/Requerimiento/CC, y Liberación a QA
- 2.5 3. Flujo de Validación y Corrección de Incidencias:
- 2.6 4. Atención y Resolución de Incidencias (Ticket):
- 2.7 5. Validación de Incidencias (Fin de Pruebas QA):
Software estándar a utilizar
Accede a JIRA haciendo click aquí
Flujo de proceso
En esta sección se describirá el flujo de proceso para un los proyectos en JIRA:
1. Registro de Actividades y Activación de Sprint:
- Registro de Actividades: Esta fase va enmarcada en el inicio de desarrollo del proyecto, CC o Requerimiento, y es cuándo PM da de alta las actividades (HU/Tareas/Subtareas) a fin de crear el Backlog de producto, estas actividades son las mismas que se tienen contempladas en el Cronograma de Proyecto tanto en descripción como en tiempo estimado.
| IMPORTANTE: Existen casos en los que no se cuenta con una tarea específica dentro del proyecto, para mapear los tiempos invertidos. Los requerimientos especiales, documentación, asignaciones internas para el área de TI etc, podrán ser mapeadas dentro de la tarea General Desarrollo en el tablero Interno-Telstock. Esta tarea no debe ser movida de estatus, sólo se empleará para registrar los tiempos y el detalle de lo realizado. |
Identifica las HU, Tareas y Subtareas con los siguientes íconos
| NOTA: Las actividades usualmente van asignadas a un responsable por defecto, sin embargo es posible que esto pueda variar durante el ciclo de desarrollo, por lo cuál cualquier desarrollador podrá acceder a todas las actividades existentes en el proyecto, y tendrá la libertad de realizarlas a fin de generar avance en el proyecto. |
- Creación y Activación del Sprint o Kanban: Una vez PM da de alta las actividades, será necesario que cree y active el Sprint o formalice la activación del Kanban (según corresponda). Para el caso de Sprint, se debe añadir las actividades que marcan el alcance y que están previamente registradas en el Backlog del Proyecto. Al iniciar o activar el Sprint, se debe indicar el rango de fechas en el que este estará vigente. Para el caso de Kanban, podrán agregarse las tareas generales y subtareas, de acuerdo al alcance mapeado para ese momento, no será necesario indicar inicio y fin en Jira.
- Notificación al Equipo: Al activar el Sprint/Kanban (inicio de trabajo), se debe enlazar el JIRA con el Slack a fin de activar la sincronización de notificaciones. Seguidamente, PM deberá notificar al equipo de trabajo a través del canal de Slack del Proyecto, que el tablero ha sido creado.
2. Actualización de Actividades en Tablero:
Los proyectos en JIRA podrán ser monitoreados de forma sencilla, a través de un tablero Kamban para el proyecto. En el, de acuerdo al estatus de una actividad en el momento de la actualización, se podrá obtener una vista rápida sobre el estado general del Sprint o Ciclo de Desarrollo, y las actividades que está realizando cada miembro del equipo.
El tablero estándar, contiene al menos 4 estados básicos para las tareas (el 5to estado es opcional):
1. To Do / Por Hacer:
* Se usa para Tareas/Subtareas/Incidencias.
* Este es el estado inicial de todas las actividades e incidencias que se dan de alta. Evidencia el conglomerado de trabajo por hacer que se tiene en un momento determinado.
2. In Progress / En Proceso:
* Se usa para Tareas/Subtareas/Incidencias.
* Una vez el responsable inicia una actividad (incidencia o tarea) debe moverla a este estatus. De esta forma evidencia a PM, Gerencia y equipo de trabajo, la tarea a la que está dando atención.
* Si una actividad fue iniciada y tiene un avance, pero luego se detuvo por bloqueo o por atender otra actividad, será necesario devolverla al estado To Do/ Por Hacer y agregar un comentario a la tarea indicando la razón. No es recomendable dejarla EN Proceso si no está siendo atendida, ya que esto afecta las métricas del desarrollador. .
| NOTA: Es una buena práctica colocar sólo aquellas tareas que en realidad se están trabajando. La finalidad del Kanban es ayudarnos a organizar nuestro trabajo por hacer, y evitar la sensación agotadora de realizar multitasking en los proyectos. |
3. Revisión/Pruebas:
* Se usa únicamente para Incidencias.
* Las incidencias registradas por QA y que hayan sido atendidas por el equipo de desarrollo y liberadas a ambiente de QA , se deben mover a este estado. UNICAMENTE CUÁNDO YA ESTÁN DESPLEGADAS EN AMBIENTE DE QA.
| NOTA: Al realizar el movimiento a este estado, es necesario añadir una nota a la tarea indicando al QA Manager y TESTER que la incidencia ya está lista para ser validada, y se deberá añadir evidencia (foto, vídeo etc) de las pruebas realizadas en ambiente dev, donde se pueda comprobar el funcionamiento correcto. |
| Warning: | IMPORTANTE: La resolución de las incidencias debe ir acompañada de una nueva ejecución de la Prueba Unitaria en TestLink, para ese caso en específico. Además, si lo amerita se debe actualizar la información necesaria para la ejecución de las pruebas por parte de QA. |
4. Done/Listo:
* Se usa para Tareas/Subtareas/Incidencias.
* Las actividades (tareas/subtareas/HU) naturales del Sprint, deberán ser movidas a este carril una vez el desarrollador haya finalizado su implementación. SÓLO APLICA PARA ACTIVIDADES DE TIPO TAREA/SUBTAREA/HU.
* Para el caso de las Incidencias (dadas de alta por QA) , estas sólo serán movidas a este estatus por el equipo de QA una vez hayan validado la corrección de la incidencia. El tester encargado de la validación deberá cargar las evidencias que soporten la validación exitosa de la incidencia, y añadir los comentarios de aprobación.
* Si una actividad fue concluida, pero luego fue necesario realizar algún cambio para ajustarla a algún flujo definido luego de su terminación, será necesario devolverla al estado EN Proceso y agregar un comentario indicando la razón. Este escenario NO aplica para los casos en que haya que hacer correcciones por ejecución de Pruebas Unitarias o Integración, ya que los tiempos de corrección deben quedar reflejados en las tareas directamente relacionadas a estas pruebas .
| Warning: | IMPORTANTE: Si el Error/Bug aún se genera, QA deberá añadir las evidencias a la misma Incidencia y un mensaje indicando que aún NO se ha realizado la corrección. La incidencia deberá ser movida al estatus 1. To Do / Por Hacer: |
| NOTA: En algunos casos, se contará con un estado adicional Desestimado , y será empleado para mover aquellas actividades que fueron desestimadas o no será necesario realizarlas para cubrir el alcance pautado. |
5. Desestimado:
* Se usa para Tareas/Subtareas/Incidencias.
* Las actividades (tareas/subtareas) naturales del Sprint o Ciclo, deberán ser movidas a este carril sólo en caso de que no sea necesario realizar dicha actividad, por cambio a nivel técnico (no fue necesario realizarla), porque se saco del alcance actual o porque no es una incidencia (esto debe ir respaldado con comentario de justificación y soporte del tester asignado). .
* Las actividades desestimadas, deberán tener un comentario añadido por el desarrollador/tester responsable, indicando la justificación detallada.
3. Registro de Tiempos en Actividades
A fin de poder hacer seguimiento de las actividades del proyecto, sacar métricas de desempeño por persona, así como estado general, es necesario que DIARIAMENTE se actualice el tiempo que se ha invertido en cada actividad.
| NOTA: La actualización debe hacerse aunque la tarea no se haya concluido, lo que se busca es poder llevar la bitácora del tiempo que se ha invertido. |
Las actividades tendrán tiempo inicial, el que se estimó al momento de realizar la fase de planificación. Este tiempo irá precargado (esto lo hace PM al dar de alta el Backlog) en cada actividad, y será el valor empleado para poder realizar la comparación del Tiempo Planeado vs Tiempo Real y poder generar los cálculos respectivos del ciclo.
| Warning: | IMPORTANTE: En el caso de las Incidencias, estas no tendrán tiempo de planificación, pero SI deberán ser actualizadas diariamente, por tester y desarrollador, y realizar el registro de tiempo invertido (Log Time), de forma similar a la explicada más adelante. |
Para el registro de trabajo se utiliza el gestor de tiempos TEMPO.
A continuación se mostrará la forma como se deberá realizar la carga:
| Warning: | IMPORTANTE: Es de carácter OBLIGATORIO la actualización diaria de las tareas del JIRA, así como el registro de tiempo REAL/Log Time invertido. Recuerde que la demora en la realización de una actividad es mapeada a través de los Dailys del proyecto, por lo cual estos tiempos debe coincidir con la información suministrada a PM. |
Click aquí -> ***** Registro de tiempos de actividades con TEMPO *****
4. Finalización de Desarrollo de HU/Requerimiento/CC, y Liberación a QA
El listado de actividades definidas para una HU/ Requerimiento/ CC , son las que determinan el % de avance que tiene esta en un momento determinado. Al terminar todas las actividades (Estatus Done/Listo) contempladas, indica la conclusión de la HU/ Requerimiento/ CC en sí.
| NOTA: Las Pruebas Unitarias también forman parte del alcance, si están no se han realizado la HU/ Requerimiento/ CC o alcance no ha sido completado. |
Es importante validar que al finalizar las actividades de una HU/ Requerimiento/ CC, esta última pasé a estatus de "Listo", si no es así, deberá realizarlo de forma manual.
| NOTA: De acuerdo a la planificación del proyecto, podremos liberar a QA las HU/Requerimiento/CC que se van completando de forma progresiva a lo largo de la fase de desarrollo, o bien realizar una única liberación con el conglomerado. Esto dependerá de la definición inicial del proyecto |
* El proceso de Pruebas Unitarias y Pruebas de Integración debe quedar documentado a través del TestLink.
| NOTA: Para garantizar la transparencia y calidad de las pruebas de integración que se realizan, será necesario que el LT del proyecto abra una llamada en el canal oficial del proyecto para garantizar que el equipo completo está participando en el flujo de integración. Además, cualquier interesado del proyecto (PO, QA, PM etc) podrán unirse a la llamada como "observadores". |
* El Líder Técnico del proyecto generará el reporte de Pruebas Unitarias y Pruebas de Integración en formato de archivo PDF y lo incluirá en el repositorio de Telstock en la ubicación que corresponda al proyecto.
* Una vez que el proceso de las Pruebas Unitarias y Pruebas de Integración sea correcto, el equipo procederá desplegar al ambiente de QA.
Para todos los casos en que se vaya a realizar una liberación a QA, será necesario realizar una conferencia por el canal del proyecto para ejecutar las pruebas humo del equipo dev al equipo de QA. Lo que se busca con esto, es comprobar que la liberación al ambiente fue correcta y que QA cuenta con el ambiente totalmente funcional, para iniciar el flujo de pruebas. Luego de esto, el LT deberá añadir la información de pruebas a la actividad designada para esto. Ver Liberación a QA .
| IMPORTANTE: La conferencia de entrega a QA, NO ES UN REVIEW, por lo cuál la duración de la conferencia no debe ser mayor a 30 minutos, y el equipo dev sólo deberá concentrarse en la demostración del flujo base del sistema. Esta sesión NO es para aclarar dudas o lógicas del sistema, a menos que se evidencie alguna inconsistencia con relación al requerimiento y al funcionamiento que se muestra. Se considera que en este punto, todos los involucrados del proyecto, están totalmente claros de funcionamiento que deberá tener el mismo. |
3. Flujo de Validación y Corrección de Incidencias:
Una vez se libera al ambiente de Pruebas, el equipo de QA da inicio al proceso de validación de funcionalidad, de acuerdo al alcance especificado en las HU/ Requerimiento/ CC. Los escenarios que ejecuta QA, deben estar documentados y dados de alta previamente, a través del TestLink.
El equipo de QA deberá tomar en cuenta los siguientes aspectos:
1. Validar información de pruebas: El equipo de QA debe verificar que la información indicada en la tarea de liberación, sea real y suficiente para dar inicio al ciclo de validaciones. Además de asegurarse de tener clara la funcionalidad que se debe probar, y las pruebas a realizar. Para esto, es necesario que se apoye en la documentación del proyecto y en el equipo de trabajo en general.
2. Validar la correcta ejecución de Pruebas Unitarias y Pruebas de Integración: El equipo de QA debe verificar, antes de dar inicio a la sesión de pruebas, que el equipo de desarrollo ejecutó de manera correcta y completa las pruebas unitarias y de integración, de la(s) HU liberada(s). De esta forma se asegura que el primer nivel de validación ha sido cubierto, y que la HU cuenta con los requisitos mínimos para ser probada en un siguiente nivel.
3. Proceso de ejecución de sesión de pruebas: Lo que buscamos al generar sesiones de pruebas es crear un registro que permita ver el histórico de pruebas ejecutadas para un Sprint, Ciclo, HU, CC, Incidencia etc, y enlazar a esta, las incidencias que se generen de dicha ejecución.
Para realizar la ejecución de las sesiones de prueba, el equipo de QA debe cumplir con los siguientes procesos:
A. Enviar el estado de las pruebas a través del RAP: de esta forma el equipo de trabajo y observadores del proyecto, estará en contexto del estado actual del ciclo de pruebas. El envío de esta información deberá ser diario (a primera hora de la jornada laboral), a fin de garantizar la claridad en las actividades que se están realizando y facilitar el seguimiento del estatus de pruebas.
| NOTA: Los Viernes antes de las 4.00 es necesario enviar el RAITE por correo electrónico a PM, para poder generar los reportes a directiva con los avances reales de pruebas y estatus. Este reporte deberá contener el estatus real de pruebas, incidencias, mejoras etc. |
B. Enlazar las Incidencias a la HU/Requerimiento/Tarea/Subtarea que Corresponda: de esta forma el seguimiento de las incidencias será mucho más fácil para el equipo de desarrollo y PM. Además de que permitirá identificar de forma más sencilla, el flujo funcional y el contexto en el que sucede dicha incidencia. Además, permitirá obtener información rápida, sobre el o los responsables, para generación de métricas de proyecto etc.
C. Generar Incidencias Completas: las incidencias generadas para cada funcionalidad, deben contener la información clara y precisa en todos los campos de su registro. Esto implica que se debe colocar nombres descriptivos y que definan a primera vista, el error que se genera, e ir acompañado de la Descripción Paso a Paso para replicar el escenario, además de las evidencias claras del error que se genera (imágenes con indicaciones, vídeos etc).
En el campo Descripción, se debe colocar la liga del escenario de pruebas Padre de TestLink (ejecutado y con evidencias) para que el desarrollador se remita directamente a este, y tenga el contexto de la funcionalidad.
D. Asociar las Incidencias al Componente de Pruebas: permitiendo clasificar las incidencias según el Sprint o ciclo de pruebas al que pertenece.
| NOTA: Al principio de cada Sprint o Ciclo de desarrollo, se creará y compartirá el componente donde se deberán concentrar las incidencias relacionadas al alcance del Ciclo/Sprint. |
4. Atención y Resolución de Incidencias (Ticket):
El proceso de Atención para las Incidencias debe llevarse de acuerdo al flujo especificado en el punto === 2. Actualización de Actividades en Tablero: === en adelante
| NOTA: La atención y resolución de las incidencias de la fase de desarrollo, por parte del equipo de DEV, deben realizarse dentro de los tiempos del proyecto. |
| QA debe establecer los limites y duración de sus pruebas, dentro del tiempo inicial estimado. |
5. Validación de Incidencias (Fin de Pruebas QA):
Una vez que todas las incidencias han sido atendidas y resueltas ( las Incidencias deben estar en Done/Listo), y que se ha finalizado exitosamente las pruebas de regresión finales, QA procederá a realizar lo que se describe a continuación:
a. Validar la actualización de todos los escenarios del TestLink. Todas las categorías de pruebas deben estar al 100% ejecutadas
b. Exportar la Matriz y Reporte de Pruebas de QA del TestLink y subirla al repositorio del proyecto, con el identificador del documento que corresponda.
c. Notificar por Correo Electrónico la culminación del ciclo de pruebas, y la ejecución exitosa de todos los casos diseñados según el alcance. Emitir el VoBo formal de finalización y aprobación de parte de QA Manager, y adjuntar las evidencias (RAITE).
| NOTA: La notificación formal y VoBo de Pruebas, deberá hacerse con copia a todos los involucrados del proyecto, incluyendo PM, Coordinadores y Directores de TI |
| Warning: | NOTA: Si la notificación no se ha enviado de forma oficial, no se considerará que ya se tiene el VoBo del área, por lo cuál los procesos y/o flujos que dependan de esto, no podrán ser ejecutados. |
