Retour sur le Scrum Day 2013

Je vous expose (enfin!) mon retour d'expérience sur le Scrum Day du 11 avril 2013. Tout d'abord, mon impression générale est très positive, l'ambiance est chaleureuse avec énormément d'échanges. Je sens personne de "perdu" ou qui se soit retrouvé ici par hasard.

Après une session d'ouverture pleine d'excellentes idées et conseils pour travailler sur soi, et ses pratiques en équipe par Rorbert Richman. J'ai ensuite effectué une matinée très REX avec les 3 sujets :

• Expérimentation de l'agilité au CNES, 
• Projet Mobile chez Cetelem en Scrum,
• 5 ans d'agilité à la DSI d'Orange.

Ces retours d'expérience mettent en lumière des points communs. L'effort et le courage sont essentiels pour l'adoption d'un processus agile puis son amélioration continue. La mise en place des bonnes pratiques se fait par étapes (presque une après l'autre). Globalement les équipes travaillent mieux ensemble et avec une meilleur satisfaction au travail.

L'après-midi fut moins terre à terre : embarquement et décollage pour objectif Mars ... version 2. Cet "Agile Game" montre bien l'équilibre délicat entre la production de valeur (le code), la réduction de la dette technique, l'analyse fonctionnelle/technique et la formation de l'équipe. La forme est à la fois très proche d'un jeu de société et des conditions de réalisation de Sprints. Ces 2 éléments transforme l'atelier en un moment convivial et passionnant.

La session de clôture m'a semblé comme le bouquet final de cette journée. Elle fut très animée et présentée par un excellent orateur Dominique Dupagne. De part son métier de médecin, il fait un intéressant parallèle entre le Vivant et l'Agile. Le système immunitaire serait par essence Agile (auto-organisation, création des anti-corps par itérations), nous serions des Sprints. L'idée est poussée très loin, voir jusque une certaine forme de provocation : l'agilité? c'est le retour à la vie !

have a nice day.

Ajouter l'effort au type Bogue

A plusieurs reprises, des clients m'ont demandé : comment intégrer le temps estimé, complété et restant sur une anomalie ? Vous pouvez traiter cette question facilement de 2 manières :

1. ajouter une tache liée sur laquelle vous gérer les temps
2. modifier le type Bug/Bogue pour y ajouter les champs nécessaires

Pour les modèles de processus Scrum v2.x et CMMI v2.x, je conseille d'utiliser la première (la seconde ne suivant pas la démarche et les principes de ces processus). Pour le modèle Msf Agile v5.x ou 6.x, les 2 approches peuvent être utilisées. La première est triviale à mettre en place. Pour la seconde, vous trouverez ci-dessous les étapes vous permettant d'intégrer la gestion des temps au type Bug/Bogue.
Pour réaliser les opérations, vous devez disposer des autorisations nécessaires le projet d'équipe. Les membres du groupe Project Administrators (ou plus) ont les autorisations nécessaires. Vous devez aussi installer Visual Studio 2012 Team Explorer sur votre machine.
Vous pouvez aussi effectuer les modifications à l'aide du Process Template Editor inclus dans les TFS Power Tools.

Télécharger en local les types Bug et Task

Ouvrez une console de commande en tant qu'administrateur et tapez les commandes suivantes pour télécharger les définitions des types Bug et Task:
cd %programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE
witadmin exportwitd /n:Bug /f:C:\Bug.xml /collection:http://tfsserveur:8080/tfs/DefaultCollection /p:TestProj
witadmin exportwitd /n:Task /f:C:\Task.xml /collection:http://tfsserveur:8080/tfs/DefaultCollection /p:TestProj

Modifier le type Bug/Bogue

D'abord, vous copiez les 3 définitions de champs de référence Microsoft.VSTS.Scheduling.xxx depuis le fichier Task.xml et les collez dans le fichier Bug.xml sous le noeud FIELDS.

<FIELD name="Remaining Work" refname="Microsoft.VSTS.Scheduling.RemainingWork" type="Double" reportable="measure" formula="sum">
        <HELPTEXT>An estimate of the number of units of work remaining to complete this task</HELPTEXT>
      </FIELD>
      <FIELD name="Original Estimate" refname="Microsoft.VSTS.Scheduling.OriginalEstimate" type="Double" reportable="measure" formula="sum">
        <HELPTEXT>Initial value for Remaining Work - set once, when work begins</HELPTEXT>
      </FIELD>
      <FIELD name="Completed Work" refname="Microsoft.VSTS.Scheduling.CompletedWork" type="Double" reportable="measure" formula="sum">
        <HELPTEXT>The number of units of work that have been spent on this task</HELPTEXT>
</FIELD>

Puis, vous copiez aussi la définition de l'interface pour ces 3 champs depuis le fichier Task.xml (cherchez Effort). Vous collez ensuite ces définitions dans le fichier Bug.xml  dans une nouvelle colonne sous le même Group que la colonne Planning. Vous pouvez remaniez l'interface comme vous le souhaitez.
Pour le type Bug de la version Msf Agile v5.x, indiquez 50 pour les attributs percentwidth des 2 colonnes contenant Planning et Effort (Hours).
(Pour le type la version Msf Agile v6.x, indiquez 25 pour les attributs percentwidth des 4 colonnes  du groupe contenant Planning et Effort (Hours) )

        <Group>
          <Column PercentWidth="50">
            <Group Label="Planning">
              <Column PercentWidth="33">
                <Control FieldName="Microsoft.VSTS.Common.StackRank" Type="FieldControl" Label="Stack Ran&amp;k:" LabelPosition="Left" NumberFormat="DecimalNumbers" MaxLength="10" />
              </Column>
              <Column PercentWidth="33">
                <Control FieldName="Microsoft.VSTS.Common.Priority" Type="FieldControl" Label="&amp;Priority:" LabelPosition="Left" />
              </Column>
              <Column PercentWidth="33">
                <Control FieldName="Microsoft.VSTS.Common.Severity" Type="FieldControl" Label="Se&amp;verity:" LabelPosition="Left" />
              </Column>
            </Group>
          </Column>
          <Column PercentWidth="50">
            <Group Label="Effort (Hours)">
              <Column PercentWidth="33">
                <Control FieldName="Microsoft.VSTS.Scheduling.OriginalEstimate" Type="FieldControl" Label="Original &amp;Estimate:" LabelPosition="Left" />
              </Column>
              <Column PercentWidth="33">
                <Control FieldName="Microsoft.VSTS.Scheduling.RemainingWork" Type="FieldControl" Label="Re&amp;maining:" LabelPosition="Left" />
              </Column>
              <Column PercentWidth="33">
                <Control FieldName="Microsoft.VSTS.Scheduling.CompletedWork" Type="FieldControl" Label="Comp&amp;leted:" LabelPosition="Left" />
              </Column>
            </Group>
          </Column>
        </Group>

Mettre à jour le type Bug/Bogue dans TFS 

Ouvrez une console de commande en tant qu'administrateur et tapez les commandes suivantes pour télécharger sur le serveur la nouvelle définition du type Bug/Bogue dans le projet d'équipe :
cd %programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE
witadmin importwitd /f:C:\Bug.xml /collection:http://tfsserveur:8080/tfs/DefaultCollection /p:TestProj

have a nice day.

Sélectionner les projets pour l'analyse de code

A l'origine, j'ai eu cette problématique car Code Analysis génère une erreur sur l'analyse d'une librairie portable (l’anomalie est signalée sur le site connect ). J'ai donc cherché une première solution de contournement pour lancer l'analyse de code lors d'une compilation automatisée.

L'objectif est de lancer l'analyse de code sur les projets lors de la Build automatisée. Je souhaite aussi  sélectionner le jeu de règles utilisé pour chaque projet.

Configurer l'exécution de l'analyse de code

Pour que l'analyse de code ne soit pas lancée à chaque fois que le développeur compile, je vais la paramétrer uniquement sur une configuration particulière: Release et Any CPU. Celle-ci n'est habituellement pas utilisée sur les postes de développement.
Pour le mode Release et Any CPU, j'active pour chaque projet souhaité l'action exécuter l'analyse de code à la compilation.
Vous pouvez changer le paramètre dans l'interface des propriétés du projet sous Visual Studio (onglet Code Analysis).

Vous pouvez aussi utiliser votre outil de recherche/remplacement de texte préféré sur les fichiers .csproj. Il suffit d'ajouter dans le noeud suivant :

<propertygroup condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
</propertygroup>

le contenu suivant

<RunCodeAnalysis>true</RunCodeAnalysis>

Choisir les ensembles de règles à vérifier

Il nous faut encore choisir l'ensemble de règles à vérifier pour chaque projet.
Vous pouvez le faire d'un coup pour tous les projets et toutes les configurations depuis les propriétés de la solution et sélectionner Common Properties > Code Analysis Settings. Vous pouvez aussi ouvrir la fenêtre d'analyse de code depuis le menu Analyse > Windows > Code Analysis et cliquez sur Configure

Il reste plus qu'à choisir les jeux de règles pour chacun des projets dans l'interface ci-dessous

Le développeur peut alors lancer l'analyse de code sur son poste, il doit basculer temporairement en Release et compiler à nouveau la solution (Rebuild)

Configurer la définition de Build

Enfin, vous configurez la définition de Build pour compiler la solution en configuration Release et plateforme Any CPU. Éditez la définition, modifiez le paramètre Items to Build :

Il vous reste à mettre en file d'attente une nouvelle compilation pour vérifier le paramétrage.

have a nice day.

Session TechDays 2013

Aux Techdays 2013, j'ai présenté avec Cristal Union notre retour d’expérience sur le développement d’applications Windows Store avec Visual Studio ALM 2012.

Au cours de la session, nous avons abordé l'ensemble des aspects qui nous ont permis la réussite et la qualité des développements :

• expression du besoin via storyboard et feedback, 
• méthodologie Agile,
• déploiement et automatisation des tests techniques,
• plan de recette et tests fonctionnels,
• points à retenir et perspectives de la plateforme.

Vous pouvez accéder à la vidéo et aux diapositives sur le site des TechDays 2013 :
http://www.microsoft.com/france/mstechdays/programmes/2013/f…

have a nice day.