Introducción
Cuando la empresa entró en un nuevo camino de cambio orientado a las metodologías agiles y todo lo que ello implica, nos pusimos a investigar con una colega cómo hacer para poder implementar esta metodología en el ambiente de trabajo cotidiano sin que esto afectara fuertemente el ritmo laboral actual.
Nuestra primera intención fue mejorar la forma en que encarábamos una iteración, teniendo un control de las horas y tareas realizadas por parte del equipo y también la forma en que organizábamos nuestro trabajo en el TFS, para ello queríamos determinar cuál era la velocidad de nuestro equipo, cuánto trabajo restaba realizar, si el tiempo restante en la iteración era suficiente para completar las tareas planificadas, si la cantidad de casos de prueba realizados eran suficientes, etc.
Investigando nos encontramos con los nuevos reportes que ofrece el nuevo Template de Agile, los cuales contestaban cada una de nuestras preguntas. Nos interiorizamos en el tema para saber que datos requería y que información devolvía, porque si ello no los íbamos a poder implementar adecuadamente.
El pequeño estudio que realizamos fue sobre la propia página de Microsoft MSDN en la cual se encuentra explicado de forma muy completa el nuevo Template y también cada uno de los reportes que ofrece.
http://msdn.microsoft.com/en-us/library/dd380714.aspx
Se tomó cada uno de los reportes y se realizó un breve resumen de cada uno de ellos definiendo cual es la información de devuelve el mismo, que parámetros de los elementos de trabajos se deben de alimentar, un análisis del reporte considerando a que pregunta podría llegar a responder el informe, como así también una versión positiva y negativa del reporte.
Esto no es más que una recopilación de cada uno de ellos considerando únicamente la información que nos era relevante. Espero que les sea de ayuda y puedan implementar estas herramientas que ofrece actualmente el TFS y muy pocas personas conocen de su existencia.
Bug Status Report
Este reporte muestra el número de errores acumulado basado en el estado del error, la prioridad y la gravedad. (state, priority, and severity).
Información que proporciona el reporte
· Número de errores: Representa el número de errores acumulados, agrupados según el estado en el cual se encuentran.
· Errores activos por prioridad/gravedad : Gráfico circular que muestra el número de errores que se encuentran activos, agrupados por prioridad o gravedad.
· Errores activos por asignación: Gráfico de barras horizontales con el número total de errores activos que cada miembro del equipo tiene asignados actualmente, agrupados por prioridad o gravedad.
· Errores resueltos por asignación: Gráfico de barras horizontales con el número total de errores resueltos que cada miembro del equipo tiene asignados, agrupados por prioridad o gravedad.
Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:
- Definir los errores y especificar sus rutas de acceso de Área e Iteración.
- Especificar la Prioridad y Gravedad de cada error.
- Asignar a cada error un miembro del equipo dedicado a resolverlo o cerrarlo.
- Actualizar el estado de cada error cuando se ha corregido, probado y cerrado.
Análisis del reporte
El reporte varía según el punto del ciclo de desarrollo del producto. Las iteraciones tempranas deben mostrar un aumento gradual del número de errores activos. Las iteraciones que están cercanas al final de un ciclo de desarrollo deben mostrar un amplio número de errores resueltos. El mismo permite responder a las siguientes preguntas:
- ¿Con qué rapidez resuelve y cierra errores el equipo?
- ¿El equipo corrige los errores con la rapidez suficiente para finalizar a tiempo?
- ¿El equipo corrige primero los errores de alta prioridad?
- ¿Cómo se distribuyen los errores por prioridad y gravedad?
- ¿Cuántos errores hay asignados a cada miembro del equipo?
- ¿Algún miembro del equipo necesita ayuda para resolver o cerrar errores?
Versión positiva del reporte
La versión positiva del reporte muestra un aumento de los errores activos a medida que pasa el tiempo seguido de una resolución y cierre de errores.
Versión negativa del reporte
Un reporte negativo muestra uno o más de los indicadores que se describen en la siguiente tabla:
· Se amplía la cantidad de errores activos. Si se amplía la cantidad de errores activos del equipo, eso significa que aumenta el trabajo pendiente de errores. El equipo detecta más errores de los que puede resolver o cerrar. Según esto podríamos determinar que la cantidad de errores a crecido potencialmente debido a diferentes problemas: problema en el equipo para resolver y cerrar errores o su capacidad se ve demorada por asuntos externos.
· La cantidad de errores activos no cambia. Una tendencia constante en el número de errores activos indica que el equipo no detecta errores, esto se puede deber a un problema en las pruebas o el equipo está teniendo dificultades para crearlo.
· La cantidad de errores resueltos o cerrados no cambia. Cuando la cantidad de errores resueltos o cerrados por el equipo no cambia durante un período de tiempo prolongado, es posible que los miembros del equipo no sean capaces de resolver o cerrar esos errores. Ante este indicador uno se puede plantear diferentes situaciones: el equipo está destinado en el tiempo asignado a resolver las tareas, se definieron correctamente las tareas que debía de realizar o se debería de validar si el equipo está alimentando correctamente los estados de los errores.
· Las asignaciones de errores no están distribuidas de manera uniforme. Se debe de realizar una reasignación de errores si es que el equipo no se encuentra equilibrado con respecto a los errores que tiene asignados.
Seguimos en próximos artículos explicando otros reportes ágiles.