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 
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!