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.
Sumario
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
 | El equipo de trabajo deberá actualizar DIARIAMENTE las actividades en el Jira, las cuales se verán reflejadas en el tablero de gestión de las actividades. |
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.
| En Jira los requerimientos nuevos o corrección de errores se manejan como INCIDENCIAS |
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.
| Es importante mencionar que solo se debe mover la actividad que se esta atendiendo en el momento, ya que solo podemos realizar una
actividad a la vez. |
 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
| Estas actividades se reconocen por el logotipo de color rojo (Incidencia) |
| 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:
|
