Gestión de Actividades en JIRA

Los flujos estándar de proceso de uso aplicativo para JIRA, son aquellos proyectos que cumplen con las siguientes condiciones:

* Requerimientos nuevos:

El desarrollo de estos requerimientos suelen ser muy extensos, por lo cual es necesario la creación de un cronograma en el cual se 
 especificaran las actividades a realizar y el tiempo para resolver cada actividad descrita.
 

* Correcciones de errores:

Normalmente este tipo de incidencias de un aplicativo se registran en el Mantis, pero cuando existen demasiadas incidencias reportadas
 por el cliente se hace necesario realizar una agrupación de incidencias las cuales se cierran y se registran por el Jira. Se  crea  un 
 cronograma en el cual se especificaran las incidencias a atender y el tiempo para resolver cada actividad descrita.
 

Software estándar a utilizar

El levantamiento de un proyecto se realiza a través del Jira.  

Flujo de proceso de actividades

En esta sección se describe el flujo de proceso por el cual deberá pasar el proyecto, que es el que se describe a continuación:

Levantamiento de actividades

  El Gestor de proyectos registra el levantamiento de las actividades que se van a realizar en el Jira, de acuerdo al cronograma elaborado
   el cual es el resultado del análisis efectuado por el grupo de Desarrolladores encargados del proyecto. Esta actividad inicia desde el 
   primer día en que se va activar el Sprint.

Equipo de trabajo Desarrolladores

Tablero de gestión de las actividades

    En este tablero se muestra el seguimiento de actividades por medio de columnas, las cuales indican en que fase del proceso esta la 
    actividad.
    
    
    

   

POR HACER

     Esta fase es el inicio de todas las actividades que se registran y que están pendientes por atender.
     
    
    

EN CURSO

     Esta fase es para indicar a todo el grupo de personas involucradas en el proyecto, que el Desarrollador esta atendiendo la actividad.
     
    
    
     En el caso de que el Desarrollador empiece una actividad y por alguna razón no la pueda concluir ya sea porque tiene algún bloqueo o 
     porque prefiere adelantar a otras actividades; sera necesario registrar un comentario a la actividad que se va a detener indicando el 
     motivo por el cual va a ocurrir esto.
     
     
     

   

     

Warning:

Es importante mencionar que cuando las actividades sean de cronograma y hayan concluido por parte del Desarrollador, la siguiente fase a la que deberá pasar la actividad es a LISTO. Estas actividades se reconocen por el logotipo de color azul (Tarea o Subtarea)

     

Warning:

Es importante mencionar que cuando se trate de la corrección de una incidencia reportada por el área de QA, la siguiente fase a la que deberá pasar la actividad es a EN CURSO.

     

Warning:

Es importante mencionar que el Desarrollador, deberá proporcionar un comentario cuando se trate de la corrección de una incidencia reportada por el área de QA.

REVISIÓN DE PRUEBAS

     En esta fase de pruebas se llevara el flujo de gestión de proyecto que se maneje, el Desarrollador creara las sesiones de prueba que se
     utilizan para indicarle al QA Manager cual es la cantidad de historias de usuario que se van a liberar para que se ejecuten las pruebas:
     
     
     

LLENADO DE CAMPOS PARA SESIONES DE PRUEBA

      La información de los campos que deben llenar los Desarrolladores para una sesión de prueba son los que se mencionan a continuación:
      

• Nombre de la sesión de prueba:

    Este nombre identifica la sesión de prueba de la historia de usuario y debe tener el siguiente formato: 
    Sesión de pruebas-HU+Numero historia usuario-Siglas proyecto
    
    
    
    Si se tratara de una incidencia o actividad debe tener el siguiente formato:
    Identificador incidencia Jira-Nombre resumen
    
    
    

• Compartido:

    Este campo permite que las sesiones de prueba sean compartidas con el equipo del QA Manager por lo que debe estar marcado.
    
         
    

• Usuario asignado:

    En este campo se debe llenar con el nombre del usuario que va a ser por defecto el responsable, el cual debe ser el QA Manager.
    
    
    

• Incidencia conexa:

    En este campo se debe seleccionar del listado de historias de usuario la que corresponde:
    
    
    
    En el caso de que sea una incidencia o actividad, se debe seleccionar el identificador de la incidencia:
    
    
    

• Información adicional:

    En este campo se debe proporcionar información adicional, el cual debe tener el siguiente formato:
    
    * Ruta de deposito de las Pruebas Unitarias del TestLink.
    * Ruta de deposito de las Pruebas Integración del repositorio.
    * Información para las pruebas del QA Manager:
      * Url del aplicativo
      * Usuarios de prueba
      * Contraseñas
      * Versión del APK (Si aplica) que se esta liberando
      
    
    

   

   

Warning:

Una vez terminadas las sesiones de prueba, el Desarrollador o el Gestor de proyectos por aviso del Desarrollador debe notificar por vía Slack en el canal del proyecto, la creación de las sesiones de prueba. Utilizando el siguiente contexto: QA Manager (Etiquetar a la persona que tenga el rol de QA Manager) Se crearon sesiones de prueba del proyecto (nombre del proyecto) por favor apoyarnos con la ejecución de las mismas.

HECHO

     Esta fase es para indicar que la actividad ha sido finalizada por parte del Desarrollador y que esta lista para la fase de 
     REVISIÓN DE PRUEBAS.
     
     
     

SEGUIMIENTO DEL TIEMPO

      Inmediatamente después de mover la actividad a esta fase, sera necesario documentar el tiempo invertido en que se llevo realizarlo de la 
      siguiente manera:
      
      1. Presionar un clic en el campo SEGUIMIENTO DEL TIEMPO:
      
         
         
      2. Aparecerá una pantalla en la cual proporcionaremos el tiempo real total, invertido en la realización de esta actividad:
      
         
         
      3. En esta pantalla capturaremos el tiempo real invertido en la realización de la actividad. Para la captura del tiempo real total, 
         se presentan 2 escenarios que pueden ocurrir los cuales se mencionan a continuación:
         
         3.1 La actividad fue finalizada en su totalidad, el tiempo definido fue el mismo que el que se estimo con anterioridad. En el 
             ejemplo que se muestra en la imagen se tiene un tiempo definido de 4 días con 6 horas (4d 6h), el tiempo registrado que el
             Desarrollador debería capturar en este campo son 0 días con 0 horas (0d 0h) lo cual indica que no hay tiempos reales que
             cumplir. También sera necesario seleccionar la fecha de inicio real de la actividad:
             
         
         
         3.2 El tiempo real fue menor al tiempo definido ya que la actividad fue mas fácil de realizar o el tiempo real fue mayor al definido
             ya que la actividad fue mayor al tiempo definido porque la actividad tiene una cierta complejidad que no se había tomado en
             cuenta. En este escenario sera necesario poner el tiempo restante que el Desarrollador estime para terminar esa actividad.

Equipo de trabajo QA

   QA Manager recibe la notificación de la creación de las sesiones de prueba, para que se de inicio a los ciclos de prueba de los escenarios
   que ellos ya mapearon, de acuerdo a sus historias de usuario con la información proporcionada por el Desarrollador.
   
   Si surgen incidencias durante los ciclos de prueba, el equipo de QA va a registrar las incidencias en el Jira. 
   
   Las incidencias que se van a registrar deben tener las siguientes características:
   
   1. Se debe registrar una incidencia del tipo Error:
      
   
   2. Los nombres de las tareas que se registran deben ser muy descriptivos, deben indicar de manera puntual de que se trata el error que se 
       esta reportando:
       
      

      
      
   3. Se deben adjuntar las etiquetas que correspondan a la incidencia ocurrida, así como la etiqueta de la incidencia por parte de QA:
   
      
      
   4. El equipo de QA asigna la incidencia al Desarrollador responsable para que sea atendido.
   
   5. El Desarrollador volverá a repetir las mismas actividades descritas en el punto: Equipo de trabajo Desarrolladores
      descrito anteriormente.
      

   

Warning:

Es importante mencionar que cuando el Tester haya validado la corrección de la incidencia añadan el siguiente comentario: Se valido incidencia, se cierra incidencia