ALM BootCamp–Video de las presentaciones

por Daniel Laco  23. mayo 2011

 

El pasado 28 de Abril participamos como oradores con Victor Passador en el ALM BootCamp en Microsoft Argentina.

También participaron Juan Pablo Díaz, Maxi Accotto y Eric Delahaye.

Aquí les dejo los videos de las presentaciones y que las disfruten !

 

Apertura - Juan Pablo Díaz:

 

 

Control de Versiones - Daniel Laco:

 

 

Versionado de Base de Datos - Maxi Accotto:

 

 

Arquitectura - Eric Delahaye:

 

 

Testing- Victor Passador:

 

 

Configuring co-authoring in SharePoint 2010

por Daniel Laco  29. marzo 2011

Investigando sobre el mundo SharePoint me encontré con una guía para que los administradores configuren la co – autoría de su organización.
En ella explican cómo configurar las versiones, el período de creación de las mismas, el número máximo de autores y la posibilidad de deshabilitar la co- autoría.
A continuación les dejo un breve resumen y los links correspondientes, donde encontrarán detalladamente la configuración de cada uno de los puntos expuestos a continuación.

-Los autores pueden trabajar el mismo documento, y las ediciones se almacenarán en el servidor como versiones de documentos.
-Si se activa la versión, SharePoint Server toma instantáneas periódicas de los documentos, y los guarda para futuras consultas.
-Los administradores pueden limitar el número máximo de autores que pueden ser co-autores de un documento al mismo tiempo.
-Los co-autores también pueden ser deshabilitados por el cliente, utilizando la directiva del grupo.

Configure versioning for co-authoring
Configure the co-authoring versioning period
Configure the maximum number of co-authoring authors
Disable co-authoring

Tags: , ,

Sharepoint | TFS

ALM Day 1–Exitósa jornada de ALM sobre Team Foundation Server

por Daniel Laco  3. marzo 2011

 

Ayer 2 de Marzo realizamos exitósamente el evento de ALM (Application Lifecycle Management) sobre TFS.

La jornada se desarrolló en las instalaciones del MUG.

La sala estaba completa, y la inscripción se completo varios días antes de las charlas.

Se pueden bajar las presentaciones aquí

TFS y los productos de terceras partes

por Victor Passador  7. diciembre 2010

Me acabo de cruzar con un post de la gente de Urban Turtle, que me pareció muy interesante.

Habla de herramientas de terceras partes que extienden la funcionalidad de TFS.

Es cada vez mayor la cantidad de herramientas que aparecen en la web que se valen de la extensibilidad que brinda TFS y que proponen complementar y/o optimizar los diferentes aspectos que cubre la solución ALM de MS (además, no sería loco pensar que esta tendencia se vaya acentuando con cada nueva versión de la plataforma).

Si bien esto supone un gran beneficio, aunque más no sea por la cantidad y variedad de la oferta, me pareció interesante difundir algunos de los cuidados que según Mario Cardinal (y quien suscribe) deberíamos tener al momento de elegir alguna de estas herramientas. Todo esto sin mencionar cuestiones de costos por licenciamiento, sólo enfocándonos en cuestiones más bien técnicas.

Antes de que sigan leyendo vale una aclaración. Yo sé que muchos van a pensar que la mayoría de estas cuestiones son más que obvias, pero también sé que ante alguna necesidad concreta de esas que queman, no tenemos demasiado tiempo para andar pensando a mediano o largo plazo y se vuelve muy tentador instalar alguna solución para salir rápidamente del escollo.

Propongo que nos detengamos un minuto y hagamos una checklist que incluya, al menos, alguno de estos puntos:

Soporte

  • Qué tipo de soporte se ofrece?
  • Cuándo fue publicada la última versión? Cada cuanto se publican? Sigue en Beta?
  • Está disponible el código fuente?

Evolución de la plataforma ALM

  • Será fácil migrar cuando aparezca la próxima versión de TFS? (aquel que pueda responder este tipo de preguntas rápidamente, que por favor se contacte por privado porque necesito que me preste la bola de cristal por algunos días)

Relación con el servidor TFS

  • Modifica el esquema de Base de Datos de TFS?
  • Requiere modificación de los templates de proyectos ya creados?
  • Tengo varios proyectos creados con diferentes templates, alguno de ellos personalizado. Se adapta a todos los proyectos?.
  • Y a todos los tipos de Work Item?
  • Tengo varios proyectos, en diferentes versiones de TFS. Aplica a todas las versiones?
  • Qué impacto tiene el hecho de que esa herramienta no aplique para todos mis proyectos y/o versiones de TFS?
  • Qué pasa con el Data Warehouse y con los reportes ?
  • Los que ya están van a seguir funcionando?

 

Deployment y mantenibilidad

  • Sirve para cualquier proyecto que ya esté en marcha o sólo para nuevos proyectos?
  • Requiere instalar algún componente en los clientes?
  • Qué tan compleja es esta instalación?
  • Qué tipo de desarrollos soporta (Winform, Web, WPF, etc.) ?

 

Localization

  • Es compatible con la configuración de mi servidor TFS?
  • Y con la configuración de Collation de mi SQL Server?

 

Verifiquemos por favor que en lugar de encontrar una solución no estemos encontrando un nuevo problema.

Saludos !

Tags: ,

ALM | TFS

Reportes Agiles en Team Foundation Server – Stories Progress Report

por Viviana Chelini  25. noviembre 2010
Ú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.

 

Reportes Agiles en Team Foundation Server – Stories Overview Report

por Viviana Chelini  10. noviembre 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

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.

 

Tags: , ,

ASP.NET | Javascript | ORM | TFS

Reportes Agiles en Team Foundation Server – Status on All Iterations Report

por Viviana Chelini  4. noviembre 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

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.

 

Extendiendo TFS 2010 – Manejo de Eventos

por Victor Passador  1. noviembre 2010

Quisiera abordar en esta oportunidad algún ejemplo de cómo se puede extender, de una manera relativamente sencilla, la funcionalidad de TFS para adaptarlo a necesidades concretas y reales que aparecen diariamente.

Hay varias maneras de extender TFS, pero en esta ocasión, me voy a centrar en el manejo de eventos y sus particularidades y como dije que se puede hacer de manera “relativamente” sencilla, voy a intentar hacerlo en sólo dos pasos:

  1. Escribiendo un servicio web que actualice una base de datos propia con información proveniente de un Work Item modificado.
  2. Eligiendo un evento al que nos vamos a suscribir y vinculándolo con el servicio web.

 

Veamos cómo sale.

Paso 1: El servicio web

El subsistema de eventos de TFS soporta notificaciones basadas en mensajes SOAP, por lo que sólo tendremos que crear un proyecto de tipo Web Service ASP.NET que contenga un método llamado “Notify” y que reciba dos parámetros:

  • eventXml: Es el Work Item serializado. Contiene información acerca de aquellos campos que han cambiado, manteniendo el viejo valor y el nuevo luego de la modificación.
  • tfsIdentityXml: Podemos obtener a través de este parámetro, la URL del servidor TFS que ha realizado la llamada

 

Aquí debajo encontrarán el código del esqueleto del servicio. Sólo restará parsear el work item para obtener la información que nos interese y utilizar ADO.NET o la técnica que prefieran para actualizar la base de datos.

   1: namespace VEMN.ExtendiendoTFS.WebService
   2: {
   3:     [WebService(Namespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/Extensibility", Description = "")]
   4:     [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
   5:     public class MiServicio : EndpointBase
   6:     {
   7:         [WebMethod]
   8:         [SoapDocumentMethod("http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03/Notify", RequestNamespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")]
   9:         public void Notify(string eventXml, string tfsIdentityXml)
  10:         {
  11:  
  12:             // Parsing del work item serializado
  13:  
  14:             // Actualización de la Base de Datos
  15:  
  16:         }
  17:     }
  18: }
   1: namespace VEMN.ExtendiendoTFS.WebService
   2: {
   3:     public class EndpointBase : WebService
   4:     {
   5:         /// <summary>
   6:         /// Deserializes a Type
   7:         /// </summary>
   8:         /// <typeparam name="T">Type to deserialize</typeparam>
   9:         /// <param name="serializedType">serialized version of the type</param>
  10:         /// <returns>DeSerialized version of the type</returns>
  11:         protected T CreateInstance<T>(string serializedType) where T : new()
  12:         {
  13:             T customType = new T();
  14:  
  15:             XmlSerializer serializer = new XmlSerializer(typeof(T));
  16:  
  17:             XmlDocument xmlDocument = new XmlDocument();
  18:             xmlDocument.LoadXml(serializedType);
  19:             XmlNodeReader xmlNodeReader = new XmlNodeReader(xmlDocument);
  20:  
  21:             customType = (T)serializer.Deserialize(xmlNodeReader);
  22:  
  23:             return customType;
  24:         }
  25:     }
  26: }

Paso 2: El evento y la suscripción

El subsistema de eventos de TFS nos permite suscribir a los siguientes sucesos:

Build Completion Event

NodesDeletedEvent

Build Status Changed Event

ProjectCreatedEvent

BranchMovedEvent

ProjectDeletedEvent

NodeCreatedEvent

CheckinEvent

NodePropertiesChangedEvent

WorkItemChanged

NodeRenamedEvent

 

La manera de asociar un evento de TFS al servicio que escribimos en el paso 1, es utilizando el comando “BisSubscribe”. Obviamente nos vamos a “colgar” del evento WorkItemChanged.

La manera de hacerlo es la siguiente:

   1: BisSubscribe.exe /eventType WorkItemChangedEvent /deliveryType Soap /address http://tfsserver/WebService/MiServicio.asmx /collection http://tfsserver:8080/tfs/defaultcollection

Algo a tener en cuenta es que, con la aparición de las Project Collections en TFS 2010, debemos utilizar el parámetro “/collection” del commando BisSubscribe en lugar del parámetro “/server” que se usaba en TFS 2008

Sintonía fina

Habiendo publicado el servicio web y estando suscriptos al evento, sólo restará probar toda la maquinaria actualizando algún Work Item y grabando los cambios. No deberá sorprendernos que la llamada al web service no se haga de manera inmediata. Transcurrirán al menos 2 minutos desde la actualización del Work Item hasta que el método “Notify” sea invocado.

Esto es porque a partir de la versión 2010 de TFS se han optimizado muchos procesos, y en esta línea de mejoras, algunas tareas que antes se hacían de manera sincrónica ahora se realizan asincrónicamente.

Este valor de delay fue establecido pensando en servidores que tienen una alta carga de procesamiento y que atienden gran cantidad de usuarios simultáneamente. Con equipos de trabajo más chicos (unos 10 usuarios simultáneos) tranquilamente se puede bajar ese tiempo a 30 segundos sin notar pérdida de performance. Inclusive es posible llevarlo a cero con el mismo resultado.

Para realizar este cambio, tendremos que utilizar la consola de Power Shell con el siguiente script:

   1: [Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
   2:  
   3:  
   4:  
   5: # Modify the TFS configuration server URL as necessary.
   6:  
   7: $configServer = new-object Microsoft.TeamFoundation.Client.TfsConfigurationServer "http://tfsserver:8080/tfs/"
   8:  
   9:  
  10:  
  11: # Get the TF registry service.
  12:  
  13: $tfsRegService = $configServer.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry])
  14:  
  15:  
  16:  
  17: # Set the notification delay to 30 seconds. All collections will use this delay unless they override this value in the collection hive.
  18:  
  19: $tfsRegService.SetValue("/Service/Integration/Settings/NotificationJobDelay", 30)
  20:  

En este ejemplo se baja el tiempo a 30 segundos. Encontrarán que es muy sencillo modificarlo por el valor que consideren más apropiado.

Haciendo la vida un poco más fácil (todavía)

El comando “BisSubscribe” es bastante críptico. Si cometemos algún error de tipeo al utilizar el comando y el web service no es invocado por culpa de ese error, no será sencillo hallar la solución sin ayuda adicional.

Para no perecer en esa tarea, podemos valernos del plug-in denominado “Alerts Explorer” para Visual Studio que viene con las Team Foundation Server Power Tools, que nos permitirá administrar esas suscripciones utilizando una GUI muy amigable e intuitiva.

image

Hasta la próxima !

Tags: , ,

ALM | TFS

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.

Reportes Agiles en Team Foundation Server – Burndown and Burn Rate Report

por Viviana Chelini  16. 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

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

Burndown and Burn Rate Report

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.

Burndown and Burn Rate Report

 

 

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 positivas del reporte

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.

 Versiones negativas del reporte


Tags: , ,

ALM | Gestión de Proyectos | TFS

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