Reportes Agiles en Team Foundation Server – Remaining Work Report

por Viviana Chelini  29. octubre 2010

 

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.

Agregar comentario

  Country flag

biuquote
  • Comentario
  • Vista previa
Loading

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML