Última entrega sobre comentarios de reportes ágiles, debajo está la lista de comentarios que hemos ido realizando:

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

Remaining Work Report

Status on All Iterations Report

Stories Overview Report

 

Stories Progress Report

 

Información que proporciona el reporte

El reporte de Progreso de los Casos de Uso muestra el estado de realización determinado por las tareas definidas para implementar el mismo.

 

Este informe muestra para cada caso de uso, la siguiente información:

 

• Progreso (% completado): valor numérico que representa el porcentaje de trabajo completado.
• Horas completadas: representación visual de las horas completadas, que se muestra como una barra de color verde oscuro.
• Completado recientemente: representación visual de las horas completadas en el intervalo de tiempo especificado para Días recientes (calendario), que se muestra como una barra de color verde claro.
• Horas restantes: Horas restantes correspondientes a todas las tareas vinculadas al caso de uso o sus casos secundarios.

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros de los elementos de trabajo:

• Definir los casos de uso y las tareas, crear un vínculo Secundario de cada tarea al caso que implementa y crear un vínculo Secundario de las subtareas a su tarea primaria.
• Definir y actualizar los campos Completado y Restante para cada tarea o subtarea durante la iteración o el lanzamiento.
• Especificar las rutas de acceso de Iteración y Área para cada caso y tarea.

Análisis del reporte

El reporte permite visualizar el volumen de trabajo realizado por el equipo durante la última semana o un período de tiempo reciente. Se puede encontrar respuestas a las siguientes preguntas:

• ¿En qué casos el equipo progresó y cuáles están a punto de completarse?
• ¿En qué casos no ha trabajado el equipo?
• ¿A qué casos de uso les queda el mayor volumen de trabajo para completarse?
• ¿Hay trabajo bloqueado en algún caso?

  Los casos que no muestran una banda de color verde claro en la barra de progreso pueden indicar un problema de bloqueo.

• ¿Se puede entregar todo lo que se ha planeado? ¿Qué objetivos se deben suprimir y cuáles deben ser objeto de un cambio de ámbito?

 

Versión positiva del reporte

Un reporte positivo muestra que el equipo ha completado recientemente trabajo (color verde claro) en todos los casos que se espera estén en curso.

Versión negativa del reporte

Un reporte negativo podría mostrar una o más de los siguientes indicadores:

• No se muestra trabajo en uno o varios casos.

  Los casos con 0% de progreso o 0 horas restantes no tienen definido esfuerzo previsto ni tareas para ellos.

• Muchos casos de uso no tienen trabajo completado recientemente.

  Cuando varios casos indican ningún volumen o volúmenes muy pequeños de trabajo completado, el progreso del equipo es lento.

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

Remaining Work Report

Status on All Iterations Report

 

Hoy comentaremos sobre:

Stories Overview Report (Agile)

El siguiente reporte muestra gráficamente información general sobre los casos de uso definido para una iteración o área determinada.

Información que proporciona el reporte

El reporte presenta una visión del trabajo realizado para el conjunto de casos de uso filtrados hasta la fecha actual.

Este reporte muestra la siguiente información sobre cada caso de uso:

Progreso del trabajo

• % de horas completadas: un valor numérico y representación visual que muestra el porcentaje de trabajo completado.
• Horas restantes: un valor numérico de todas las horas restantes para todas las tareas vinculadas al caso de uso o sus casos secundarios.

Estado de la prueba

• Pruebas: un valor numérico que representa el número de casos de prueba vinculados al caso de uso o sus casos secundarios.
• Resultados de pruebas: un valor numérico y representación visual que muestra el porcentaje de casos de prueba, agrupados según el estado de su ejecución de pruebas más reciente, donde las opciones son Superadas (verde), Con error (rojo) o Sin ejecutar (negro).
• Errores: un valor numérico y representación visual que muestra el número de errores vinculados al caso de prueba o caso de uso, donde las opciones son Activa (azul) y Resuelto (oro).

El reporte de Información general enumera y resalta los casos según los siguientes criterios:

• Los casos aparecen por orden de importancia, que está basado en su clasificación asignada.
• Los casos aparecen en tipo en negrita cuando están en el estado activo o resuelto.
• Los casos aparecen en tipo normal cuando están en el estado cerrado.
• Los casos aparecen en tipo gris cuando su iteración o área asignada está fuera del conjunto filtrado, pero tienen tareas o casos secundarios que están dentro del conjunto filtrado de iteraciones o áreas de producto.

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros de los elementos de trabajo:

• Definir los casos de uso y tareas, crear un vínculo Secundario desde cada tarea a un caso de uso y crear un vínculo Secundario desde cualquier subtarea a su tarea primaria.
• Definir y actualizar los campos Completado y Restante para cada tarea o subtarea durante la iteración o versión.
• Definir los casos de prueba y crear el vínculo Prueba realiza por desde cada caso de prueba a un caso de uso.
• Para cada error, crear el vínculo Prueba realiza por al caso de prueba que identificó el defecto de código o un vínculo Relacionado al caso de uso con el que está relacionado el error.
• Establecer el Estado de cada error en Resuelto cuando se corrija.
• Especificar las rutas de acceso Área e Iteración para cada caso, tarea, caso de prueba y error.

 

Análisis del reporte

El reporte de Información general muestra el progreso de trabajo global en tres áreas que son importantes para completar y cerrar un caso de uso:

• Tareas implementadas para completar el caso de uso.
• Casos de prueba ejecutados para asegurar la calidad de los casos implementados.
• Errores identificados que indican los problemas con la calidad de los casos de uso.

Progreso del trabajo

• ¿Corresponde a sus expectativas la cantidad de trabajo que resta para cada caso de uso?
• ¿Se implementan primero los casos de uso clasificados según su relevancia?
• ¿Cuántas pruebas se definen para cada caso de uso?¿Cuántas pruebas se superan?
• ¿Qué casos de uso se implementan que no tienen ningún caso de prueba definido para ellos?

Progreso de la calidad

• ¿Cuántos casos de prueba se han ejecutado para cada caso de uso y cuántos han superado las pruebas?
• ¿Cuántos errores activos tiene cada caso de uso?
• ¿Se encuentran errores para los casos de uso que se prueban?
• ¿Se resuelven los errores o siguen activos?

Evaluación de riesgo

• ¿Qué casos de uso están en riesgo?
• ¿Qué casos de uso no son suficientemente estables para la versión?
• ¿Qué casos de uso puede distribuir hoy el equipo?

 

Versión positiva del reporte

Un reporte positivo muestra más progreso en los casos de uso que aparecen cerca de la parte superior del reporte. En la imagen que se muestra a continuación se visualiza que el equipo ha realizado más trabajo para los casos que aparecen en el reporte.

 

 

Versión negativa del reporte

Un reporte negativo muestra una o más de los siguientes indicadores:

• El equipo está realizando más progreso en los casos de uso que tienen un rango inferior que en los que tienen un rango superior.
• Hay más pruebas con errores que superadas.
• Se producen errores en las pruebas para un caso de uso, pero no se crea ningún elemento de trabajo de error.

 

Hasta la próxima.

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

Remaining Work Report

 

Hoy nos toca comentar un nuevo reporte.

Status on All Iterations Report

Este reporte permite realizar un seguimiento del rendimiento del equipo sobre las iteraciones en las que ha participado.

Información que proporciona el reporte

 

El reporte de estado muestra para cada iteración especificada la siguiente información:

• Casos de Uso cerrados: número de casos de uso que se han cerrado.
• Progreso (Horas): representación visual y numérica en dos barras que representa los valores para Estimación original (gris), Completado (verde) y Restante (azul claro) basados en el número acumulado de horas que se definen para todas las tareas.
• Errores: valor numérico y representación visual para todos los errores, agrupados por sus estados actuales de Activo (azul), Resuelto (oro) y Cerrado (verde).Estos valores se derivan de los valores actuales que se especifican durante la iteración y el estado de cada error.

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros de los elementos de trabajo:

• Definir casos de uso, tareas y errores y especificar las rutas de acceso de Área e Iteración para cada uno.
• Especificar los campos Estimación original, Completado y Restante para cada tarea o subtarea y actualizar los campos Completado y Restante durante la iteración.
• Actualizar el Estado de cada artículo, tarea y error cuando progrese de estado activo a cerrado.

 

Análisis del reporte

El reporte permite determinar cuántos casos de uso están listos para la versión comercial y comprender mejor la tasa de progreso del equipo. El reporte permite encontrar respuestas a las siguientes preguntas:

 

• ¿Coincidió el ámbito de trabajo para cada iteración con la capacidad del equipo?
• ¿El número de casos de uso cerrados son los esperados por iteración?
• ¿Está el equipo resolviendo y cerrando más errores?
• ¿Cuántos casos de uso puede distribuir el equipo?

 

Versión positiva del reporte

En un reporte de estado de iteraciones positivo muestra un progreso de horas a medida que transcurren iteraciones.

 

Versión negativa del reporte

Un reporte de estado negativo podría mostrar uno o más de los siguientes indicadores:

• No se cerró ningún caso de uso en una o más iteraciones.
• El número de horas estimadas y completadas varía ampliamente dentro de las iteraciones o entre ellas.
• El número de errores encontrados no aumenta con cada iteración sucesiva.

   

 

Hasta la próxima.

 

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

 

Seguimos en este post con:

Remaining Work Report

El reporte de trabajo restante permite realizar un seguimiento del progreso del equipo e identificar cualquier problema en el flujo de trabajo.

Información que proporciona el reporte

El reporte puede visualizarse según las horas trabajadas o el número de elementos de trabajo para cada tarea, caso de uso o error.

La primera vista (horas trabajadas) muestra el número total de horas de trabajo para el período de tiempo especificado y el progreso del equipo para completar ese trabajo. La segunda vista (elementos de trabajo) muestra el número de elementos de trabajo para el período de tiempo especificado y el número de elementos de trabajo en cada estado.

Horas de trabajo

Aquí se muestra un ejemplo del reporte en la vista Horas de Trabajo. Este ejemplo es positivo en cuanto que se ha completado una tasa constante de trabajo.

 

• Horas restantes: valor acumulado de todas las horas restantes para todas las tareas.
• Horas completadas: valor acumulado de todas las horas completadas para todas las tareas.

Número de elementos de trabajo

La ilustración siguiente muestra el mismo reporte pero en la vista Elementos de Trabajo, con los elementos de trabajo agrupados por estado. Un análisis del graficó permite determinar que el equipo realizó un progreso adecuado pero la estimación de elementos de trabajo aumentó desde el inicio de la iteración a casi tres veces más hacia el final de la iteración.

 

• Activo: valor acumulado de todos los casos de uso, tareas y errores que se encuentran en estado Activo (azul).
• Resuelto: valor acumulado de todos los casos de uso o errores que se encuentran en estado Resuelto (oro).
• Cerrado: valor acumulado de todos los casos de uso, tareas y errores que se encuentran en estado Cerrado (verde).

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

 

• Definir los casos de uso, tareas y errores y especificar las rutas de acceso de Área e Iteración para cada elemento de trabajo.
• Especificar y actualizar los campos Horas Completadas y Horas Restantes para cada tarea o subtarea a medida que el equipo realiza progresos en cada elemento de trabajo.
• Actualizar el Estado de cada tarea, caso de uso y error cuando progrese de activo a cerrado.

Análisis del reporte

El reporte muestra información que permite visualizar si el equipo progresa correctamente y si finalizará las tareas dentro del tiempo asignado, como así también permite responder a las siguientes preguntas:

 

• ¿Con qué rapidez avanza el equipo hacia el trabajo restante?
• ¿Se agrega trabajo durante la iteración?
• ¿Cuánto progreso puede realizar el equipo en el tiempo disponible?
• ¿Hay demasiado trabajo en curso?
• ¿El flujo de trabajo se impide o está bloqueado?
• ¿Cuándo finalizará el equipo la iteración actual?

Versión positiva del reporte

Un reporte positivo muestra un progreso constante para resolver y cerrar las tareas. La forma rectangular del diagrama indica que el trabajo estimado coincide con el trabajo final y no fue necesario agregar nuevas tareas.

Versión negativa del reporte

Un reporte negativo muestra poco progreso y las líneas planas del gráfico identifican que las tareas permanecen en el mismo estado durante un tiempo prolongado. También se puede determinar que le número elementos de trabajo aumenta después del punto medio de la iteración, lo que indica que se han introducido nuevas tareas las cuales no habían sido planificadas.

 

Los posibles indicadores que se pueden visualizar en un reporte negativo son:

• El número de horas completadas o el número de elementos de trabajo resueltos o cerrados sigue siendo plano, se podría deben a un bloqueo en el progreso del equipo.
• El número de horas restantes o elementos de trabajo activos aumenta.

  Esta situación indica que el equipo no estimó con precisión el trabajo en el inicio de la iteración o que el equipo agregó las características después de que se inició la iteración.

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Seguimos en este post con:

 

Burndown and Burn Rate Report (Agile)

El siguiente reporte permite determinar la tasa de avance del equipo, como así también muestra la evolución de la tendencia de trabajo completado y restante a lo largo de un período de tiempo especificado. El reporte se puede visualizar según las horas trabajadas o el número de elementos de trabajo que se han resuelto y cerrado.

Información que proporciona el reporte

La ilustración anterior muestra el trabajo restante y líneas de tendencia que predicen cuándo se completará el trabajo. La línea de tendencia ideal calcula una pendiente o trayectoria para el momento en que se completará el trabajo según la cantidad de trabajo restante y la fecha de finalización definida. La línea de tendencia real se calcula en función del progreso real del equipo para completar el trabajo y cerrar los elementos de trabajo.
La sección inferior del reporte presenta un cálculo de la tasa de avance del equipo, tanto real como necesaria, y una división de las asignaciones de trabajo para cada miembro del equipo.

 

 

Evolución del proyecto

 

La evolución muestra la tendencia de cuánto trabajo se ha completado y cuánto trabajo queda en el transcurso del tiempo en una iteración o una versión. Este grafico considera los siguientes parámetros:

• Horas restantes: valor acumulado de todas las horas restantes para todas las tareas.
• Horas completadas: valor acumulado de todas las horas completadas para todas las tareas.
• Elementos Activos: la cantidad de tareas, casos de uso o errores que se encuentran en estado Activo.
• Elementos Resueltos: la cantidad de tareas, casos de uso o errores que se encuentran en estado Resuelto.
• Elementos Cerrados: la cantidad de tareas, casos de uso o errores que se encuentran en estado Cerrado.

 

Líneas de tendencia:

• Real: la línea corta el eje X cuando se espera que la iteración se complete según la tasa real de horas que se han completado y las horas restantes.
• Ideal: la línea se dibuja desde el trabajo restante en la fecha de inicio para cortar el eje X en la fecha de finalización.

 

Tasa de Avance

La Tasa de avance muestra una estimación de cuánto trabajo puede completar un equipo durante una iteración. Este cálculo muestra la rapidez con que el equipo está completando el trabajo planeado y cuánto varía la tasa de un día a otro o de una iteración a otra, estos datos resultan útiles planear la iteración siguiente, junto con las mediciones de calidad.

A continuación se describe que parámetros considera para calcular la tasa de avance, se puede visualizar según las horas completadas o los elementos de trabajo completados.

• Real: número total de horas o elementos de trabajo que el equipo ha completado durante el intervalo de tiempo especificado, dividido por el número de días en el intervalo.
• Necesario: número total de horas o número total de elementos de trabajo que se estimaron para el intervalo de tiempo especificado, dividido por el número de días en el intervalo.

 

Asignación de trabajo

La sección del reporte Asignación de trabajo proporciona información de cómo se ha asignado el trabajo al equipo, el trabajo que el equipo ha completado y el restante para cada miembro. Por medio de esta sección se puede obtener la siguiente información para cada miembro del equipo:

• Horas Restante: número total de horas que quedan en el intervalo de tiempo especificado.
• Horas Completadas: número total de horas que el miembro del equipo completó en el intervalo de tiempo especificado.
• Elementos Activos (azul): número total de tareas, casos de uso y errores que se encuentran en estado activo.
• Elementos Resueltos (oro): número total de tareas, casos de uso y errores que se encuentran en estado resuelto.
• Elementos Cerrados (verde): número total de tareas, casos de uso y errores que se encuentran en estado cerrado.

Actividades requeridas para el seguimiento de elementos de trabajo

• Para que el reporte sea fiable los miembros del equipo deben realizar las siguientes actividades:
• Definir los casos de uso, tareas y errores y especificar las rutas de acceso de Área e Iteración para cada uno.
• Especificar y actualizar los campos Horas Completadas y Restantes para cada tarea o subtarea cuando se trabaja en ella. Si se divide una tarea en subtareas, se debe especificar únicamente las  horas para las subtareas.
• Actualizar el Estado de cada tarea, caso de uso y error cuando progrese de activo a cerrado.

Análisis del reporte

Un análisis del reporte permite encontrar respuestas a  las siguientes preguntas:

Evolución

• ¿Con qué rapidez está completando el equipo el trabajo restante?
• ¿El equipo está agregando trabajo durante la iteración?
• ¿Cuánto trabajo puede completar el equipo en el tiempo disponible?
• ¿Cuándo puede el equipo finalizar el trabajo?
• ¿Cuándo puede el equipo finalizar la iteración actual?

 

Tasa de avance

• ¿El equipo está trabajando con la rapidez suficiente para finalizar el trabajo restante a tiempo?

 

Asignación del trabajo

• ¿Está bien distribuido el trabajo entre el equipo?
• ¿El equipo debería equilibrar la carga de trabajo restante?

 

Versiones positivas del reporte

Un reporte positivo muestra que las líneas de tendencia real e ideal están muy próximas.

Versiones negativas del reporte

Un reporte negativo mostrará una o más de las siguientes indicaciones:

• Las líneas de tendencia real e ideal son divergentes o están muy separadas.
• El número total de horas está aumentando.

 

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Seguimos en este post con:

 

Build Quality Indicators Report

El siguiente reporte muestra la cobertura de pruebas, la renovación de código y el número de errores para una compilación especificada.

 

Información que proporciona el reporte

En el reporte se puede visualizar sobre el eje X las compilaciones que incluye el reporte, sobre la base de los filtros establecidos para la plataforma, la configuración y la definición de la compilación.

Cada barra vertical representa un conjunto de datos derivados de una o más compilaciones. En la variante de tamaño de código del reporte, la longitud de cada barra vertical representa el tamaño de la base de código protegida. Las pruebas manuales se pueden ejecutar en cualquier momento después de la compilación y están asociadas a esa compilación. Las pruebas que no se han ejecutado todavía se cuentan como "no concluyentes".

En la siguiente tabla se describe la información que aparece en el reporte:

Indicador	Descripción
Errores activos (número)	Gráfico de líneas que representa el número de errores que estaban activos al momento de la compilación.
Renovación de código (líneas)	Gráfico de líneas que describe el número de líneas de código que el equipo agregó, quitó y modificó antes de la compilación. La renovación de código se calcula determinando el número de líneas de código que se han agregado, eliminado o modificado en la compilación dividido por el número total de líneas de la compilación.
Cobertura de código (porcentaje)	Gráfico de líneas que representa el porcentaje de código que cubren las pruebas.
Pruebas no concluyentes	Gráfico de barras apiladas de color gris que indica el número de pruebas que no tuvieron un resultado correcto o se pusieron en pausa. Si la compilación no tuvo un resultado correcto, las pruebas no se cuentan o se cuentan como no concluyentes.
Pruebas no superadas	Gráfico de barras apiladas de color rojo que indica el número de pruebas no superadas para la compilación.
Pruebas superadas	Gráfico de barras apiladas de color verde que indica el número de pruebas superadas para la compilación.

Para que el reporte sea fiable los miembros del equipo deben realizar las siguientes actividades para administrar pruebas y compilaciones:

• Configurar un sistema de compilación. Para utilizar Team Foundation Build, debe configurar un sistema de compilación.
• Crear definiciones de compilación. Puede crear varias definiciones de compilación, de modo que cada una de ellas pueda ejecutarse para generar código para una plataforma diferente.
• Definir las pruebas que se ejecutarán automáticamente como parte de la compilación.
• Configurar las pruebas para recopilar datos de cobertura de código. Para que los datos de cobertura de código aparezcan en el reporte, los miembros del equipo deben instrumentar las pruebas para recopilar esos datos.
• Ejecutar compilaciones con regularidad. Puede ejecutar compilaciones a intervalos establecidos o después de cada protección. Puede crear compilaciones periódicas cuando utilice el desencadenador de programación.

 

Análisis del reporte

El reporte permite responder las siguientes preguntas:

• ¿Cuál es la calidad del software?
• ¿Está el equipo probando suficiente código?
• ¿Se están superando las pruebas?
• ¿Es probable que el equipo termine en función del código y las métricas de pruebas?
• ¿Con qué frecuencia se superan las pruebas y con qué frecuencia se prueba el código?

 

Versión positiva del reporte

Un reporte positivo muestra los siguientes indicadores:

• La mayoría de las pruebas se superan (áreas grandes de color verde) y pocas pruebas no se superan (cantidades pequeñas de color rojo).
• El porcentaje de color rojo es inferior al 20-30 por ciento.

 

Versiones negativas del reporte

Una versión negativa mostrará uno o más de los siguientes indicadores:

• Menos cobertura de código y más renovación de código. Podría indicar que el nuevo código se protege sin las correspondientes pruebas unitarias que lo cubran.

  

• Baja tasa de pruebas en ejecución. Estos datos podrían indicar que el equipo no está realizando suficientes pruebas. Este bloqueo podría indicar falta de recursos o que los evaluadores estén haciendo otras tareas, como escribir la automatización de pruebas en lugar de probar la funcionalidad actual.

  

• Alta renovación de código, baja tasa de cobertura de código. Una alta renovación de código sugiere que los errores se introducirán como efectos secundarios de los cambios. De lo contrario, una alta renovación de código podría indicar una cobertura reducida y la necesidad de reescribir pruebas.

  

• Tasa alta de pruebas no superadas. La siguiente ilustración muestra que muchas pruebas se realizan con una cobertura de código razonable, pero que no se están superando las pruebas. Estos datos podrían indicar prácticas de desarrollo poco rigurosas o, en iteraciones tempranas, que las pruebas son demasiado duras para esta etapa del producto.

  

• Alta tasa de pruebas que se superan y alta tasa de errores activos. La siguiente ilustración muestra una alta tasa de pruebas superadas pero, no obstante, un alta tasa de errores de entrada. Esta situación se puede producir por varias razones. Es posible que las pruebas no sean suficientemente rigurosas para esta etapa del producto.

  

• Tasa creciente de superación de pruebas sin aumento en la cobertura de código. Habitualmente, cuantas más pruebas se realizan, se debe cubrir más código. Por otro lado, si la ejecución de pruebas y las tasas de superación de pruebas aumentan sin un aumento correspondiente en la cobertura de código, es posible que las pruebas incrementales sean redundantes.
• El número de errores activos aumenta, pero las pruebas no superadas no aumentan. Es probable que las pruebas no estén probando la misma funcionalidad que indican los errores.
• El número de errores activos está disminuyendo, pero las pruebas superadas no aumentan. Puede que exista un aumento en la tasa de reactivación.

 

 

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Seguimos en este post con:

 

Reactivation Report

A medida que el equipo resuelve y cierra los errores, se puede utilizar el reporte de Reactivaciones para determinar la eficacia con que el equipo corrige los errores.

Las reactivaciones se refirieren a errores que se han resuelto o cerrado tempranamente y, a continuación, se han vuelto a abrir. La tasa de la reactivación también se la denomina tasa de retorno de errores.

Este reporte se puede utilizar para mostrar los errores y casos de uso que se han reactivado. Una tasa de reactivaciones baja (por ejemplo, menor que el 5%) podría ser aceptable dependiendo de los objetivos del equipo. Sin embargo, una tasa alto o creciente de reactivaciones indica que el equipo podría necesitar diagnosticar y corregir otros problemas.

Información que proporciona el reporte

El reporte de Reactivaciones informa en un gráfico de superficie el número de errores o casos que se han resuelto o reactivado después de cerrarlos.

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

• Definir casos de uso y errores, y especificar sus rutas de iteración y de área.
• Actualizar el Estado de los casos y errores a medida que avanzan desde que se activan hasta que se cierran.

 

Análisis del reporte

Es normal que el reporte varíe según el punto del ciclo de desarrollo del producto en que nos encontremos. Las iteraciones tempranas deberían presentar muy pocas reactivaciones.

El reporte de Reactivaciones muestra información que se puede utilizar para detectar si el equipo está reactivando un número alto de errores o casos, esta tasa se obtiene de contar el número de errores supuestamente corregidos cuyas correcciones no funcionan. Estas reactivaciones pueden crear un ciclo de repetición del trabajo que interfiere con las tareas planeadas.

El reporte permite responder las siguientes preguntas:

• ¿Cuántos errores se han reactivado en la iteración actual?
• ¿Cuántos casos de uso se han reactivado en la iteración actual?
• ¿El equipo está resolviendo y cerrando los errores y casos reactivados a una velocidad aceptable?

 

Versión positiva del reporte

Una versión positiva del reporte muestra un progreso sostenido de resolución y cierre de errores. La tasa total de reactivación de elementos de trabajo es del 5% o inferior, y no aumenta durante la iteración. Cuanto menor sea la tasa de reactivación, más podrá progresar el equipo en su conjunto.

 

Versión negativa del reporte

 

Una versión negativa del reporte podría indicar:

El equipo está reactivando una cantidad elevada de errores. Una tasa de reactivación de errores alta podría indicar que el equipo está cerrando los errores rápidamente. Este indicador se podría tomar como una mala señal para el proyecto, ya que las reactivaciones introducen trabajo adicional que duplica el esfuerzo total que se necesita para completar el trabajo correspondiente.

El equipo está reactivando un número alto de casos de uso La tasa de reactivación de casos de uso debe considerarse como un porcentaje del número total de casos de uso que el equipo está cerrando.

 

En el post anterior publiqué una introducción al tema de reportes Ágiles y un resumen de uno de los reportes.

Seguimos la serie con:

Bug Trend Report

El siguiente reporte ayuda a obtener y seguir la tasa de detección y resolución de errores del equipo. Este reporte muestra un promedio acumulado o móvil de los errores notificados, resueltos y cerrados a lo largo del tiempo, obteniendo una visión de la medida en que el equipo está encontrando, resolviendo y cerrando los errores.

Información que proporciona el reporte

El reporte calcula un promedio acumulado del número de errores que el equipo ha abierto, resuelto y cerrado. El promedio acumulado se basa en los siete días antes de la fecha para la que se calcula. Es decir, el reporte calcula el promedio del número de errores en cada estado para cada uno de los siete días antes de la fecha y, a continuación, divide el resultado entre siete.

 

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.
• Actualizar el Estado de cada error cuando se ha corregido, probado y cerrado.
• Especificar la Prioridad y Gravedad de cada error durante la evaluación de errores.

Análisis del reporte

Las tasas de errores se interpretan mejor comparándolas con todas las actividades de proyecto de equipo actuales y las otras métricas que proporcionan los reportes de Estado del error y Reactivaciones. Por ejemplo, el equipo podría encontrar errores con especial rapidez en código mal escrito, en código recientemente integrado, con pruebas mejoradas o durante un evento excepcional como una búsqueda intensiva de errores. Por otra parte, los errores son más difíciles de encontrar en un producto de alta calidad y con pruebas ineficaces. Cuando el producto se estabiliza hacia el fin de un ciclo del producto, el equipo debería encontrar errores con menos frecuencia.

El reporte podría informar determinadas situaciones que se deberían evaluar porque surgen:

· El equipo encuentra el mismo número de errores aproximadamente en períodos de tiempo sucesivos.

o ¿Son adecuados los casos de prueba para probar los casos de uso que se están desarrollando?

o ¿Las pruebas se han vuelto obsoletas o están probando la funcionalidad equivocada?

o ¿El equipo de pruebas está probando cada caso de uso rigurosamente?

· El equipo resuelve muchos errores en cada período

o ¿Se cierran rápidamente los errores resueltos? La tasa de errores cerrados debe ser similar a la de errores resueltos.

o ¿Permanecen las reactivaciones de errores dentro de los límites esperados?

· El equipo resuelve los errores rápidamente pero no los cierra.

o ¿Están sobreasignados los recursos de pruebas?

o ¿Debería el equipo volver a revisar las prioridades de pruebas?

Versión positiva del reporte

Un reporte positivo muestra que el equipo encuentra más errores en el inicio de un ciclo de desarrollo y menos errores hacia el fin de una iteración. Cuando el equipo resuelve los errores más rápidamente que los encuentra, el número de errores activos empezará a disminuir. Cuando el equipo empieza a encontrar menos errores, el producto se estará estabilizando.

Versión negativa del reporte

Un reporte negativo podría mostrar que el equipo encuentra errores más rápidamente a medida que se acerca la fecha de envío y los resuelve más lentamente. En esta situación, el trabajo pendiente del equipo está aumentando, ya que los errores no se corrigen y sería conveniente investigar las causas.

 

 

 

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.