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

Visual Studio 2013

I clienti aziendali hanno già sperimentato i vantaggi associati ai singoli team Agile. Tuttavia, la scalabilità di queste procedure nei team e l'implementazione dell'agilità a livello aziendale presentano diverse sfide. Scaled Agile Framework® (SAFe™) fornisce una guida di orientamento su come vincere queste sfide e ottenere la scalabilità dell'agilità. Inoltre, se si ha una distribuzione locale di TFS 2013, è possibile usare SAFe.

È possibile usare i progetti team creati con i modelli di processo TFS automatici per tenere traccia dei criteri SAFe. In questo documento viene descritto in che modo i concetti SAFe vengono mappati a TFS, come pianificare e tenere traccia dei progetti SAFe in TFS e come configurare e personalizzare TFS per supportare SAFe.

Se si ha dimestichezza con Scrum ma non con SAFe, questi video in Scaled Agile Framework Foundations di Inbar Oren, il Lean Samurai, rappresentano un ottimo strumento per orientarsi.

Mapping dei concetti SAFe ai concetti TFS

SAFe supporta una visualizzazione portfolio di più team Agile. SAFe illustra in che modo una visualizzazione portfolio corrisponde a una gerarchia di team, ognuno dei quali ha i propri obiettivi specifici. Questo framework suddivide gli epic in feature e story. I team lavorano su questi elementi in sprint e li distribuiscono mediante program increment (PI) e release train. Inoltre, il backlog di portfolio può tenere traccia di come vengono mappati i risultati finali agli strategic theme e ai budget associati.

Immagine su concessione di Leffingwell, LLC.

Gli esempi in questo documento illustrano come aggiungere un tipo di elemento di lavoro e un backlog dell'epic, configurare una gerarchia di team a tre livelli e mappare i team ai rispettivi percorsi area e iterazione. Gli esempi sono costruiti in base al modello di processo Agile di TFS, ma le modifiche possono essere applicate a qualsiasi modello di processo TFS.

Mapping di portfolio, program e team SAFe ai progetti team e ai team TFS

Poiché TFS supporta una struttura gerarchica dei team, ogni team ha una specifica visione del lavoro che si amplia nel livello successivo della gerarchia di team.

Per supportare i team SAFe, riconfigurare il team predefinito come team portfolio per la gestione degli epic. Quindi, creare dei sottoteam per il lavoro a livello di programma e per il lavoro a livello di team. È possibile tenere traccia del lavoro tra i team e nei vari livelli.

Mapping di backlog SAFe ai backlog TFS

TFS supporta automaticamente i livelli di backlog story e feature. È possibile aggiungere facilmente un terzo livello per tenere traccia degli epic. Le user story possono essere mappate a feature che a sua volta può essere mappato a epic. Una visualizzazione gerarchica dei backlog mostra in che modo lo stato delle user story contribuisce agli epic.

Mapping di release, iteration e sprint SAFe alle interazioni TFS

Release train, release, iteration, program increment (PI) e sprint SAFe vengono mappati facilmente ai percorsi di iterazione TFS. Condividendo le iterazioni nella gerarchia di team, è possibile gestire i rilasci in modo coerente.

Il team portfolio tiene traccia degli epic che possono estendersi su più release train o PI. I team program tengono traccia dei risultati finali della feature forniti con PI. I team feature lavorano in sprint per completare più story. Con TFS ogni team sceglie le iterazioni che l'aiuterà a tenere traccia dei risultati finali del team.

Mapping di strategic theme e budget SAFe nei tag e nei campi TFS

È possibile usare i tag per mappare gli epic agli strategic theme o ai budget associati.

È possibile eseguire ricerche e query sui tag in TFS e creare query riutilizzabili e report con i tag.

Per un mapping più affidabile del lavoro agli strategic theme e ai budget, è possibile aggiungere un campo agli elementi di lavoro per tenere traccia del theme o del budget supportato da ciascun epic, feature o story.

Metriche SAFe e report TFS

È possibile visualizzare metriche SAFe aggiungendo o personalizzando un report. Ad esempio, il report sullo stato delle funzionalità, analogamente al report sulla panoramica delle story, mostra quali funzionalità stanno per essere completate e quali sono appena state avviate. Quando i team lavorano su story collegate alle feature, viene visualizzato un indicatore di stato che mostra la percentuale (%) di completamento di una specifica funzionalità. Le parti interessate dispongono di dati eseguibili per gestire l'ambito, le risorse e la priorità.

Per una versione scaricabile del report sullo stato delle funzionalità, vedere Scaling Agile and SAFe TFS Reports.

Pianificare e tenere traccia dei progetti SAFe in TFS

Dopo aver configurato TFS per supportare SAFe, creare relazioni di traccia dalle story agli epic. Inoltre, è possibile visualizzare lo stato dai livelli di team portfolio, program e feature.

Mapping delle feature agli epic e delle story alle feature

Il team program può mappare le feature agli epic usando il riquadro di mapping. I team feature possono usare la stessa funzionalità per mappare le story alle feature.

Visualizzazione dello stato per il team portfolio

Per tenere traccia dello stato degli epic che si estendono sulle release, il backlog del team portfolio visualizza gli epic. Ogni epic può essere espanso per visualizzare le feature e le user story che lo supportano.

Il team portfolio può anche visualizzare lo stato degli epic nella bacheca Kanban.

Visualizzazione dello stato per il team program

I team program, che si occupano principalmente di release train, possono visualizzare le feature nel proprio backlog insieme ai PI ai quali sono associate.

Come il team portfolio, anche i team program possono attivare e disattivare la visualizzazione per vedere gli epic e/o le user story supportati dalle proprie feature.

Un'altra visualizzazione disponibile per i team program mostra i grafici basati su query dello stato del release train, gli elementi del backlog o le attività in corso durante uno sprint di spedizione. Per ogni team è disponibile una visualizzazione della home page personalizzabile.

Poiché gran parte del lavoro di un team program interessa PI e release train, può essere utile creare un report personalizzato che mostri le date di spedizione pianificate e i contenuti previsti per ciascun train. Inoltre, se la distribuzione TFS include l'integrazione con SQL Server Reporting Services o Project Server, è possibile sfruttare le numerose opzioni di creazione di report e i report predefiniti offerti da questi servizi.

Visualizzazione dello stato per il team feature

Per i singoli team feature, la visualizzazione del backlog mostra le story su cui stanno lavorando.

Poiché i team feature non hanno la proprietà di epic o feature, questi non sono presenti nelle visualizzazioni del backlog a livello di team. Tuttavia, per sapere quali epic e feature sono supportati dalle story, il team può attivare le relative visualizzazioni dal backlog.

Può anche suddividere il lavoro in attività e usare la lavagna delle attività per rispettare la pianificazione durante specifici sprint.

La visualizzazione sotto forma di grafico delle query risulta molto utile nello sprint Innovation and Planning (IP) quando i team feature collaborano per stabilizzare le funzionalità pianificate per una release.

Per tutto il resto, i singoli team feature procedono come al solito, eseguendo gli sprint secondo le cadenze previste. Possono usare la bacheca Kanban e la lavagna delle attività per tenere traccia dello stato e suddividere il lavoro in blocchi gestibili.

Tuttavia, lo stato delle singole story ora è visibile ai team di gestione program e portfolio e la visualizzazione di gestione riflette le operazioni effettuate dal team feature.

Configurare TFS per il supporto di SAFe

In questa sezione, da un progetto denominato "Fabrikam” e un team con lo stesso nome del progetto si arriverà alla seguente struttura di tre livelli e nove team. La gerarchia di percorsi area e la configurazione del percorso area di ogni team supportano la visualizzazione del backlog dei singoli team e il rollup delle visualizzazioni all'interno della gerarchia.

Ogni progetto in TFS ha un team predefinito. È possibile configurare altri team il lavoro a livello di team program e feature. Inoltre, è possibile ridefinire i team predefiniti, ad esempio il team portfolio che gestisce gli epic.

In questo modo, tutti i team possono gestire il proprio carico di lavoro e le priorità avendo una chiara visione del modo con cui il loro lavoro supporta gli epic gestiti nel backlog del team portfolio. Allo stesso tempo, il team portfolio può monitorare lo stato del backlog dalla bacheca Kanban dei team, assegnare le priorità agli elementi del backlog e visualizzarne lo stato nei release train.

Tutto questo potrebbe sembrare complicato, ma in realtà è richiesta una configurazione minima per impostare i team e iniziare a lavorare.

In questo scenario si prende in considerazione un progetto con un team predefinito, un'area e un set di iterazioni. Prima di tutto, viene configurata una struttura di percorsi area per supportare la gerarchia di team desiderata. Quindi, si verifica che i percorsi di iterazione supportino la struttura di release e i team program e feature da usare. Infine, viene creata, configurata e popolata l'appartenenza dei team.

Per configurare e personalizzare TFS è necessario essere membri del gruppo Project Administrators.

Creare le aree per supportare la gerarchia di team

1. Connettersi al progetto team da configurare per supportare SAFe e usare l'icona dell'ingranaggio per aprire la pagina di amministrazione del team predefinito.

2. Nella pagina Aree creare un elemento figlio nel percorso area di primo livello e denominarlo in modo che corrisponda a uno dei team program da creare.

   

3. Quindi creare una seconda area nello stesso livello figlio e denominarla come il secondo team program.

4. In ciascuna area program creare un'area figlio per ciascun team feature che supporterà il corrispondente team program. Il risultato finale dovrebbe comprendere una gerarchia di percorsi area a tre livelli.

   

Creare le iterazioni per supportare i release train e gli sprint

Per tenere traccia dello stato delle release, creare la struttura del percorso di iterazione. A differenza dei percorsi area, più team possono condividere la stessa struttura del percorso di iterazione. La condivisione della struttura di iterazione consente a più team di lavorare nella stessa cadenza sprint dello stesso release train.

Se sono già presenti delle iterazioni per il team predefinito, è possibile rinominarle. È opportuno creare una struttura di iterazione che supporti l'intera struttura di team e non solo un team singolo.

1. Nell'iterazione predefinita, che ha lo stesso nome del progetto, creare un'iterazione figlio che rappresenta il primo program increment (PI). Facoltativamente aggiungere una data di inizio e di fine per il PI, ma ricordare che l'iterazione verrà suddivisa ulteriormente in sprint.

   

2. Creare quindi un'iterazione figlio per ogni sprint all'interno del PI. Impostare le date per questi sprint in modo che corrispondano alle cadenze dei team feature.

   

Creare e configurare i team

In questa sezione viene configurata una struttura di team gerarchica che mappa i percorsi area gerarchici creati precedentemente.

La struttura mappa i seguenti team SAFe ai team TFS:

• Team portfolio -> team predefinito di primo livello, il team Fabrikam

• Team program -> team di secondo livello, Fiber Suite e Service Suite

• Team feature -> team di terzo livello definiti in Fiber Suite e Service Suite.

Per istruzioni dettagliate, vedere Gestione portfolio Agile: utilizzo di TFS per supportare i backlog tra più team.

Per eseguire questi passaggi è necessario essere un amministratore del progetto in TFS.

Creare e configurare tutti i team program

1. Dalla pagina di panoramica del progetto team creare un nuovo team. Verificare che la casella di controllo Creare un percorso area con il nome del team sia deselezionata.

   

2. Scegliere il team dall'elenco, andare alla pagina Aree e selezionare la casella di controllo accanto al percorso area precedentemente creato per il team.

   

3. Usare il menu di scelta rapida per escludere le sottoaree. Escludendo le sottoaree, il backlog del team include solo gli elementi il cui percorso area corrisponde al percorso area predefinito del team.

   

4. Configurare quindi le iterazioni che saranno attive per il team program. In questo esempio sono stati configurati tre PI, ciascuno con cinque sprint di due settimane. Quattro sprint sono normali, mentre l'ultimo è di tipo Innovation and Planning (IP).

   

     

   Poiché il team program Fiber Suite si occupa del release train, sono stati scelti PI 1, 2 e 3, ma non gli sprint singoli.

5. Dopo aver selezionato le iterazioni attive per il team, aggiungere gli utenti al nuovo team. È preferibile aggiungere gli scrum master per tutti i team feature, i proprietari del prodotto e i release train engineer (RTE) ai team program come Fiber Suite.

   

6. Se ci sono più team a livello di programma ripetere i passaggi da 1 a 5 per ciascun team program.

Creare e configurare tutti i team feature

Vengono quindi creati alcuni team feature per completare il lavoro al terzo livello della gerarchia di team. Ogni team feature aggiunge del lavoro sprint che si amplia nel PI. Il numero di team creato dipende dalle dimensioni dell'organizzazione.

1. Creare un nuovo team per la pagina di amministrazione del team originale e denominarlo. Come in precedenza, verificare che la casella di controllo accanto a Creare un percorso area con il nome del team sia deselezionata.

   

2. Scegliere il team dall'elenco, andare alla pagina Aree e selezionare la casella di controllo accanto al percorso area precedentemente creato per il team.

   

3. Configurare le iterazioni per il team usando i PI e gli sprint creati in precedenza. A differenza dei team program, selezionare gli sprint singoli come iterazioni di lavoro per il team feature.

   

4. Aggiungere gli account per gli sviluppatori, i tester e gli scrum master del team. TFS supporta l'assegnazione di uno scrum master a più team. Lo scrum master può tenere traccia del lavoro in più team.

   

5. Ripetere i passaggi da 1 a 4 per ogni team feature nell'organizzazione. Verificare che il percorso area predefinito configurato per il team sia un sottopercorso area contenuto nel percorso area a livello di programma corrispondente. Così viene assicurato il rollup dai team feature ai team program.

Configurare il team portfolio

Dopo aver configurato la struttura di sottoteam, riconfigurare il team predefinito come team portfolio. Anche se questo team continua ad avere il nome del progetto, le modifiche apportate a questo team di primo livello consentono di tenere traccia efficacemente degli epic nei PI al livello più alto.

1. Nella pagina Aree del progetto team modificare le impostazioni in modo da non includere le sottoaree. Assicurarsi di scegliere il progetto team e non il team predefinito, Fabrikam.

   

2. Nella pagina delle iterazioni deselezionare le caselle di controllo accanto a tutte le iterazioni tranne per il livello radice che non può essere deselezionato. Poiché il team portfolio si occupa solo di epic che estendono PI, usa solo l'iterazione radice e i PI o gli sprint. I team portfolio non funzionano negli sprint.

   

3. Aggiungere e rimuovere gli utenti dal team portfolio appropriato per il livello. Dalla pagina di panoramica scegliere il team predefinito.

   

      

   È possibile aggiungere altri utenti tipo, ad esempio gestori di portfolio, architetti di livello aziendale e release train engineer (RTE) a questo livello e rimuovere tutti gli altri.

   

Personalizzare il processo TFS per supportare SAFe

In questa sezione viene aggiunto il tipo di elemento di lavoro epic alla gerarchia di backlog portfolio. Viene anche aggiunto il campo Tipo di requisito a tutti e tre i tipi di elementi di lavoro del backlog. Vengono creati alcuni epic e le feature vengono mappate in epic.

Per informazioni sul funzionamento dopo aver aggiunto il livello di backlog epic, passare qui. Inoltre, se non si vogliono ripetere i passaggi di personalizzazione descritti in questa sezione, in ALM Rangers è disponibile un post di blog e degli script PowerShell di esempio che mostra come installare le personalizzazioni nel progetto.

Aggiungere l'epic al backlog di portfolio

Come in precedenza, è necessario essere membri del gruppo Project Administrators per eseguire questi passaggi.

Prima di tutto viene esportato un tipo di elemento di lavoro esistente, usato per creare il nuovo tipo di elemento di lavoro denominato epic. Viene anche aggiunto un campo Tipo di requisito per tenere traccia del tipo dell'epic: Architettura o Business. Viene quindi aggiunta una categoria per gli epic. Poi vengono modificati i tipi di elementi di lavoro esistenti, feature e user story, anche se hanno altri nomi, per includere il campo Tipo di requisito. Il campo Tipo di requisito tiene traccia del tipo di obiettivo supportato da ogni elemento di lavoro. Infine viene aggiunto un epic al backlog del team portfolio.

Aggiungere il tipo di elemento di lavoro epic

Il modo più semplice per creare un tipo di elemento di lavoro consiste nel copiare quello esistente, rinominarlo e modificarlo.

Il tipo di elemento di lavoro feature viene esportato e usato come base per il tipo di elemento di lavoro epic.

1. In modalità amministratore, aprire una finestra del prompt dei comandi. Cambiare la directory in cui è stato installato Visual Studio (o Team Explorer).

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

   Nelle edizioni a 64 bit di Windows usare %programfiles(x86)%.

2. Usare lo strumento witadmin per scaricare la definizione del tipo di elemento di lavoro feature e salvarla come Epic.xml.

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

3. Aprire il file Epic.xml, sostituire <WORKITEMTYPE name="Feature"> con <WORKITEMTYPE name="Epic"> e aggiornare la descrizione.

   <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. Modificare <Tab Label="Implementation"> oppure, per CMMI, la sezione <Tab Label="Requirements">, sostituendo le seguenti righe con <Filter WorkItemType="Feature" />.

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

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

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

     Questa modifica consente di limitare il controllo dei collegamenti per supportare gli elementi di lavoro figlio degli epic.

   <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. Aggiungere il campo Tipo di requisito alla definizione del tipo di elemento di lavoro epic. Per questa operazione viene preso in prestito un campo esistente (creato in origine per supportare i progetti CMMI, ma ugualmente utile ai fini dell'esempio) Microsoft.VSTS.CMMI.RequirementType e aggiungerlo alla sezione FIELDS dell'epic.

   Trovare la sezione FIELDS e aggiungere il seguente codice:

   <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. Aggiungere quindi il campo nel form. Nella sezione FORM aggiungere il campo nella posizione più adatta alle esigenze della società. Nell'esempio seguente il campo è stato aggiunto sotto il campo dell'iterazione.

   <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. Salvare e importare il file.

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

Aggiungere la categoria dell'epic

Ora che è disponibile un tipo di elemento di lavoro epic, è possibile aggiungere una categoria per l'epic. TFS gestisce i backlog in base alle categorie.

1. Esportare la definizione delle categorie in un file XML.

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

2. Aprire il file e aggiungere la categoria dell'epic. È possibile sostituire Microsoft con il nome della società per indicare che si tratta della propria personalizzazione.

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

3. Come nella procedura precedente, importare il file.

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

Aggiungere il campo Tipo di requisito per tenere traccia del lavoro Business/Architettura

Il campo Tipo di requisito viene quindi aggiunto alle feature e al terzo livello dell'elemento backlog, a prescindere che si tratti di user story, product backlog item o, facoltativamente, bug. Non è necessario aggiungerlo al requisito perché è già incluso nella definizione CMMI predefinita.

1. Esportare la definizione del tipo di elemento di lavoro feature.

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

2. Aggiungere il campo Tipo di requisito secondo la procedura usata in precedenza per il tipo di elemento di lavoro epic. Trovare la sezione FIELDS e aggiungere il seguente codice:

   <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. Aggiungere il campo nel form nella stessa posizione in cui è stato aggiunto nell'epic. Ad esempio:

   <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. Salvare e importare il file.

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

5. Ripetere i passaggi da 1 a 4 per le definizioni del tipo di elemento di lavoro user story e product backlog item. Facoltativamente, modificare la definizione del tipo di elemento di lavoro bug per tenere traccia di quale requisito è supportato dai bug o per tenere traccia dei bug nel backlog.

Aggiungere la categoria dell'epic alla gerarchia di backlog portfolio

L'epic viene quindi aggiunto alla gerarchia di elementi di lavoro che formano il backlog.

1. Esportare il file di definizione XML per la configurazione del processo.

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

2. Aprire il file e aggiungere una sezione PortfolioBacklog per gli epic nella sezione PortfolioBacklogs. Allo stesso tempo, modificare l'elemento PortfolioBacklog per FeatureCategory in modo che l'epic risulti come elemento padre per le feature.

   Modificare i mapping di metastato secondo necessità in base al modello di processo. Il seguente esempio supporta sia i progetti Agile che CMMI. Aggiungere anche il campo Tipo di requisito alla sezione 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>        
   

   I progetti Scrum richiedono il mapping degli stati del flusso di lavoro Nuovo, In corso e Completato. Si tratta degli stessi stati mappati per l'elemento backlog del portfolio feature.

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

   Inoltre, i progetti CMMI richiedono il mapping degli stati del flusso di lavoro Proposto, Attivo, Risolto e Chiuso.

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

3. Aggiungere parent="Microsoft.EpicCategory" a PortfolioBacklog category="Microsoft.FeatureCategory". Aggiungere anche il campo Tipo di requisito alla sezione 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. Aggiungere il campo Tipo di requisito alla sezione Columns della sezione 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. Aggiungere i colori da usare per l'epic alla sezione WorkItemColors. È possibile scegliere qualsiasi colore, ma si consiglia di non usare un colore già in uso nel sistema.

   Il colore scelto nell'esempio corrisponde all'arancione (codice colore esadecimale=FF7B00). Aggiungere un prefisso al codice colore esadecimale con FF.

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

6. Salvare e importare il file.

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

Aggiornare il percorso area per gli elementi di lavoro esistenti

Per visualizzare gli elementi di lavoro esistenti in un backlog del team, è necessario aggiornare il percorso area di ogni elemento di lavoro nel percorso area predefinito del team. La funzionalità di modifica di massa è disponibile nel Web browser o in Excel.

1. Creare una query che contenga gli elementi di lavoro da modificare, selezionare quelli desiderati e aprire il menu di scelta rapida per ciascuno degli elementi selezionati.

   

2. Selezionare il percorso area che corrisponde al percorso area predefinito del team.

   

3. Salvare in massa tutti gli elementi di lavoro modificati.

   

Per altre informazioni sulla modifica di massa degli elementi di lavoro, andare qui.

Aggiungere gli epic e mappare gli epic alle feature

Dopo aver aggiunto il tipo di elemento di lavoro epic, crearne alcuni. Il processo è uguale al processo di creazione di qualsiasi altro elemento di lavoro backlog. Dalla pagina del backlog del team portfolio per gli aggiungere un elemento backlog epic.

Aggiungere tutti gli epic necessari. Per elencare gli elementi in ordine di importanza, trascinarli all'interno dell'elenco.

Il tipo di requisito predefinito per gli epic è Business, ma è possibile cambiarlo da Business ad Architettura.

È anche possibile aggiungere dei tag agli epic per tenere traccia dei temi di investimento supportati da ciascun epic.

Visualizzare l'epic nella bacheca Kanban. Per ottenere questa visualizzazione è necessario personalizzare le colonne Kanban per rinominare e aggiungere gli stati del flusso di lavoro intermedi. Per una descrizione di questi stati, vedere Business Epic Kanban Abstract.

Questo scenario, però, non è ancora molto interessante. Non ci sono operazioni in corso e non è possibile eseguire il drill down per visualizzare le feature che supportano gli epic. È opportuno mappare le feature esistenti agli epic appena creati e mappare le user story a queste feature, se non sono già mappate.

Mappare più elementi se è disponibile un backlog esistente

Il mapping degli elementi di lavoro è facile se si usa il riquadro di mapping. Dalla pagina del backlog feature o story, attivare il riquadro di mapping. Nell'esempio è stato scelto il team Fiber Suite e sono stati attivati sia il riquadro di mapping che la visualizzazione per visualizzare la gerarchia delle feature mappate agli epic.

Se il percorso area di tutte le feature è stato già modificato nel team a livello program appropriato, l'elenco di feature sarà vuoto perché il team portfolio non possiede alcuna feature. In questo caso passare a uno dei team program.

Trascinare gli elementi dal backlog all'elemento da associare come padre. È possibile mappare solo feature a epic. Analogamente, è possibile mappare solo gli elementi del terzo livello del backlog (user story, elementi di backlog o requisiti) alle feature.

Ripetere questo processo in tutti i livelli del backlog finché non viene creata la gerarchia desiderata.

Le feature già in corso non vengono visualizzate nel backlog del team portfolio. Sono responsabilità dei team program, quindi vengono visualizzate nel backlog di questi team. (Si tratta in realtà di una funzione del percorso area impostata per l'elemento di lavoro; un elemento di lavoro viene visualizzato nel backlog di un team solo se viene assegnato al percorso area creato per tale team). È possibile mappare le feature da questo backlog.

È inoltre possibile modificare in blocco gli elementi di lavoro e gestirne la gerarchia in Microsoft Excel.

Poiché un aspetto importante di SAFe riguarda il mapping del lavoro agli obiettivi relativi al business o all'architettura, è opportuno verificare che il tipo di requisito impostato sia Architettura per tutte le feature mappate a un epic di architettura. (L'opzione predefinita è Business, quindi non è necessario modificare il tipo per gli elementi che supportano un epic di business). È anche possibile aggiungere tag per tenere traccia dell'investimento.

Gli stessi principi si applicano alle user story in corso. È possibile mapparle alle feature, modificare il tipo di requisito su Architettura per il lavoro svolto per il supporto degli epic di architettura e aggiungere tag per tenere traccia dei temi.

Resources

Le risorse menzionate in questo white paper e alcune altre vengono elencate di seguito per riferimento.

• Modelli di processo abilitati per SAFe: collegamento al download dei tre modelli di processo forniti da TFS (Scrum, Agile e CMMI) di cui sono state discusse le personalizzazioni in questo white paper.

• Upgrade/Publish TFS 2013 Process Templates with PowerShell: post del blog di Gordon Beeming che fornisce uno script PowerShell che è possibile usare per applicare le modifiche documentate in questo white paper.

• Scaled Agile Framework: sito delle risorse SAFe.

• SAFe in 7 minutes: video di Inbar Oren, il Lean Samurai.

• Scaling Agile and SAFe TFS Reports: report sullo stato delle funzionalità scaricabile compatibile con il modello di processo Scrum per distribuzioni locali di TFS 2012 e 2013.

• Gestione portfolio Agile: utilizzo di TFS per supportare i backlog tra più team: white paper che descrive come configurare TFS per supportare più team e backlog.

• Trovare elementi di lavoro tramite query (da aggiornare): descrive come configurare TFS per supportare il rollup, i valori sommati dei campi selezionati per tutti gli elementi di lavoro figlio di un elemento padre. Poiché TFS supporta più livelli di annidamento, quando si esegue il rollup è opportuno verificare che i valori non vengano conteggiati due volte.

• Report automatici (SQL Server Reporting Services): riepiloga i report che TFS fornisce per il monitoraggio dello stato e la qualità del codice.

• Sincronizzare Team Foundation Server con Project Server: descrive in che modo i project manager e i team di sviluppo possono usare gli strumenti preferiti e condividere in modo trasparente le informazioni abilitando il flusso di dati dagli elementi di lavoro in TFS alle attività nei piani del progetto dell'organizzazione in Project Server.

• Tenere traccia del lavoro assegnato a due o più team: mostra in che modo uno sviluppatore o un tester può tenere traccia del lavoro quando supporta più team feature.

Informazioni sugli autori

Gordon Beeming è uno sviluppatore software di Derivco nell'assolata città di Durban, Sud Africa. Passa molto tempo alla tastiera occupandosi di Visual Studio oppure si rilassa insieme alla famiglia. L'indirizzo del suo blog è 31og.com ed è possibile seguirlo anche su Twitter all'indirizzo twitter.com/gordonbeeming.

Brian Blackman è uno dei principali consulenti di Microsoft Premier Developer e si occupa di aiutare i partner ISV e le organizzazioni a raggiungere il successo in campo tecnologico e sul mercato. Ha conseguito un MBA, le certificazioni CSM, CSP, MCSD (C++) e MCTS ed è un Visual Studio ALM Ranger. Quando non si dedica al ruck mastering e ai progetti di Visual Studio ALM Ranger, scrive codice, crea e presenta workshop e offre consulenze in diversi ambiti, in particolare per il supporto delle organizzazioni nel migliorare la propria agilità.

Gregg Boer è uno dei principali responsabili del programma in Microsoft. Gregg è il proprietario del prodotto per l'esperienza nella gestione Agile in TFS.

Kathryn Elliott è una scrittrice senior di articoli tecnici in Microsoft.

Susan Ferrell è una scrittrice senior di articoli tecnici e una Visual Studio ALM Ranger.

Willy-Peter Schaub è un responsabile del programma nel gruppo di Visual Studio ALM Ranger nel Centro sviluppatori Microsoft Canada. Dalla metà degli anni '80 si è impegnato a migliorare la semplicità e la gestibilità nell'ambito della progettazione software. Il suo blog è disponibile all'indirizzo blogs.msdn.com/b/willy-peter_schaub ed è possibile seguirlo su Twitter all'indirizzo twitter.com/wpschaub.