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.

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.

 Identifica las  HU, Tareas y Subtareas con los siguientes íconos

Iconos Jira

• 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. .

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. 

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:

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.

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í.

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.

* El proceso de Pruebas Unitarias y Pruebas de Integración debe quedar documentado a través del TestLink.

* 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 .

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.

        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.

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

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).
    

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.