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!

 

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:

 

 

Hace unos días publiqué un post donde mencionaba los recaudos mínimos que deberíamos considerar al momento de instalar algún Add-on para TFS (vale también para VS).

Como no quiero que me consideren “apocalíptico” ni mucho menos trataré, por un lado, de mostrar las herramientas que nosotros hemos instalado y utilizado largamente y que nos han facilitado la vida en muchas oportunidades (o que estamos testeando con TFS 2010). Por el otro, me gustaría que ustedes comenten acerca de las experiencias que han tenido para que este post sirva, de alguna manera, como referencia de las herramientas que todo administrador o usuario de TFS debiera tener en su toolkit.

Empiezo yo:

Administración General

• Team Foundation Server Tools 2010: Un viejo conocido, en su versión para TFS 2010, que entre otras cosas incluye:
  • Alerts Explorer: UI gráfica que permite suscribirse a los diferentes eventos del servidor (cambio de un work-item, build terminado, nuevo check-in, etc.)
  • TFS Backups: administra un schedule para backups de la base de datos de configuración, de los proyectos de la colección, sharepoint (si se instaló con la integración de esa herramienta), reporting services (ídem)
  • Best Practices Analyzer: Verifica problemas de deploy, data usage, etc.
  • Pack de políticas de check-in
  • Mejoras para Team Explorer
  • Editor de Templates
• Team Foundation Sidekicks: Excelente herramienta de Attrice que permite visualizar/administrar entre otras cosas:
  • Historial de archivos del Source Control
  • Status (cheched out, locks, etc.)
  • Workspaces
  • Labels
  • Etc.

 

Seguridad

• Team Foundation Server Administration Tool: Uno de los problemas recurrentes al administrar proyectos de TFS es el de configurar permisos de usuarios. Hay que administrar seguridad tanto en el servidor TFS, el servidor de reportes y el sitio Sharepoint, cada uno con sus particularidades. Esta herramienta permitirá hacerlo todo junto desde un mismo lugar

 

Templates

• Microsoft Visual Studio Scrum 1.0: Uno de los templates más esperados.
• Scrum for Team System (antes conocido como Conchango): Excelente template Scrum, ahora en su versión para TFS 2010
• TMap for VS 2010: Un template para proceso de testing desarrollado por Sogeti en colaboración con MS

 

Visual Studio

• Productivity Power Tools (no es puramente TFS, pero los programadores –y otros- agradecidos) 
  • Solution Navigator: Permite ver clases (y sus miembros) desde el Solution Explorer, con filtros para visualizar solamente archivos abiertos, sin grabar, etc., vistas previas, y más.
  • Tab Well UI: Permite más posibilidades de manejo de ventanas del IDE para uso con múltiples monitores, tabs fijos (para que no desaparezcan cuando hay muchos documentos abiertos), coloreo de tabs según ciertas condiciones (soporta expresiones regulares), etc.
  • Searchable Add Reference Dialog: Ahora podemos hacer búsquedas al agregar referencias a nuestro proyecto !
  • Y mucho más …

Otros

• Team Foundation Server MSSCCI Provider 2010: Permite acceso al Version Control de TFS a herramientas que no soportan integración con Team Explorer, por ejemplo:
  • Visual Studio 2003
  • Visual Foxpro 9 SP2
  • Microsoft Access 2007
  • Powerbuilder 11.5
  • Enterprise Architect 7.5
  • y otros …
• VS Team Explorer Everywhere 2010: Permite acceso a TFS de cualquier IDE basada en Eclipse.

 

Creo que tengo alguna otra más para compartir, pero les dejo la posta a Uds. …

Saludos !

Ú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

 

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

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.

 

 

Dónde quedan los reportes de TFS2008 cuando se realiza la migración a TFS 2010?

A no preocuparse si acceden a los viejos reportes y ven que la fecha de actualización del cubo quedó congelada a la fecha de la migración, porque los reportes están ahora en una nueva locación

Por los cambios producidos en los modelos en la nueva version 2010, el proceso de actualización que realiza TFS hace que se instalen las nuevas bases de datos y cubos siguiendo el concepto de Project Collections (ver http://www.vemn.com.ar/Blog/post/Nuevos-conceptos-en-TFS-2010.aspx)

Las bases anteriores TFSWarehouse y al cubo también llamado de la misma manera siguen existiendo y los reportes en Reporting Services (SSRS) siguen apuntando a esta base .

Pero los reportes para los templates basados en MSF for Agile y MSF for CMMI en la versión 4.2 son migrados a un nuevo directorio en Reporting Services. Este directorio se llama TFSReports y dentro de él está el directorio DefaultCollections (esto dependiendo del nombre de la collection que fué creada en la migración). Dentro de este último directorio vamos a encontrar todos los reportes de los proyectos anteriores migrados a la nueva versión 2010 de TFS.

Por supuesto, que todos los proyectos abiertos desde Visual Studio, apuntan ahora a la nueva ubicación. Esta ubicación es sacada desde la consola de configuración de TFS.

En el gráfico siguiente, está un esquema de como quedan ahora las bases de datos y los Data Sources de Reporting Services

 

 

Tambien tenemos nuevos Data Sources

 

Aquí les dejo una serie de link sobre información puntual sobre el tema de reportes (algunos extraidos del blog de Buck Hodges:

Sunder Raman, Program Manager para TFS, ha escrito una serie de post (en inglés) sobre los cambios en el almacenamiento y en los cubos para 2010.

Reporting

• Reporting in Team Foundation Server 2010 – Part 1: Introduction
• Reporting in Team Foundation Server 2010 – Part 2: SharePoint Dashboards: SharePoint Server dashboard
• Reporting in Team Foundation Server 2010 – Part 3: SharePoint Dashboards: SharePoint Server dashboard customization
• Reporting in Team Foundation Server 2010 – Part 4: SharePoint Dashboards: Creating a team dashboard
• Reporting in Team Foundation Server 2010 - Part 5: SharePoint Foundation Dashboard
• Reporting in Team Foundation Server 2010 - Part 6: Rich SQL Reporting Services Reports
• Reporting in Team Foundation Server – Part 7: Excel Reports from Work Item Queries
• Reporting in Team Foundation Server 2010 – Part 8: Custom Reports: Options & Tools

 

Customizing Reports for Team Foundation Server 2010 (en MSDN)

Cube

• Team Foundation Server 2010 – Cube Schema Changes in Beta 2
• Team Foundation Server 2010 – Cube Schema Changes in RTM

 

 

John Socha-Leialoha, escribió una serie de post sobre la actualización de reportes en TFS

• Upgrading Team Foundation Server 2008 Reports to 2010, Part I (originally written for beta 1 - part 2 describes changes between beta 1 and beta 2)
• Upgrading Team Foundation Server 2008 Reports to 2010, Part II
• Upgrading Team Foundation Server 2008 Reports to 2010, Part III

Siguiendo con nuestra idea de mostrar novedades que exceden la calificación de “nueva característica”, y que nos ponen en situación de repensar algunas situaciones, quisiera comentar sobre las Categorías de Work Items.

Ahora, con TFS 2010, podemos categorizar Work Items, pero … ¿por qué querríamos o necesitaríamos hacer esto?.

Porque tendríamos la posibilidad de tratar de la misma manera a aquellos work items que son diferentes pero parecidos, teniendo en cuenta que cuando hablo de “tratar” estoy apuntando al seguimiento de esos work items. Con este nuevo agrupamiento podríamos por ejemplo:

• Construir queries, con una sintaxis mucho más simple e intuitiva, que devuelvan work items de más de un tipo. ¿O acaso una “User Story” y un “Quality of Service Requirement” no son en definitiva requerimientos del usuario?
• Construir reportes de manera más simple apuntando a obtener resultados más “macro” sin resignarnos a perder el detalle de lo que hay debajo (… o ver el bosque y también ver los árboles). Cada work item tendrá su propia estructura de datos, con el nivel de detalle que requiera cada uno, pero aquella información que tengan en común podría ser explotada en reportes utilizando estas nuevas categorías.
• Construir Test Suites utilizando Microsoft Test Manager (el nuevo integrante de la familia TFS, del que estaremos posteando/presentando novedades muy pronto)

 

Para crear queries que respondan a este nuevo agrupamiento, tenemos disponible el comando “In Group”. Aquí tienen un ejemplo de una query utilizada por el Microsoft Test Manager que se vale de este nuevo operador.

Estas categorías están definidas en el template con el cual fue creado el proyecto. Es por este motivo que no encontraremos (al menos por ahora) ningún botón que diga “Add New Category”.

Pero no todo está perdido, si nos damos un poco de maña, nos prometen que podemos categorizar work items en proyectos que no tenían esa facilidad.

Hasta la próxima !