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 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: Una vez PM da de alta las actividades, será necesario que cree y active el Sprint. Para esto debe añadir las actividades que marcan el alcance del sprint 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.

• Notificación al Equipo: Al activar el Sprint en JIRA, 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 de Desarrollo 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 y las actividades que está realizando cada miembro del equipo.

El tablero estándar, contiene 4 estados básicos para las tareas:

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.  

1. In Progress / En Proceso:

      * Se usa para Tareas/Subtareas/Incidencias.
      * Una vez el desarrollador 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. 

1. 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 DESPLIEGADAS 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 sesión de pruebas del JIRA, con la información necesaria para la ejecución de las pruebas por parte de QA.

1. Done/Listo:

      * Se usa para Tareas/Subtareas/Incidencias.

Una vez dada de alta la solicitud:

    El Gestor de proyectos realiza una revisión de toda la información contenida en el Ticket.
    
    Si considera que la información proporcionada es insuficiente: 

    a. Cambiará el estado del Ticket a SE NECESITAN MAS DATOS en el Mantis.
    b. Añadirá una nota etiquetando al STAKEHOLDER que registró el Ticket, para indicarle el detalle de la información que hace falta.
    
    En caso contrario a lo descrito anteriormente:

    a. Cambiará el estado del Ticket a ACEPTADO o asignará el Ticket a un Desarrollador en el Mantis.

Warning:

IMPORTANTE: La atención a las solicitudes dependerá de su prioridad, y de la disponibilidad de desarrolladores.

3. Asignación de la solicitud (Ticket):

    La asignación de una solicitud de CC puede ser realizada por:
    
    Desarrollador:
    Se define ( Auto asignación ). Lo que se busca con esto es fomentar la iniciativa del Desarrollador, su capacidad de Autogestión y de Autorganizacion. Es importante que el Desarrollador antes de asignarse una solicitud (Ticket) considere los siguientes aspectos:

    a. No tener actividades mapeadas en un Sprint o Cronograma activo de mayor relevancia o prioridad.
    b. Que se tenga conocimiento del aplicativo bajo el cual fue registrada la solicitud, en caso de que sean solicitudes de CC de prioridad Alta. Esto para evitar que exista desviación de tiempo por desconocimiento de la plataforma/tecnología/reglas de negocio. 
     
     Si son solicitudes de CC de prioridad Normal o Baja, el Desarrollador puede asignarse la solicitud (Ticket) aunque no tenga conocimiento del proyecto, para este caso sera necesario que valide con el Gestor o Coordinador de proyectos si puede tomar esta actividad.
       
    Gestor de proyectos/Coordinador de proyectos:
    a. Esta asignación se hace directamente por cualquiera de los roles antes mencionados y se realiza de acuerdo a la prioridad que tenga el Ticket.
    

4. Análisis de la solicitud (Ticket):

    Una vez que la solicitud fue Auto Asignada o recibió Asignación directa por el Gestor o el Coordinador de proyectos,  
    el Desarrollador procederá a realizar lo que se describe a continuación:  
  
    a. Documentar el campo Descripción técnica en el Mantis, realizando un previo análisis de los artefactos que van a sufrir cambios.
       Es necesario que liste los artefactos como pueden ser:
       * Clases
       * Métodos
       * Base de datos:
            * Procedimientos
            * Tablas
            * Vistas
            * Funciones
       Que van a ser modificados a nivel de código fuente.  
     
    b. Recurrir al Gestor o Coordinador de proyectos, cuando implique cambios a otras áreas de desarrollo (Web Service, Back Office, etc). A fin de que ellos puedan asignar un desarrollador adicional, para que apoye en el área que corresponda. 

    c. Documentar en el campo Tiempo estimado los tiempos que se van a utilizar para la solución del CC, tomando en cuenta:
       * Tiempo de Desarrollo de áreas involucradas.
       * Pruebas Unitarias.
       * Pruebas de Integración. (Para los casos en que aplique)      
    d. El área de QA debe documentar en el campo Tiempo estimado QA, los tiempos de pruebas a realizar de acuerdo a la información que se tenga en la solicitud de CC. Si este campo no esta documentado, el Gestor de proyectos solicitará al área de QA que documente sus tiempos estimados de pruebas de QA.
       

5. Aprobación de la solicitud (Ticket):

     Una solicitud de control de cambio es APROBADA cuando aparece en el campo Aprobado la palabra SI
    
    Una vez que se tiene la información en los campos Descripción técnica y Tiempo estimado, el Gestor de proyectos solicita la  aprobación del control de cambio a la Directiva para su resolución.
    
    La Directiva revisa la solicitud del control de cambio en el Mantis para aprobarlo o no.
    
    

6. Resolución de la solicitud (Ticket):

    Una vez que la solicitud del control de cambio ha sido APROBADA, el Desarrollador procederá a realizar lo que se describe a  continuación:
    a. Llevar a cabo la implementación de la solución del CC, de acuerdo a la información registrada en el campo Descripción.
    b. Una vez que haya realizado el desarrollo, realizará el proceso de las Pruebas Unitarias y Pruebas de Integración
       a través del TestLink.
    c. Generará el reporte de Pruebas Unitarias en formato de archivo PDF y lo incluirá en el repositorio de
       Telstock en la ubicación que corresponda al proyecto.
    d. Una vez que el proceso de las Pruebas Unitarias y Pruebas de Integración sea correcto, el Desarrollador procederá al despliegue de los cambios a los artefactos al ambiente de QA.
    e. Una vez que el ambiente de QA este totalmente listo, el Desarrollador cambiara el estatus de la solicitud de CC a RESUELTA en el Mantis:
       
    f. El Desarrollador añadirá una nota al Ticket, indicando al QA Manager la siguiente información:
    
       Atención a QA Manager
       
      " Por favor apoyarnos con las pruebas del presente control de cambio.
       Las  Pruebas Unitarias se encuentran en el repositorio en la ruta (Ruta repositorio)
       Y en el TestLink en la ruta (Ruta TestLink).
       La información para las pruebas es la siguiente:
       * Url del aplicativo:
       * Usuarios de prueba:
       * Contraseñas:
       * Versión del APK (Si aplica) que se esta liberando:"
       

7. Validación de solicitud (Pruebas QA):

    Una vez que el estatus de la solicitud de control de cambio sea RESUELTO, QA procederá a realizar lo que se describe a continuación:
    a. Validar que tiene la información completa de las Pruebas Unitarias, y que pueda acceder al ambiente con toda la información suministrada por el desarrollador.
    b. Ejecutar los escenarios de prueba considerando el tiempo estimado que se colocó en la solicitud.
    c. Si al ejecutar los escenarios de prueba existen incidencias relacionadas al control de cambio entonces:
       1.  QA registrará en Mantis las incidencias encontradas, haciendo una solicitud de alta, similar a lo descrito en el apartado  Alta de la solicitud (Ticket)).
       2.  QA relacionará el Ticket de la incidencia a la solicitud de CC inicial.
       3.  El Desarrollador corrige las incidencias de acuerdo a lo considerado en el apartado: Resolución de la solicitud (Ticket) descrito anteriormente.
       4.  QA valida la corrección de las incidencias y cierra aquellas que estén resueltas y reasigna las que aun no estén.         
    b. Si al final de la ejecución de los escenarios de prueba no existe ninguna incidencia, QA coloca como nota en la solicitud (Ticket) el  Vo.Bo en el siguiente formato:
       
       Se validó el presente control de cambio con todos los escenarios exitosos, se da el Vo.Bo de QA
       Y deberá agregar la siguiente información:
       * Ruta de repositorio en donde está la matriz de pruebas.
       * Ruta de repositorio en donde está el reporte de pruebas.
    c. El Gestor de Proyectos procede a cerrar la solicitud (Ticket).

Warning:

QA debe establecer los limites de sus pruebas, dentro del tiempo inicial que se estimó.

Warning:

La gestión de las incidencias de QA por parte del Desarrollador, debe ser similar a un Ticket de control de cambio normal, la única diferencia es que no se va a solicitar aprobación para aplicar la solución, ya que se entiende que es derivada de la solicitud inicial. Estos incidencias, unicamente pueden ser asignados por el QA Manager.

b. Fase de Pruebas QA: Es en este momento donde el Tester asignado da de alta las Incidencias que se han generado durante el ciclo de validaciones de lo desarrollado.

 Identifica las  Incidencias con el siguiente ícono

IconosJira1