Agregando Bugs al Board de Web Access - Template MSF for Agile 5.0

por Victor Passador  17. diciembre 2012

TFS 2012 propone gestionar las tareas del desarrollo a través de un Web Access totalmente renovado desde su versión 2010. Utilizando esta herramienta, el PM podrá entre otras cosas, administrar las capacidades del equipo, crear y asignar User Stories, Taks, Bugs, planificar sprints, verificar estado de avance del proyecto a través del Burndown chart, del reporte de salud de los Builds, y varios etcéteras más.

La planificación propiamente dicha, se realiza a través del “Board” (un tablero muy útil en daily meetings además de otros momentos) y facilita la administración de tareas ya que no hay que trasladar el cambio de estado de los papelitos en el “tablero de corcho” a la herramienta, sino que se puede hacer directamente desde ésta.

Considero que la herramienta aporta mucho a la agilidad, pero en ciertos escenarios, se queda corta en posibilidades de personalización.

El caso que quiero plantear se da con un Team Project ya creado y migrado desde la versión anterior, con el template MSF for Agile 5.0, donde quisiéramos que aparezcan en ese board los bugs, además de las tareas.

Aquí se explica cómo es que funciona el board y cuáles son los tipos de Work Item que allí aparecen.

Si bien el texto es claro y con ejemplos, no cubre el 100% de la necesidad de nuestro escenario. Describiré más abajo cuáles son los pasos a seguir (tomando los pasos detallados en el link y ampliando con lo que estaba faltando):


Aclaración 1: Cada uno de estos pasos consiste en exportar desde TFS a un directorio local una sección del Process Template con el que fue creado el Team Project, modificar las entradas que sean necesarias y volver a incorporar esa sección modificada en el servidor, todo esto utilizando el comando witadmin

Aclaración 2: Como estamos modificando definiciones en un servidor que probablemente esté en producción, es buena práctica conservar una copia de cada archivo que obtengamos luego de ejecutar un comando “witadmin exportxxx …”. Si las cosas no salen como esperamos, teniendo un backup, siempre será posible volver todo a su estado inicial ejecutando el comando “witadmin importxxx …”


Paso 1: “Bajar” la definición de categorías del template para poder incluir a los bugs dentro de la categoría Task Category (hace un tiempo escribí aquí sobre categorías de Work Items)

witadmin exportcategories
     /collection:CollectionURL
     /p:ProjectName
     /f:"DirectoryPath\categories.xml"

Paso 2: Modificar la sección correspondiente para que quede como se muestra a continuación

<CATEGORY name="Task Category" refname="Microsoft.TaskCategory">
   <DEFAULTWORKITEMTYPE name="Task" />
   <WORKITEMTYPE name="Bug" />
</CATEGORY>

Paso 3: “Subir” la nueva definición

witadmin importcategories
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\categories.xml"

Paso 4: “Bajar” la definición de configuración para agregar los estados (metastates) y así unificar entre Task y Bugs

witadmin exportcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"

Paso 5: Modificar la sección correspondiente para que quede como se muestra a continuación

<TaskWorkItems category="Microsoft.TaskCategory">
    <States>
       <State value="Active" type="Proposed"/>
        <State value="Resolved" type="InProgress"/>
        <State value="Closed" type="Complete"/>
    </States>
</TaskWorkItems>

Paso 6: “Subir” la nueva definición

witadmin importcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"


Atención: En el ejemplo del artículo de MSDN hay una entrada para el estado “New”, pero debemos eliminarla porque no existe ese estado en el template MSF for Agile 5.0.  Si omitimos ese cambio, obtendremos un error al ejecutar el comando witadmin importcommonprocessconfig


Paso 7: “Bajar” la definición de Bug para poder modificar el template y agregar el campo Activity

witadmin exportwitd
    /collection:CollectionURL
    /p:ProjectName
    /n:Bug
    /f:"DirectoryPath\Bug.xml"

Paso 8: Modificar la sección correspondiente para que quede como se muestra a continuación

<FIELD name="Activity" reportable="dimension" type="String" refname="Microsoft.VSTS.Common.Activity">
    <HELPTEXT>Type of work involved</HELPTEXT>
    <SUGGESTEDVALUES expanditems="true">
        <LISTITEM value="Development"/>
        <LISTITEM value="Requirements"/>
        <LISTITEM value="Design"/>
        <LISTITEM value="Testing"/>
        <LISTITEM value="Deployment"/>
        <LISTITEM value="Documentation"/>
    </SUGGESTEDVALUES>
</FIELD>

Paso 9: “Subir” la nueva definición

witadmin importwitd
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\Bug.xml"


Aclaración: Si bien estamos agregando este campo a la definición del bug porque el bug ahora pertenece a la categoría TaskCategory (paso 1) y requiere de esta definición, no es necesario modificar el Layout de edición a menos que queramos tener acceso a ese campo al momento de editar un bug.


Conclusión

Como ven en la captura, ahora tenemos visibilidad de los Bugs en el board Agile, y además, se ve una nueva columna (Resolved) que muestra los bugs en ese estado. Por favor no tomen en cuenta el Burndown Chart, es sólo un proyecto para pruebas Smile

image
 
Si después de realizar todo el proceso, los bugs siguen sin aparecer, por favor revisen que estén vinculados a la respectiva User Story.

Hasta la próxima!

Tags: , ,

ALM | Gestión de Proyectos | TFS

Receta mágica de ALM para aplicar en TFS

por Victor Passador  26. marzo 2011

En la búsqueda diaria de la solución absoluta y definitiva a los problemas de gestión del código fuente, di con un post de El Bruno donde plantea algo muy simple pero efectivo:

1. Formación

    1.1 Conocer las capacidades de la herramienta

    1.2 Conocer la problemática del negocio

2. Tomar una decisión para comenzar a trabajar

3. Cada 6 semanas/meses ajustar la forma de trabajo

4. Goto 2

 

Según El Bruno, esto surge como conclusión de una Mesa Redonda con la gente de MadridDotNet donde se compartieron experiencias de administración de código fuente en cuestiones de branching, merge, archivos históricos, la maldición del checkout exclusivo y otras cuestiones.

Recomiendo su lectura, es un post cortito y ameno.

Hasta la próxima !

Tags: ,

Gestión de Proyectos | ALM

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