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

Visual Studio 2013

Les clients d'entreprise connaissent les avantages que procure une équipe Agile spécifique. Toutefois, l'adaptation de ces pratiques à l'ensemble des équipes et l'implémentation de l'agilité au niveau de l'entreprise présentent plusieurs défis. SAFe™ (Scaled Agile Framework®) fournit une feuille de route pour relever ces défis et adapter l'agilité. En outre, si vous avez un déploiement local de TFS 2013, vous pouvez utiliser SAFe.

Vous pouvez utiliser des projets d'équipe que vous avez créés avec des modèles de processus TFS prêts à l'emploi pour effectuer le suivi des critères SAFe. Ce document indique comment les concepts SAFe s'adaptent à TFS, comment planifier et superviser les projets SAFe dans TFS et comment configurer et personnaliser TFS pour prendre en charge SAFe.

Si vous êtes familiarisé avec Scrum, mais pas avec SAFe, vous pouvez vous orienter avec ces vidéos disponibles sur le site Scaled Agile Framework Foundations et conçues par Inbar Oren (Samurai Lean).

Mapper les concepts SAFe aux concepts TFS

SAFe prend en charge une vue de portefeuille de plusieurs équipes Agile. SAFe illustre comment une hiérarchie d'équipes ayant chacune ses propres objectifs permet d'avoir une vision de portefeuille. Cette infrastructure décompose les épopées (« Epics ») en fonctionnalités (« Features ») et histoires (« Stories »), sur lesquelles les équipes travaillent au travers de sprints et qu'elles remettent par le biais d'incréments de programme et de trains de versions. En outre, le Backlog de portefeuille peut effectuer le suivi du mappage des livrables aux thèmes stratégiques et aux budgets associés.

Image reproduite avec la permission de Leffingwell, LLC.

Les exemples dans ce document montrent comment ajouter le Backlog et le type d'élément de travail d'épopée, configurer une hiérarchie d'équipes de trois niveaux et mapper les équipes à leurs chemins de zone et d'itération respectifs. Les exemples s'appuient sur le modèle de processus Agile de TFS. Toutefois, les modifications peuvent être appliquées à n'importe quel modèle de processus TFS.

Les portefeuilles, programmes et équipes SAFe sont mappés aux équipes et projets d'équipe TFS

Étant donné que TFS prend en charge une structure d'équipes hiérarchique, chaque équipe possède sa propre vue de son travail qui se cumule jusqu'au niveau supérieur dans la hiérarchie d'équipes.

Pour prendre en charge les équipes SAFe, vous reconfigurez l'équipe par défaut en tant qu'équipe de portefeuille pour gérer vos épopées. Vous créez ensuite des sous-équipes pour le travail au niveau du programme et le travail au niveau de l'équipe. Le travail peut faire l'objet d'un suivi entre les équipes et les niveaux.

Les Backlogs SAFe sont mappés aux Backlogs TFS

Par défaut, TFS prend en charge les niveaux de Backlog de fonctionnalité et d'histoire. Vous pouvez facilement ajouter un troisième niveau pour effectuer le suivi des épopées. Les histoires utilisateur peuvent être mappées à des fonctionnalités, qui à leur tour peuvent être mappées à des épopées. Une vue hiérarchique de ces Backlogs montre dans quelle mesure la progression des histoires utilisateur contribue aux épopées.

Les versions, itérations et sprints SAFe sont mappés aux itérations TFS

Les trains de versions, versions, itérations, incréments de programme et sprints SAFe sont facilement mappés aux chemins d'itération TFS. En partageant les itérations dans la hiérarchie d'équipes, vous gérez les versions de manière cohérente.

L'équipe de portefeuille effectue le suivi des épopées, qui peuvent englober plusieurs trains de versions ou incréments de programme. Les équipes de programme effectuent le suivi de leurs livrables de fonctionnalité, fournis avec un incrément de programme. De leur côté, les équipes de fonctionnalité travaillent dans des sprints pour terminer plusieurs histoires. Avec TFS, chaque équipe choisit les itérations qui permettront le suivi de leurs livrables d'équipe.

Les budgets et thèmes stratégiques SAFe sont mappés aux balises et champs TFS

Vous pouvez utiliser des balises pour mapper les épopées à leurs thèmes stratégiques ou budgets associés.

Vous pouvez rechercher et interroger les balises dans TFS, et vous pouvez créer des rapports et des requêtes réutilisables à l'aide de balises.

Pour renforcer le mappage du travail aux budgets et aux thèmes stratégiques, vous pouvez ajouter un champ à vos éléments de travail pour déterminer quel thème ou budget est pris en charge par chaque épopée, fonctionnalité ou histoire.

Mesures SAFe et rapports TFS

Vous pouvez afficher les mesures SAFe en ajoutant ou en personnalisant un rapport. Par exemple, le rapport de progression des fonctionnalités, semblable à un rapport de vue d'ensemble des histoires, montre les fonctionnalités qui sont sur le point de se terminer et celles qui viennent de commencer. Quand les équipes travaillent sur des histoires liées à des fonctionnalités, une barre de progression s'affiche. Elle indique le pourcentage (%) d'achèvement d'une fonctionnalité donnée. Les parties prenantes peuvent exploiter des données pour gérer la portée, les ressources et la priorité.

Pour obtenir une version téléchargeable du rapport de progression des fonctionnalités, consultez Adaptation des rapports TFS SAFe et Agile.

Planifier/superviser les projets SAFe dans TFS

Une fois que vous avez configuré TFS pour prendre en charge SAFe, créez des relations de suivi depuis les histoires jusqu'aux épopées. En outre, vous pouvez afficher la progression à partir des niveaux d'équipe de portefeuille, de programme et de fonctionnalité.

Mapper les fonctionnalités aux épopées et les histoires aux fonctionnalités

L'équipe du programme peut mapper les fonctionnalités aux épopées en utilisant le volet de mappage. Selon le même procédé, les équipes de fonctionnalité peuvent mapper leurs histoires à des fonctionnalités.

Vue de la progression de l'équipe de portefeuille

Pour effectuer le suivi de la progression des épopées qui couvrent les versions, le Backlog de l'équipe de portefeuille montre les épopées. Chaque épopée peut être développée pour afficher les fonctionnalités et les histoires utilisateur qui la prennent en charge.

L'équipe de portefeuille peut également afficher la progression des épopées sur leur tableau Kanban.

Vue de la progression de l'équipe de programme

Les équipes de programme, essentiellement concernées par les trains de version, peuvent voir les fonctionnalités dans leur Backlog, ainsi que les incréments de programme auxquels elles sont associées.

Comme l'équipe de portefeuille, les équipes de programme peuvent basculer leur vue pour déterminer les épopées prises en charge par leurs fonctionnalités, les histoires utilisateur qui prennent en charge leurs fonctionnalités, ou les deux.

Une autre vue disponible pour les équipes de programme affiche des graphiques basés sur des requêtes illustrant la progression des trains de versions, les éléments du Backlog ou les tâches actives pendant un sprint de livraison. Une vue de page d'accueil personnalisable est disponible pour chaque équipe.

Étant donné qu'une partie importante du travail d'une équipe de programme tourne autour des incréments de programme et des trains de versions, un rapport personnalisé qui affiche les dates de livraison prévues et les éléments projetés d'un train donné peut être utile. En outre, si votre déploiement TFS inclut l'intégration à Project Server ou à SQL Server Reporting Services, vous pouvez tirer parti de la richesse des options de création de rapports et des rapports intégrés offerts par chacun de ces services.

Vue de la progression de l'équipe de fonctionnalité

La vue du Backlog d'une équipe de fonctionnalité affiche les histoires sur lesquelles celle-ci travaille.

Étant donné que les équipes de fonctionnalité ne possèdent pas d'épopées ou de fonctionnalités, les épopées et fonctionnalités n'apparaissent pas dans leurs vues de Backlog au niveau de l'équipe. Toutefois, si l'équipe souhaite connaître les épopées et les fonctionnalités prises en charge par leurs histoires, elles peuvent activer ces vues à partir de leur Backlog.

Elles peuvent également décomposer leur travail en tâches et utiliser le tableau de tâches pour rester opérationnelles pendant les sprints.

L'affichage graphique des requêtes est très utile dans le sprint d'innovation et de planification, quand les équipes de fonctionnalité collaborent pour stabiliser les fonctionnalités planifiées pour une version.

Pour tout le reste, il s'agit de la routine habituelle pour les équipes de fonctionnalité individuelles. Elles peuvent effectuer les sprints à leurs cadences habituelles. Elles peuvent utiliser leur tableau Kanban et un tableau de tâches pour effectuer le suivi de la progression et décomposer le travail en segments gérables.

Toutefois, leur progression sur les histoires individuelles est désormais visible par leurs équipes de gestion de portefeuille et de programme. La vue de gestion reflète ce qu'elles font.

Configurer TFS pour prendre en charge SAFe

Dans cette section, nous allons partir d'un projet, nommé « Fabrikam » et d'une équipe, qui porte le nom du projet, pour obtenir la structure suivante de trois niveaux et neuf équipes. La hiérarchie des chemins de zone et la configuration du chemin de zone de chaque équipe prennent en charge la vue de Backlog de chaque équipe et le cumul des vues au sein de la hiérarchie.

Chaque projet dans TFS possède une équipe par défaut. Vous pouvez configurer des équipes supplémentaires pour le travail au niveau du programme et le travail au niveau de l'équipe de fonctionnalité. En outre, vous pouvez redéfinir l'équipe par défaut en tant qu'équipe de portefeuille qui gère les épopées.

De cette manière, toutes les équipes peuvent gérer leur propres charge de travail et priorités tout en comprenant bien comment leur travail prend en charge ces épopées gérées dans le Backlog de l'équipe de portefeuille. En même temps, l'équipe de portefeuille peut surveiller la progression de son Backlog dans son propre tableau Kanban, hiérarchiser les éléments de leur Backlog et consulter la progression dans les trains de versions.

Tout ceci peut sembler compliqué, mais la mise en place des équipes et la prise en main demandent en réalité très peu de configuration.

Nous commençons avec un projet comportant une équipe par défaut, une zone et un ensemble d'itérations. Tout d'abord, nous allons configurer une structure de chemins de zone pour prendre en charge la hiérarchie d'équipes que nous voulons. Ensuite, nous allons nous assurer que les chemins d'itération prennent en charge la structure de version que nous voulons, ainsi que les équipes de fonctionnalité et de programme à utiliser. Enfin, nous allons créer, configurer et définir les membres des équipes.

Vous devez être membre du groupe Project Administrators pour configurer et personnaliser TFS.

Créer des zones pour prendre en charge votre hiérarchie d'équipes

1. Connectez-vous au projet d'équipe que vous souhaitez configurer pour prendre en charge SAFe et utilisez l'icône d'engrenage pour ouvrir la page d'administration de l'équipe par défaut.

2. Dans la page Zones, créez un enfant sous le chemin de zone de niveau supérieur et attribuez-lui le nom de l'une des équipes de programme que vous allez créer.

   

3. Ensuite, créez une deuxième zone au même niveau enfant et attribuez-lui le nom de la deuxième équipe de programme.

4. Sous chaque zone de programme, créer une zone enfant pour chaque équipe de fonctionnalité qui prendra en charge l'équipe de programme correspondante. Vous devez vous retrouver avec une hiérarchie de chemins de zone à 3 niveaux.

   

Créer des itérations pour prendre en charge vos trains de version et vos sprints

Pour effectuer le suivi vers les versions, créez la structure de chemins d'itération. Contrairement aux chemins de zone, plusieurs équipes peuvent partager la même structure de chemins d'itération. Partager la structure d'itérations permet à plusieurs équipes de travailler à la même cadence de sprints vers les mêmes trains de versions.

Si vous avez déjà des itérations pour votre équipe par défaut, vous pouvez les renommer. Vous voudrez créer une structure d'itérations qui prend en charge l'ensemble de votre structure d'équipes, pas simplement une seule équipe.

1. Sous l'itération par défaut, qui partage le même nom que le projet, créez une itération enfant destinée à représenter votre premier incrément de programme. Éventuellement, ajoutez une date de début et une date de fin pour l'incrément de programme, mais n'oubliez pas que l'itération sera ventilée dans les sprints.

   

2. Ensuite, créez une itération enfant pour chaque sprint dans l'incrément de programme. Définissez pour ces sprints des dates qui correspondent aux cadences de vos équipes de fonctionnalité.

   

Créer et configurer vos équipes

Dans cette section, nous allons configurer une structure d'équipes hiérarchique correspondant aux chemins de zone hiérarchiques que vous avez précédemment créés.

Cette structure mappe les équipes SAFe suivantes aux équipes TFS :

• Équipe de portefeuille -> équipe de niveau supérieur par défaut, l'équipe Fabrikam

• Équipes de programme -> équipes de niveau secondaire, Fiber Suite et Service Suite

• Équipes de fonctionnalité -> équipes de troisième niveau définies sous Fiber Suite et Service Suite.

Si vous avez besoin d'aide plus détaillée, consultez Gestion du portefeuille Agile : utilisation de TFS pour prendre en charge les Backlogs avec plusieurs équipes.

Vous devez être administrateur de projet dans TFS pour effectuer ces étapes.

Créer et configurer chaque équipe de programme

1. Dans la page Vue d'ensemble du projet d'équipe, créez une équipe. Veillez à décocher la case Créez un chemin de zone avec le nom de l'équipe.

   

2. Choisissez l'équipe dans la liste, accédez à la page Zones et cocher la case en regard du chemin de zone que vous avez déjà créé pour cette équipe.

   

3. Utilisez le menu contextuel pour exclure les sous-zones. En excluant les sous-zones, le Backlog de l'équipe inclut uniquement les éléments dont le chemin de zone correspond au chemin de zone par défaut de l'équipe.

   

4. Ensuite, configurez les itérations qui seront actives pour l'équipe du programme. Dans cet exemple, nous avons configuré trois incréments de programme, chacun comportant cinq sprints de deux semaines. Quatre des sprints sont des sprints ordinaires, tandis que le dernier sprint est un sprint d'innovation et de planification.

   

     

   Étant donné que l'équipe de programme Fiber Suite est concernée par les trains de versions, nous choisissons les incréments de programme 1, 2 et 3, mais nous ne choisissons pas les sprints individuels.

5. Une fois que vous avez sélectionné les itérations qui doivent être actives pour l'équipe, ajoutez des utilisateurs à la nouvelle équipe. Dans l'idéal, vous devez ajouter les ScrumMasters pour chaque équipe de fonctionnalité, les directeurs de produits, ainsi que les ingénieurs de train de versions aux équipes de programme, telles que Fiber Suite.

   

6. Si vous avez plusieurs équipes au niveau du programme, répétez les étapes 1 à 5 pour chaque équipe de programme.

Créer et configurer chaque équipe de fonctionnalité

Ensuite, nous allons créer quelques équipes de fonctionnalité pour que le travail soit effectué au troisième niveau de la hiérarchie d'équipes. Chaque équipe de fonctionnalité contribuera à un travail de sprint qui se cumule dans l'incrément de programme. Le nombre d'équipes que vous créez dépend de la taille de votre organisation.

1. Créez une équipe à partir de la page d'administration de l'équipe d'origine et attribuez un nom à l'équipe. Comme précédemment, veillez à décocher la case Créez un chemin de zone avec le nom de l'équipe.

   

2. Choisissez l'équipe dans la liste, accédez à la page Zones et cocher la case en regard du chemin de zone que vous avez déjà créé pour cette équipe.

   

3. Configurez les itérations de l'équipe, à l'aide des incréments de programme et des sprints que vous avez créés précédemment. Contrairement aux équipes de programme, cette fois, sélectionnez les sprints individuels en tant qu'itérations de travail pour l'équipe de fonctionnalité.

   

4. Ajoutez les comptes des développeurs, des testeurs et du ScrumMaster de l'équipe. TFS prend en charge l'affectation d'un ScrumMaster à plusieurs équipes. Le ScrumMaster peut effectuer le suivi du travail entre plusieurs équipes.

   

5. Répétez les étapes 1 à 4 pour chaque équipe de fonctionnalité dans votre organisation. Assurez-vous que le chemin de zone par défaut que vous configurez pour l'équipe est un chemin de sous-zone situé sous le chemin de zone correspondant au niveau du programme. Cela garantit le cumul depuis les équipes de fonctionnalité jusqu'aux équipes de programme.

Configurer l'équipe de portefeuille

Votre structure de sous-équipes étant configurée, paramétrez l'équipe par défaut en tant qu'équipe de portefeuille. Même si cette équipe continue de porter le nom du projet, les modifications apportées à cette équipe de niveau supérieur lui permettront d'effectuer un suivi efficace des épopées entre les incréments de programme au niveau le plus élevé.

1. Dans la page Zones du projet d'équipe, modifiez les paramètres afin que les sous-zones ne soient pas incluses. Veillez à choisir le projet d'équipe et non l'équipe par défaut (Fabrikam).

   

2. Dans la page Iterations, décochez les cases de toutes les itérations, sauf pour le niveau racine, qui ne peut pas être désactivé. Étant donné que l'équipe de portefeuille n'est concernée que par les épopées qui couvrent les incréments de programme, elle utilise l'itération racine seule, sans recourir aux incréments de programme ou aux sprints. Les équipes de portefeuille ne travaillent pas dans les sprints.

   

3. Ajoutez et supprimez des utilisateurs dans l'équipe de portefeuille appropriée pour ce niveau. Dans la page Vue d'ensemble, choisissez l'équipe par défaut.

   

      

   Envisagez d'ajouter d'autres acteurs, tels que les responsables de portefeuille, les architectes de niveau entreprise et les ingénieurs de train de versions à ce niveau et supprimez toute autre personne.

   

Personnaliser le processus TFS pour prendre en charge SAFe

Dans cette section, nous allons ajouter le type d'élément de travail d'épopée à la hiérarchie du Backlog du portefeuille. Nous allons également ajouter le champ Requirement Type aux trois types d'éléments de travail de Backlog. Enfin, nous allons créer des épopées et mapper les fonctionnalités aux épopées.

Si vous êtes davantage intéressé par le déroulement des opérations après l'ajout du niveau de Backlog des épopées, rendez-vous ici maintenant. En outre, si vous préférez ne pas effectuer vous-même les étapes de personnalisation décrites dans cette section, les ALM Rangers mettent à votre disposition un billet de blog et un exemple de script PowerShell qui montre comment installer ces personnalisations sur votre projet.

Ajouter Epic au Backlog de portefeuille

Comme précédemment, vous devez être membre du groupe Project Administrators pour effectuer ces étapes.

Tout d'abord, nous allons exporter un type d'élément de travail existant et l'utiliser pour créer un type d'élément de travail, que nous nommerons Epic. Nous allons également ajouter un champ Requirement Type pour savoir de quel type d'épopée il s'agit : Architecture ou Business. Ensuite, nous allons ajouter une catégorie pour les épopées. Nous allons ensuite modifier des types d'éléments de travail (WIT) existants ─ Fonctionnalités et Histoires utilisateur, même s'ils ne sont pas nommés ainsi ─ pour inclure le champ Requirement Type. Le champ Requirement Type effectue le suivi du type d'objectif que chaque élément de travail prend en charge. En dernier lieu, nous allons ajouter Epic au Backlog de l'équipe de portefeuille.

Ajouter le type d'élément de travail Epic

Le moyen le plus simple de créer un type d'élément de travail consiste à copier un type existant, à le renommer, puis à le modifier.

Nous allons exporter le type d'élément de travail Feature et l'utiliser comme base pour le type d'élément de travail Epic.

1. En mode administrateur, ouvrez une fenêtre d'invite de commandes. Accédez au répertoire où vous avez installé Visual Studio (ou Team Explorer).

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

   Sur les éditions 64 bits de Windows, utilisez %programfiles(x86)%.

2. Utilisez l'outil witadmin pour télécharger la définition du type d'élément de travail Feature et enregistrez-la sous le nom Epic.xml.

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

3. Ouvrez le fichier Epic.xml, remplacez <WORKITEMTYPE name="Feature"> par <WORKITEMTYPE name="Epic"> et mettez à jour la description.

   <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. Modifiez la section <Tab Label="Implementation"> ou, dans le cas de CMMI, <Tab Label="Requirements">, en remplaçant les lignes suivantes par <Filter WorkItemType="Feature" />.

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

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

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

     Cette modification empêche le contrôle de liens de prendre en charge les fonctionnalités en tant qu'éléments de travail enfants d'épopées.

   <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. Ajoutez le champ Requirement Type à la définition du type d'élément de travail Epic. Pour ce faire, nous allons emprunter un champ existant (créé à l'origine pour prendre en charge les projets CMMI, mais tout aussi utile dans notre cas) Microsoft.VSTS.CMMI.RequirementType et l'ajouter à la section FIELDS Epic.

   Recherchez la section FIELDS et ajoutez le code suivant :

   <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. Ensuite, ajoutez le champ au formulaire. Dans la section FORM, ajoutez le champ partout où vous pensez qu'il est approprié pour votre entreprise. Dans l'exemple ci-dessous, nous avons ajouté le champ situé sous le champ Iteration.

   <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. Enregistrez, puis importez le fichier.

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

Ajouter la catégorie Epic

Le type d'élément de travail Epic étant créé, nous allons ajouter une catégorie pour les épopées. TFS gère les Backlogs en fonction des catégories.

1. Exportez la définition Catégories dans un fichier xml.

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

2. Ouvrez le fichier et ajoutez la catégorie Epic. Vous pouvez choisir de remplacer Microsoft par le nom de votre société, pour indiquer qu'il s'agit de votre personnalisation.

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

3. Comme auparavant, importez le fichier.

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

Ajouter le champ Requirement Type pour effectuer le suivi du travail lié à Architecture/Business

Ensuite, nous allons ajouter le champ Requirement Type à Features et au troisième niveau de l'élément de Backlog, qu'il s'agisse de User Story, de Product Backlog Item ou éventuellement de Bug. Vous n'avez pas besoin de l'ajouter à Requirement, car il est déjà inclus dans la définition de CMMI par défaut.

1. Exportez la définition du type d'élément de travail Feature.

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

2. Ajoutez le champ Requirement Type, tout comme vous l'avez fait précédemment avec le type d'élément de travail Epic. Recherchez la section FIELDS et ajoutez le code suivant :

   <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. Ajoutez le champ au formulaire, à la même position à laquelle vous l'avez ajouté à Epic. Par exemple :

   <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. Enregistrez, puis importez le fichier.

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

5. Répétez les étapes 1 à 4 pour les définitions des types d'élément de travail User Story et Product Backlog Item. Éventuellement, modifiez la définition du type d'élément de travail Bug si vous souhaitez déterminer les bogues de spécification à prendre en charge ou si vous effectuez le suivi des bogues dans votre Backlog.

Ajouter la catégorie Epic à la hiérarchie du Backlog du portefeuille

Nous allons ensuite ajouter des épopées à la hiérarchie d'éléments de travail qui composent le Backlog.

1. Exportez le fichier de définition XML de configuration de processus.

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

2. Ouvrez le fichier et ajoutez une section PortfolioBacklog pour les épopées dans la section PortfolioBacklogs. En même temps, vous devez modifier l'élément PortfolioBacklog de FeatureCategory pour qu'Epics soit un parent de Features.

   Le cas échéant, modifiez les mappages des metastates en fonction de votre modèle de processus. L'exemple suivant prend en charge les projets Agile et CMMI. En outre, ajoutez le champ Requirement Type à la section 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>        
   

   Les projets Scrum nécessitent que vous mappiez les états de flux de travail New, In Progress et Done. Ce sont les mêmes états que ceux mappés pour l'élément de Backlog de portefeuille Feature.

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

   En outre, les projets CMMI nécessitent que vous mappiez les états de flux de travail Proposed, Active, Resolved et Closed.

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

3. Ensuite, ajoutez parent="Microsoft.EpicCategory" à la section PortfolioBacklog category="Microsoft.FeatureCategory". De même, ajoutez le champ Requirement Type à la section 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. Ensuite, ajoutez le champ Requirement Type à la section Columns de la section 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. Ajoutez les couleurs à utiliser pour Epic à la section WorkItemColors. Vous pouvez choisir les couleurs que vous souhaitez, mais dans l'idéal, n'utilisez pas une couleur qu'emploie déjà le système.

   La couleur que nous avons choisie correspond à orange (code de couleur hexadécimal FF7B00). Faites précéder le code de couleur hexadécimal de FF.

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

6. Enregistrez et importez le fichier.

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

Mettre à jour le chemin de zone des éléments de travail existants

Pour que les éléments de travail existants apparaissent dans le Backlog d'une équipe, vous devez définir le chemin de zone de chaque élément de travail sur le chemin de zone par défaut de l'équipe. Vous pouvez utiliser la fonctionnalité de modification en bloc à partir de votre navigateur web ou recourir à Excel.

1. Créez une requête qui contient les éléments de travail que vous souhaitez modifier, sélectionnez ceux que vous souhaitez modifier, puis ouvrez le menu contextuel associé à l'un des éléments sélectionnés.

   

2. Sélectionnez le chemin de zone qui correspond au chemin de zone par défaut de l'équipe.

   

3. Enregistrez en bloc tous les éléments de travail que vous avez modifiés.

   

Pour plus d'informations sur la modification en bloc des éléments de travail, cliquez ici.

Ajouter des épopées et les mapper à des fonctionnalités

Une fois que vous avez ajouté le type d'élément de travail Epic, vous pouvez créer des éléments. Le processus est identique à la création de tout autre élément de travail de Backlog. Dans la page Backlog de l'équipe de portefeuille pour les épopées, ajoutez un élément de Backlog de type épopée.

Ajoutez autant d'épopées que nécessaire. Pour répertorier les éléments dans leur ordre d'importance, faites-les glisser dans la liste.

Le type de spécification par défaut des épopées est Entreprise, mais, pour une épopée donnée, vous pouvez remplacer cette valeur par Architecture.

Vous pouvez également ajouter des balises à vos épopées, afin d'effectuer le suivi des thèmes d'investissement pris en charge par chaque épopée.

À présent, affichez vos épopées dans le tableau Kanban. Pour obtenir cette vue, vous devez personnaliser les colonnes Kanban afin de renommer et d'ajouter des états de flux de travail intermédiaires. Pour obtenir une description de ces états, consultez Résumé du système Kanban d'épopée pour les entreprises.

Toutefois, cela n'est pas très intéressant à ce stade. Rien n'est en cours, et vous ne pouvez pas déterminer les fonctionnalités qui prennent en charge vos épopées. Vous devez mapper des fonctionnalités existantes aux épopées que vous venez de créer et mapper les histoires utilisateur à ces fonctionnalités, si elles ne sont pas déjà mappées.

Mapper plusieurs éléments si un Backlog existe

Mapper des éléments de travail est facile à l'aide du volet de mappage. Dans la page du Backlog des fonctionnalités ou des histoires, activez le volet de mappage. Dans notre exemple, nous choisissons l'équipe Fiber Suite et activons le volet de mappage et la vue pour afficher la hiérarchie des fonctionnalités mappées aux épopées.

Notez que si vous avez déjà défini le chemin de zone de toutes vos fonctionnalités sur l'équipe de niveau programme appropriée, la liste des fonctionnalités est vide, car l'équipe de portefeuille ne possède aucune fonctionnalité. Dans ce cas, passez à l'une des équipes de programme.

Faites glisser des éléments depuis le Backlog vers l'élément que vous souhaitez associer en tant que parent. Vous ne pouvez mapper que des fonctionnalités aux épopées. De même, vous ne pouvez mapper que le troisième niveau de l'élément de Backlog (que ce soit une histoire utilisateur, un élément de Backlog ou une spécification) aux fonctionnalités.

Répétez ce processus à chaque niveau du Backlog jusqu'à ce que vous ayez créé la hiérarchie souhaitée.

Qu'en est-il des fonctionnalités en cours ? Elles n'apparaissent pas dans le Backlog de l'équipe de portefeuille. Étant sous la responsabilité des équipes de programme, elles apparaissent dans le Backlog de cette équipe. (Il s'agit en fait d'une fonction du chemin de zone défini pour l'élément de travail ; un élément de travail n'apparaît dans le Backlog d'une équipe que si vous l'assignez au chemin de zone que vous avez créé pour cette équipe.) Vous pouvez les mapper à partir de là.

Vous pouvez également modifier des éléments de travail en bloc et gérer leur hiérarchie dans Microsoft Excel.

L'un des aspects importants de SAFe étant le mappage du travail à des objectifs d'entreprise ou d'architecture, veillez à définir le type de spécification sur Architecture pour toute fonctionnalité mappée à une épopée d'architecture. (Le choix par défaut étant Entreprise, vous n'avez pas besoin de modifier le type d'un élément qui prend en charge une épopée d'entreprise.) Vous pouvez également ajouter des balises pour effectuer le suivi de l'investissement.

Les mêmes principes s'appliquent aux histoires utilisateur en cours. Vous pouvez les mapper à des fonctionnalités, définir le type de spécification sur Architecture pour le travail nécessaire à la prise en charge des épopées architecturales et ajouter des balises pour le suivi des thèmes.

Ressources

Les ressources mentionnées dans ce livre blanc, ainsi que d'autres, sont fournies ici pour référence.

• Modèles de processus compatible avec SAFe : lien vers un téléchargement des trois modèles de processus fournis par TFS ─ Scrum, Agile et CMMI ─ et qui comportent les personnalisations documentées dans ce livre blanc.

• Upgrade/Publish TFS 2013 Process Templates with PowerShell : billet de blog de Gordon Beeming qui fournit un script PowerShell permettant d'appliquer les modifications décrites dans ce livre blanc.

• Scaled Agile Framework : site de ressources sur SAFe.

• SAFe en 7 minutes : vidéo d'Inbar Oren (Lean Samurai).

• Adaptation des rapports TFS Agile et SAFe : rapport de progression de fonctionnalité téléchargeable qui fonctionne avec le modèle de processus Scrum pour les déploiements TFS 2012 et 2013 locaux.

• Gestion du portefeuille Agile : utilisation de TFS pour prendre en charge les Backlogs avec plusieurs équipes : livre blanc qui explique comment configurer TFS pour prendre en charge plusieurs équipes et plusieurs Backlogs.

• Rechercher des éléments de travail à l'aide de requêtes (à mettre à jour). : explique comment configurer TFS pour prendre en charge le cumul, qui représente la somme des valeurs de champs sélectionnés pour tous les éléments de travail enfants d'un parent. TFS prenant en charge plusieurs niveaux d'imbrication, quand vous effectuez le cumul, assurez-vous qu'aucune valeur n'est comptée deux fois.

• Rapports prêts à l'emploi (SQL Server Reporting Services) : répertorie les rapports que TFS fournit pour surveiller la progression et la qualité du code.

• Synchroniser Team Foundation Server avec Project Server : explique comment les responsables de projet et les équipes de développement peuvent utiliser les outils de leur choix et partager des informations de façon transparente en permettant aux données de circuler entre les éléments de travail dans TFS et les tâches dans les plans de projet d'entreprise dans Project Server.

• Faire le suivi de votre travail lorsqu'il est assigné à deux ou plusieurs équipes : montre comment un développeur ou un testeur peut effectuer le suivi d'un travail quand il prend en charge plusieurs équipes de fonctionnalité.

À propos des auteurs

Gordon Beeming est développeur de logiciels chez Derivco dans la ville ensoleillée de Durban, Afrique du Sud. Il passe la majeure partie de son temps à explorer les possibilités de Visual Studio ou à se reposer en famille. Son blog est disponible à l'adresse 31og.com et vous pouvez le suivre sur Twitter à l'adresse twitter.com/gordonbeeming.

Brian Blackman est consultant principal chez Microsoft Premier Developer et son travail porte essentiellement sur la réussite des entreprises et des partenaires ISV dans l'ingénierie et sur la place de marché. Il possède un MBA, les certifications CSM, CSP, MCSD (C++) et MCTS et est Visual Studio ALM Ranger. Quand il ne fait pas office de Ruck Master ou qu'il ne contribue pas aux projets Visual Studio ALM Ranger, il passe son temps à écrire du code, à créer et à proposer des ateliers, ainsi qu'à offrir ses services de conseil, notamment auprès des organisations en quête d'agilité.

Gregg Boer est responsable de programme principal chez Microsoft. Gregg est responsable produit en charge de la gestion Agile dans TFS.

Kathryn Elliott est rédactrice technique senior chez Microsoft.

Susan Ferrell est rédactrice technique senior et Visual Studio ALM Ranger.

Willy-Peter Schaub est responsable de programme avec les Visual Studio ALM Rangers au sein du Centre de développement de Microsoft au Canada. Depuis le milieu des années 80, la simplicité et la facilité de gestion en ingénierie logicielle constituent ses principaux axes de travail. Son blog se trouve à l'adresse blogs.msdn.com/b/willy-peter_schaub et vous pouvez le suivre sur Twitter à l'adresse twitter.com/wpschaub.