Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs

Visual Studio 2013

Los clientes de empresa han visto las ventajas de contar con equipos individuales ágiles. Sin embargo, escalar estas prácticas a todos los equipos e implementar la agilidad en el ámbito empresarial presenta varios desafíos. El marco Scaled Agile Framework® (SAFe™) proporciona una guía sobre cómo superar estos retos y escalar la agilidad. Si usted dispone de una implementación local de TFS 2013, puede utilizar SAFe.

Para realizar un seguimiento de los criterios de SAFe, puede utilizar proyectos de equipo creados con plantillas de proceso TFS predefinidas. En este artículo se explican la asignación de conceptos SAFe a TFS, la planeación y el seguimiento de proyectos SAFe y la configuración y personalización de TFS para admitir SAFe.

Si está familiarizado con Scrum pero no con SAFe, estos vídeos de Scaled Agile Framework Foundations creados por Inbar Oren —Lean Samurai—, le servirán de orientación.

Asignación de conceptos SAFe a conceptos TFS

SAFe admite una vista de cartera de varios equipos ágiles y muestra cómo una jerarquía de equipos —todos ellos con sus propios objetivos específicos— cumple con una visión de cartera. Este marco desglosa epopeyas (Epics) en características (Features) y casos (Stories), que los equipos trabajan en Sprints y entregan mediante incrementos de programa (PI, Program Increments) y trenes de versión (Release Trains). Además, el trabajo pendiente de cartera puede realizar un seguimiento de cómo se asignan las entregas a temas estratégicos (Strategic Themes) y presupuestos asociados (budgets).

Imagen cortesía de Leffingwell, LLC.

Los ejemplos de este documento muestran cómo agregar el WIT —tipo de elemento de trabajo— Epic (epopeya) y el trabajo pendiente, configurar una jerarquía de equipo de tres niveles y asignar equipos a sus respectivas áreas y rutas de iteración. Los ejemplos se compila a partir de la plantilla de proceso Agile de TFS. Sin embargo, los cambios pueden aplicarse a cualquier plantilla de proceso de TFS.

Los equipos, los programas y las carteras de SAFe se asignan a los equipos y proyectos de equipo de TFS

Dado que TFS admite una estructura jerárquica de equipo, cada equipo tiene una vista propia de su trabajo que se acumula en el siguiente nivel dentro de la jerarquía del equipo.

Para admitir equipos SAFe, reconfigure el equipo predeterminado como el equipo de cartera que administra sus epopeyas. A continuación cree subequipos para el trabajo de nivel de programa y de nivel de equipo. El trabajo se puede controlar en todos los equipos y niveles.

Asignación de trabajos pendientes de SAFe a trabajos pendientes de TFS

De forma predeterminada, TFS admite los niveles de caso y de trabajo pendiente de características. Usted puede agregar fácilmente un tercer nivel para realizar un seguimiento de las epopeyas. Los casos de usuario pueden asignarse a las características que, a su vez, pueden asignarse a epopeyas. Una vista jerárquica de los trabajos pendientes muestra cómo el progreso de los casos de usuario contribuye a las epopeyas.

Asignación de Sprints, iteraciones y lanzamientos de SAFe a iteraciones de TFS

Los Sprints, los incrementos de programa (PI), las iteraciones, los lanzamientos y los trenes de versión de SAFe se asignan fácilmente a las rutas de acceso de iteración de TFS. Al compartir las iteraciones en la jerarquía del equipo, los lanzamientos se administran de una manera coherente.

El equipo de cartera realiza el seguimiento de las epopeyas, que pueden abarcar varios trenes de versión o PI. Los equipos del programa siguen las entregas de características, que se envían con una PI. Y los equipos de características trabajan en Sprints para completar varios casos. Con TFS, cada equipo elige qué iteraciones serán compatible con ellos para realizar el seguimiento de sus entregas de equipo.

Asignación de temas estratégicos y presupuestos de SAFe a etiquetas y campos de TFS

Puede utilizar etiquetas para asignar epopeyas a temas estratégicos o presupuestos asociados.

Puede buscar y consultar etiquetas en TFS y también crear consultas reutilizables e informes con etiquetas.

Para una asignación más sólida del trabajo a temas estratégicos y presupuestos, puede agregar un campo a sus elementos de trabajo a fin de realizar un seguimiento de los temas o presupuestos que admite cada epopeya, característica o caso.

Métrica de SAFe e informes de TFS

Agregue o personalice un informe para ver las métricas de SAFe. Por ejemplo, el informe de progreso de características (Feature Progress), similar a un informe de información general de casos (Stories Overview), muestra qué características están a punto de finalizar y cuáles están iniciándose. Cuando los equipos trabajan en casos vinculados a características, aparece una barra de progreso que describe el porcentaje (%) de progreso de una determinada característica. Los participantes tienen datos útiles para administrar el ámbito, los recursos y la prioridad.

Si desea descargar una versión del informe de progreso de características, puede hacerlo aquí.

Planear y seguir proyectos de SAFe en TFS

Una vez que haya configurado TFS para admitir SAFe, cree las relaciones de seguimiento de casos a epopeyas. Además, puede ver el progreso desde los niveles de equipo de cartera, programa y características.

Asignar características a epopeyas y casos a características

El equipo de programas puede asignar características a epopeyas mediante el panel de asignación. Los equipos de características pueden hacer lo mismo para asignar sus casos a las características.

Vista del progreso del equipo de cartera

Para realizar un seguimiento del progreso de las epopeyas que abarcan lanzamientos, el trabajo pendiente del equipo de cartera muestra las epopeyas. Las epopeyas se pueden expandir para mostrar las características y los casos de usuario que lo permitan.

El equipo de cartera también puede ver el progreso de las epopeyas en su panel kanban.

Vista del progreso del equipo de programa

Los equipos de programa, principalmente los relacionados con trenes de versión, pueden ver las características en su trabajo pendiente, junto con los PI a los que están asociados.

Al igual que el equipo de cartera, los equipos de programa también pueden alternar la vista para ver qué epopeyas son compatibles con sus características, los casos de usuario que admiten sus características, o las dos cosas.

Otra de las vistas disponibles para los equipos de programa muestra gráficos basados en consultas del progreso del tren de versión, los elementos de trabajo pendiente o las tareas activas durante un sprint de envío. Cada equipo dispone de una vista personalizable de página principal.

Dado que gran parte del trabajo de un equipo de programa gira en torno a los PI y a los trenes de versión, podría ser útil disponer de un informe personalizado que muestre las fechas de envío programadas y lo que se proyecta incluir en un tren determinado. Además, si su implementación de TFS incluye integración con Project Server o de SQL Server Reporting Services, puede sacar partido de las completas opciones de informes y de los informes integrados que ofrecen cada uno de estos servicios.

Vista del progreso del equipo de características

La vista de trabajo pendiente de los equipos de características individuales muestra los casos en los que esos equipos están trabajando.

Dado que los equipos de características no poseen epopeyas ni características, estas no aparecen en sus vistas de trabajo pendiente en el nivel de equipo. Sin embargo, si el equipo desea saber qué epopeyas y características son compatibles con sus casos, pueden activar esas vistas desde su trabajo pendiente.

También pueden desglosar su trabajo en tareas y utilizar el panel de tareas para mantenerse informados durante sprints específicos.

La vista del gráfico de consultas es muy útil en el sprint de innovación y planeamiento (IP, Innovation and Planning), cuando los equipos de características colaboran para dar estabilidad a las características programadas para una versión.

Por lo demás, el trabajo es el acostumbrado para equipos individuales de características. Puede realizar el sprint a su ritmo habitual. También pueden usar el panel kanban y el panel de tareas para realizar el seguimiento del progreso y dividir el trabajo en fragmentos más manejables.

No obstante, ahora los equipos de administración de programas y carteras pueden ver su progreso en casos individuales. La vista de administración refleja lo que hacen.

Configurar TFS para admitir SAFe

En esta sección pasaremos de tener un proyecto, denominado “Fabrikam”, y un equipo, que comparte el nombre del proyecto, a la siguiente estructura de tres niveles y nueve equipos. La jerarquía de la ruta de acceso de área y la configuración de la ruta de acceso de área de cada equipo son compatibles con la vista de trabajo pendiente de cada equipo y el consolidado de vistas dentro de la jerarquía.

Cada proyecto de TFS tiene un equipo predeterminado. Puede configurar equipos adicionales para el trabajo en el ámbito de programas y en el de equipos de características. También puede redefinir el equipo predeterminado como el equipo de cartera que administra las epopeyas.

De este modo, todos los equipos pueden administrar su propia carga de trabajo y sus prioridades al tiempo que comprenden con claridad que su trabajo es compatible con esas epopeyas administradas en el trabajo pendiente del equipo de cartera. Al mismo tiempo, el equipo de cartera puede supervisar el progreso de su trabajo pendiente en su propio panel kanban, priorizar los elementos del trabajo pendiente y ver el progreso en los trenes de versión.

Todo esto puede parecer complicado, pero en realidad hace falta muy poca configuración para establecer los equipos y empezar a trabajar.

Empezaremos por un proyecto con un equipo predeterminado, un área y un conjunto de iteraciones. En primer lugar, configuraremos una estructura de ruta de acceso de área para admitir la jerarquía de los equipos deseada. A continuación, nos aseguraremos de que las rutas de acceso de iteración son compatibles con la estructura de la versión que queremos y con los equipos de programa y características que se van a usar. Por último, crearemos, configuraremos y rellenaremos las suscripciones de los equipos.

Es necesario ser miembro del grupo de administradores de proyectos para configurar y personalizar TFS.

Crear áreas para admitir la jerarquía del equipo

1. Conéctese al proyecto de equipo que desea configurar para admitir SAFe y utilice el icono de engranaje para abrir la página de administración del equipo predeterminado.

2. En la página Áreas, cree un elemento secundario bajo la ruta de acceso del área de nivel superior y asígnele un nombre que corresponda a uno de los equipos de programa que se va a crear.

   

3. A continuación, cree una segunda área en el mismo nivel secundario y asígnele el nombre del segundo equipo de programa.

4. En cada área del programa, cree un subárea para cada equipo de características que será compatible con su correspondiente equipo de programa. El resultado final debería ser una jerarquía de ruta de acceso de área de 3 niveles.

   

Crear iteraciones para admitir los trenes de versión y los sprints

Para seguir el progreso hacia las versiones, cree la estructura de ruta de acceso de iteración. A diferencia de las rutas de acceso de área, varios equipos pueden compartir la misma estructura de ruta de acceso de iteración. El uso compartido de la estructura de iteración permite que varios equipos trabajen en la misma cadencia de Sprint y hacia los mismos trenes de versión.

Si ya dispone de las iteraciones para su equipo predeterminado, puede cambiar su nombre. Necesitará crear una estructura de iteración que sea compatible con toda la estructura de equipos, no con un solo equipo.

1. En la iteración predeterminada, que comparte el mismo nombre que el proyecto, cree una iteración secundaria que representará el primer incremento del programa (PI). Opcionalmente, agregue una fecha de inicio y de finalización para el PI, pero tenga en cuenta que la iteración se desglosará en sprints.

   

2. A continuación, cree una iteración secundaria para cada sprint en el PI. Establezca fechas para estos sprints que se correspondan con las cadencias de los equipos de características.

   

Crear y configurar los equipos

En esta sección configuraremos una estructura jerárquica de equipo que se asigna a las rutas de acceso de área jerárquica que hemos creado anteriormente.

Esta estructura asigna los siguientes equipos de SAFe a equipos TFS:

• Equipo de cartera -> equipo de nivel superior predeterminado (equipo Fabrikam)

• Equipos de programa -> equipos de nivel secundario (Fiber Suite y Service Suite)

• Equipos de características -> equipos de nivel terciario definidos en Fiber Suite y Service Suite.

Si necesita orientación más detallada, consulte Administración de carteras Agile: Usar TFS para admitir trabajos pendientes en varios equipos.

Para poder realizar estos pasos, debe ser administrador de proyectos.

Crear y configurar los equipos de programa

1. En la página Información general del proyecto de equipo, cree un equipo nuevo. Asegúrese de desactivar la casilla Cree una ruta de acceso del área con el nombre del equipo.

   

2. Elija el equipo en la lista, vaya a la página Áreas y seleccione la casilla situada junto a la ruta de acceso del área que creó anteriormente para ese equipo.

   

3. Utilice el menú contextual para excluir las subáreas. Al excluir las subáreas, el trabajo pendiente del equipo solo incluye aquellos elementos cuya ruta de acceso del área coincide con la ruta de acceso del área predeterminada del equipo.

   

4. A continuación, configure las iteraciones que estarán activas el equipo de programa. En este ejemplo, hemos configurado tres PI, cada uno con cinco sprints de dos semanas. Cuatro de los sprints son regulares y el último es un sprint de innovación y planeamiento (IP).

   

     

   Dado que la preocupación del equipo de programa Fiber Suite son los trenes de versión, elegimos PI 1, 2 y 3, pero no elegimos los sprints individuales.

5. Una vez que ha seleccionado las iteraciones que están activas para el equipo, agregue usuarios al nuevo equipo. Lo ideal sería agregar los facilitadores (scrum master) de cada equipo de características, los propietarios de producto y los ingenieros de trenes de versión (RTE, por sus siglas en inglés) a los equipos de programa, como Fiber Suite.

   

6. Si dispone de más de un equipo en el nivel de programa, repita los pasos 1 a 5 con cada equipo de programa.

Crear y configurar los equipos de características

A continuación, vamos a crear algunos equipos de características para realizar el trabajo en el tercer nivel de la jerarquía de equipo. Cada equipo de características contribuirá al trabajo de sprint que se acumula en el PI. El número de equipos que cree dependerá del tamaño de su organización.

1. Cree un nuevo equipo desde la página de administración del equipo original y asígnele un nombre. Igual que antes, asegúrese de desactivar la casilla situada junto a Cree una ruta de acceso del área con el nombre del equipo.

   

2. Elija el equipo en la lista, vaya a la página Áreas y seleccione la casilla situada junto a la ruta de acceso del área que creó anteriormente para ese equipo.

   

3. Configure las iteraciones para el equipo con los PI y los sprints que creó previamente. A diferencia de con los equipos de programa, esta vez seleccione los sprints individuales como las iteraciones de trabajo para el equipo de características.

   

4. Agregue las cuentas de los desarrolladores, los evaluadores y el facilitador para el equipo. TFS admite la asignación de un facilitador a varios equipos. El facilitador puede realizar un seguimiento del trabajo en varios equipos.

   

5. Repita los pasos 1 a 4 con cada equipo de características de su organización. Asegúrese de que la ruta de acceso del área predeterminada que configure para el equipo sea una ruta de acceso de subárea que se encuentre en su correspondiente ruta de acceso del área de nivel de programa. Esto garantiza el consolidado de equipos de características en los equipos de programa.

Configurar el equipo de cartera

Ahora que la estructura del equipo secundario está configurada, vuelva a configurar el equipo predeterminado para que actúe como el equipo de cartera. Aunque este equipo seguirá teniendo el nombre del proyecto, los cambios que haga en este equipo de nivel superior le ayudarán a asegurarse de que realiza un seguimiento eficaz de las epopeyas en los PI del nivel más alto.

1. En la página Áreas del proyecto de equipo, cambie la configuración para que no se incluyan las subáreas. Asegúrese de que elige el proyecto de equipo y no el equipo predeterminado Fabrikam.

   

2. En la página Iteraciones, desactive las casillas de todas las iteraciones excepto la del nivel raíz, que no se puede borrar. Dado que la única preocupación del equipo de cartera son las epopeyas que abarcan PI, únicamente utiliza la iteración de raíz y no los PI o los sprints. Los equipos de cartera no trabajan en sprints.

   

3. Agregue y quite usuarios del equipo de cartera correspondiente a este nivel. En la página Información general, elija del equipo predeterminado.

   

      

   Considere la posibilidad de agregar otras personas, como administradores de carteras, arquitectos de nivel empresarial e ingenieros de tren de versión (RTE) en este nivel y quitar todos los demás.

   

Personalizar el proceso TFS para admitir SAFe

En esta sección agregaremos el WIT de epopeya a la jerarquía de trabajo pendiente de cartera. También agregaremos el campo Tipo de requisito a los tres WIT de trabajo pendiente. Además, crearemos algunas epopeyas y asignaremos características a epopeyas.

Si está más interesado en el funcionamiento posterior a la adición del nivel de trabajo pendiente de epopeya, haga clic aquí. Si prefiere no realizar usted mismo los pasos de personalización que se describen en esta sección, los ALM Rangers tienen una entrada de blog y un script de PowerShell de ejemplo en donde se explica cómo instalar estas personalizaciones en el proyecto.

Agregar la epopeya al trabajo pendiente de cartera

Al igual que antes, debe ser miembro del grupo de administradores de proyectos para poder llevar a cabo estos pasos.

En primer lugar, exportaremos un WIT existente y lo usaremos para crear el nuevo WIT, al que llamaremos Epic (epopeya). También agregaremos un campo de tipo de requisito para realizar un seguimiento del tipo de epopeya que es: arquitectura o empresa. A continuación, agregaremos una categoría para las epopeyas. Después modificaremos los WIT existentes ─características y casos de usuario, incluso si no se llaman así— para incluir el campo Tipo de requisito. El campo Tipo de requisito realiza un seguimiento del tipo de objetivo que admite cada elemento de trabajo. Por último, agregaremos la epopeya Epic al trabajo pendiente del equipo de cartera.

Agregar el WIT de epopeya

La manera más fácil de crear un WIT es copiar uno existente, cambiar su nombre y a continuación editarlo.

Vamos a exportar el WIT de característica y lo utilizaremos como base para el WIT de epopeya.

1. En el modo de administrador, abra una ventana de símbolo del sistema. Cambie el directorio por la ruta en la que instaló Visual Studio (o Team Explorer).

   cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDE

   En las ediciones de 64 bits de Windows, use %programfiles(x86)%.

2. Utilice la herramienta witadmin para descargar la definición de WIT de característica y guárdela como Epic.xml.

   witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Epic.xml"

3. Abra el archivo Epic.xml, reemplace <WORKITEMTYPE name="Feature"> por <WORKITEMTYPE name="Epic"> y actualice la descripción.

   <witd:WITD application="Work item type editor" version="1.0" xmlns:witd="https://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
   <WORKITEMTYPE name="Epic">
      <DESCRIPTION>Tracks an Epic that will span Releases. </DESCRIPTION>
   

4. Edite la sección <Tab Label="Implementation"> o, para CMMI, <Tab Label="Requirements">, reemplazando las líneas siguientes por <Filter WorkItemType="Feature" />.

   • Agile: <Filter WorkItemType="User Story" />

   • Scrum: <Filter WorkItemType="Product Backlog Item" />

   • CMMI: <Filter WorkItemType="Requirement" />

     Con este cambio se restringe el control de vínculos para admitir características como secundarios elementos epopeyas.

   <Tab Label="Implementation">
      <Control Type="LinksControl" Name="Hierarchy" Label="" LabelPosition="Top">
         <LinksControlOptions>
             <WorkItemLinkFilters FilterType="include">
                <Filter LinkType="System.LinkTypes.Hierarchy" FilterOn="forwardname" />
             </WorkItemLinkFilters>
             <WorkItemTypeFilters FilterType="include">
                <Filter WorkItemType="Feature" />
             </WorkItemTypeFilters>
             <ExternalLinkFilters FilterType="excludeAll" />
             <LinkColumns>
                <LinkColumn RefName="System.ID" />
                <LinkColumn RefName="System.Title" />
                <LinkColumn RefName="System.AssignedTo" />
                <LinkColumn RefName="System.State" />
                <LinkColumn LinkAttribute="System.Links.Comment" />
             </LinkColumns>
          </LinksControlOptions>
   

5. Agregue el campo Tipo de requisito a la definición de WIT de epopeya. Para ello, tomaremos prestado un campo existente (creado originalmente para admitir proyectos CMMI, pero igualmente útil aquí para nuestros fines) Microsoft.VSTS.CMMI.RequirementType y lo agregaremos a la sección FIELDS de la epopeya.

   Busque la sección FIELDS y agregue este código:

   <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
      <REQUIRED />
      <ALLOWEDVALUES>
         <LISTITEM value="Architecture" />
         <LISTITEM value="Business" />
      </ALLOWEDVALUES>
      <DEFAULT from="value" value="Business" />
      <HELPTEXT>Indicates whether this supports business or architectural objectives.</HELPTEXT>
   </FIELD>
   

6. A continuación, agregue el campo al formulario. En la sección FORM, agregue el campo donde crea que funciona mejor para su negocio. En el ejemplo siguiente, lo hemos agregado debajo del campo de iteración.

   <Group Label="Classification">
      <Column PercentWidth="100">
         <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
         <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
         <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
   

7. Guarde y después importe el archivo.

   witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Epic.xml"

Agregar la categoría de epopeya (Epic)

Ahora que tenemos un WIT de epopeya, vamos a agregar una categoría para epopeyas. TFS administra trabajos pendientes basados en categorías.

1. Exporte la definición de categorías a un archivo xml.

   witadmin exportcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

2. Abra el archivo y agregue la categoría de epopeya. Si desea personalizar el nombre, reemplace Microsoft por el nombre de su compañía.

   <CATEGORY name="Epic Category" refname="Microsoft.EpicCategory">
      <DEFAULTWORKITEMTYPE name="Epic" />
   </CATEGORY>
   

3. Al igual que antes, importe el archivo.

   witadmin importcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

Agregue el campo Tipo de requisito para realizar un seguimiento del trabajo de empresa/arquitectura

A continuación, vamos a agregar el campo Tipo de requisito a las características y en el tercer nivel de elemento de trabajo pendiente, ya sea un caso de usuario, un elemento de trabajo pendiente del producto u, opcionalmente, un error. No tiene que agregarlo al requisito, porque ya está incluido en la definición de CMMI predeterminada.

1. Exporte la definición de WIT de característica.

   witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Feature.xml"

2. Agregue el campo Tipo de requisito, tal como hizo anteriormente con el WIT de epopeya. Busque la sección FIELDS y agregue este código:

   <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
       <REQUIRED />
       <ALLOWEDVALUES>
           <LISTITEM value="Architecture" />
           <LISTITEM value="Business" />
       </ALLOWEDVALUES>
       <DEFAULT from="value" value="Business" />
        <HELPTEXT>Indicates whether this supports business or architectural objectives</HELPTEXT>
   </FIELD>
   

3. Agregue el campo al formulario en la misma posición que lo agregó a la epopeya. Por ejemplo:

   <Group Label="Classification">
      <Column PercentWidth="100">
         <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
         <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
         <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
   </Column>
   

4. Guarde y después importe el archivo.

   witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Feature.xml"

5. Repita los pasos del 1 al 4 para las definiciones de WIT de caso de usuario y elemento de trabajo pendiente del producto. Como opción, puede editar la definición de WIT de error si desea realizar un seguimiento del requisito que admiten los errores, o si hace un seguimiento de los errores del trabajo pendiente.

Agregar la categoría de epopeya a la jerarquía de trabajo pendiente de cartera

A continuación agregaremos epopeyas a la jerarquía de elementos de trabajo que componen el trabajo pendiente.

1. Exporte el archivo de definición XML de la configuración de proceso.

   witadmin exportprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

2. Abra el archivo y agregue una sección PortfolioBacklog para epopeyas dentro de la sección PortfolioBacklogs. Al mismo tiempo, modifique el elemento PortfolioBacklog para FeatureCategory de modo que las epopeyas sean un elemento primario de las características.

   Modifique las asignaciones de metaestado según sea necesario según la plantilla de proceso. El siguiente ejemplo es compatible con proyectos de Agile y CMMI. Además, agregue el campo Tipo de requisito a la sección Columns.

   <PortfolioBacklogs>
     <PortfolioBacklog category="Microsoft.EpicCategory" pluralName="Epics" singularName="Epic">
         <States>
         <State value="New" type="Proposed" />
         <State value="Active" type="InProgress" />
         <State value="Resolved" type="InProgress" />
         <State value="Closed" type="Complete" />
         </States>
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
       . . .
   </PortfolioBacklog>        
   

   Los proyectos Scrum requieren asignar los siguientes estados de flujo de trabajo: nuevo, en curso y finalizado. Se trata de los mismos estados que se asignan para el elemento de trabajo pendiente de cartera de característica.

           <State type="Proposed" value="New" />
           <State type="InProgress" value="In Progress" />
           <State type="Complete" value="Done" />
   

   Los proyectos CMMI requieren asignar los siguientes estados de flujo de trabajo: propuesto, activo, resuelto y cerrado.

           <State value="Proposed" type="Proposed" />
           <State value="Active" type="InProgress" />
           <State value="Resolved" type="InProgress" />
           <State value="Closed" type="Complete" /> 
   

3. A continuación, agregue parent="Microsoft.EpicCategory" a PortfolioBacklog category="Microsoft.FeatureCategory". Además, agregue el campo Tipo de requisito a la sección Columns.

   <PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.EpicCategory" pluralName="Features" singularName="Feature">
      . . .
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
       . . .
   
   </PortfolioBacklogs>
   

4. A continuación, agregue el campo Tipo de requisito a la sección Columns de la sección RequirementsBacklog.

   <RequirementBacklog singularname="User Story" pluralName="User Stories" category="Microsoft.RequirementCategory">
      . . .
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Scheduling.Effort" width="50"/>
        <Column refname="Microsoft.IterationPath" width="200"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
      . . .
   </RequirementBacklog>
   

5. Agregue los colores que se usarán para la epopeya en la sección WorkItemColors. Puede elegir cualquier color que desee, pero a poder ser, no utilice un color ya en uso por el sistema.

   El color que hemos elegido se corresponde al naranja (código de color hexadecimal = FF7B00). Prefije el código de color hexadecimal con FF.

   <WorkItemColor primary="FFFF7B00" secondary="FFFFD7B5" name="Epic" />
   

6. Guarde e importe el archivo.

   witadmin importprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

Actualizar la ruta de acceso del área para elementos de trabajo existentes

Para que los elementos de trabajo existentes se muestren en el trabajo pendiente de un equipo, es necesario actualizar la ruta de acceso del área de cada elemento de trabajo para que sea la ruta del área predeterminada del equipo. Puede utilizar la característica de edición en masa del explorador web o puede usar Excel.

1. Cree una consulta que contenga los elementos de trabajo que desea editar, seleccione esos elementos y luego abra el menú contextual de cualquiera de los elementos seleccionados.

   

2. Seleccione la ruta de acceso del área que corresponde a la ruta de acceso del área predeterminada del equipo.

   

3. Guardar en masa todos los elementos de trabajo que ha modificado.

   

Puede obtener más información sobre cómo modificar en masa los elementos de trabajo aquí.

Agregar epopeyas y asignar epopeyas a características

Ahora que ya agregado el WIT de epopeya, querrá crear alguno. El proceso es exactamente igual que crear cualquier otro elemento de trabajo pendiente. Desde la página Trabajo pendiente del equipo de cartera para epopeyas, agregue un elemento de trabajo pendiente de epopeya.

Agregue todas las epopeyas que necesite. Para mostrar los elementos por orden de importancia, arrástrelos dentro de la lista.

El tipo de requisito predeterminado para epopeyas es el de empresa, pero puede cambiarlo por el de arquitectura.

También puede agregar etiquetas a las epopeyas; le ayudarán a realizar un seguimiento de los temas de inversión admitidos por las epopeyas.

Ahora vea las epopeyas en el panel kanban. Para obtener esta vista, deberá personalizar las columnas kanban para cambiarles el nombre y agregar estados de flujo de trabajo intermedio. Para obtener una descripción de estos estados, consulte este artículo.

Sin embargo, esto todavía no nos interesa demasiado. Como no hay nada en curso, no se puede profundizar para ver qué características son compatibles con sus epopeyas. Deberá asignar las características existentes a las epopeyas que acaba de crear y asignar los casos de usuario a esas características, si aún no lo están.

Asignar varios elementos si tiene un trabajo pendiente

El panel de asignación facilita la tarea de asignar elementos. En la página trabajo pendiente de características o casos, active el panel de asignación. En nuestro ejemplo, se elige el equipo Fiber Suite y se activan el panel de asignación y la vista para ver la jerarquía de características que se asignan a epopeyas.

Tenga en cuenta que si ya ha cambiado la ruta de acceso de área de todas las características al equipo de nivel de programa correspondiente, la lista de características estará vacía, ya que el equipo de cartera no posee ninguna característica. En ese caso, cambie a uno de los equipos de programa.

Arrastre los elementos del trabajo pendiente hasta el elemento que desee asociar como primario. Solo puede asignar características a epopeyas. De forma similar, solo puede asignar el tercer nivel de elemento de trabajo pendiente (ya sea caso de usuario, elemento de trabajo pendiente o requisito) a las características.

Repita este proceso en cada nivel de trabajo pendiente hasta que haya creado la jerarquía que desea.

¿Qué ocurre con las características que ya están en curso? Definitivamente no aparecerán en el trabajo pendiente del equipo de cartera. Son responsabilidad de los equipos de programa, por lo que aparecen en el trabajo pendiente de ese equipo. (Esta es realmente una función de la ruta de acceso del área para el elemento de trabajo; un elemento de trabajo solo aparecerá en el trabajo pendiente de un equipo si se asigna a la ruta de acceso del área creada para ese equipo). Puede asignarlas desde allí.

También puede editar los elementos de trabajo y administrar su jerarquía de forma masiva en Microsoft Excel.

Puesto que uno de los aspectos importantes de SAFe es asignar trabajo a objetivos de empresa o arquitectura, tendrá que asegurarse de establecer el tipo de requisito en arquitectura para cualquier característica que se asigne a una epopeya de arquitectura. (Dado que la opción predeterminada es la empresa, no es necesario cambiar el tipo de cualquier elemento que admita una epopeya de empresa). También puede agregar etiquetas para realizar un seguimiento de la inversión.

Los mismos principios se aplican a casos de usuario en curso. Puede asignarlos a características, cambiar el tipo de requisito a arquitectura en trabajos cuyo fin sea admitir epopeyas de arquitectura y agregar etiquetas para el seguimiento de temas.

Recursos

A continuación, y a modo de referencia, se enumeran los recursos que se mencionan en estas notas del producto, además de otros adicionales.

• Plantillas de proceso habilitadas de SAFe: vínculo para descargar las tres plantillas de proceso que proporciona TFS ─Scrum, Agile y CMMI─, que contienen las personalizaciones documentadas en estas notas del producto.

• Plantillas de proceso de actualización o publicación de TFS 2013 con PowerShell: entrada de blog de Gordon Beeming en la que se proporciona un script de PowerShell que puede usarse para aplicar los cambios documentados en estas notas del producto.

• Scaled Agile Framework: sitio de recursos de SAFe.

• SAFe en 7 minutos: vídeo de Inbar Oren, Lean Samurai.

• Escala de informes TFS de Agile y SAFe: informe de progreso de características descargable que funciona con la plantilla de procesos Scrum en implementaciones de TFS 2012 y 2013.

• Administración de carteras Agile: Usar TFS para admitir trabajos pendientes en varios equipos: notas del producto que muestran cómo configurar TFS para admitir varios equipos y trabajos pendientes.

• Buscar elementos de trabajo utilizando consultas (actualizar): describe cómo configurar TFS para admitir consolidado, es decir, el resumen de los valores de campos seleccionados en todos los elementos de trabajo secundarios que contiene un elemento primario. Dado que TFS admite varios niveles de anidamiento, al realizar el consolidado asegúrese de que no contabiliza dos veces los valores.

• Informes predefinidos (SQL Server Reporting Services): resume los informes proporcionados por TFS para supervisar el progreso y la calidad del código.

• Sincronizar Team Foundation Server con Project Server: describe cómo los administradores de proyectos y los equipos de desarrollo pueden utilizar las herramientas que prefieran y compartir información de forma transparente al permitir que los datos fluyan desde los elementos de trabajo de TFS a las tareas de planes de proyecto de empresa de Project Server.

• Realizar un seguimiento del trabajo asignado a dos o más equipos: muestra cómo un desarrollador o evaluador puede seguir el trabajo cuando da soporte a más de un equipo de características.

Acerca de los autores

Gordon Beeming es desarrollador de software en Derivco y vive en la soleada ciudad de Durban, Sudáfrica. Dedica la mayor parte de su tiempo a gastar teclado trabajando en Visual Studio y a relajarse con su familia. Tiene un blog, 31og.com, y puede seguirlo en Twitter en twitter.com/gordonbeeming.

Brian Blackman es consultor principal con Microsoft Premier Developer, y su objetivo principal es que los partners ISV y las empresas tengan éxito en el ámbito de la ingeniería y el mercado. Tiene un MBA y es CSM, CSP, MCSD (C++) y MCTS, además de ALM Ranger de Visual Studio. Cuando no actúa de “Ruck Master” y colabora con proyectos como ALM Ranger de Visual Studio, dedica su tiempo a escribir código, crear y ofrecer talleres de trabajo y a asesorar en diversas concentraciones, especialmente en ayudar a las organizaciones en la búsqueda de agilidad empresarial.

Gregg Boer es uno de los principales administradores de programas de Microsoft. Gregg es el propietario del producto de la experiencia Agile Management de TFS.

Kathryn Elliott es redactor técnico sénior en Microsoft.

Susan Ferrell es redactor técnico sénior y ALM Ranger de Visual Studio.

Willy-Peter Schaub es administrador de programas con los ALM Rangers de Visual Studio en el Centro de desarrollo de Microsoft de Canadá. Desde mediados de la década de los 80 trabaja para simplificar y facilitar el mantenimiento en la ingeniería de software. Su blog está en blogs.msdn.com/b/willy-peter_schaub y puede seguirlo en Twitter en twitter.com/wpschaub.