vendredi 31 mai 2013

Créer des maquettes efficaces en collaboration

J'ai enregistré une nouvelle émission dans la série Bon App!. Je vous y présente les outils à disposition pour la réalisation des maquettes dynamiques dans la suite Visual Studio ALM et comment les créer en collaboration.

Les avantages d'une maquette dynamique

La création d'une maquettes dynamique (storyboard, animation, mockup) permet de clarifier les fonctionnalités d'une application à développer. Elle permet aux utilisateurs de se projeter dans la future application afin de valider les fonctions à implémenter. Si vous y intégrez la charte graphique, vous pourrez aussi la valider à l'avance!

Les outils Storyboard et SketchFlow

Visual Studio 2012 Premium installe un Add-In PowerPoint. Celui-ci vous permet d'étendre les fonctionnaltés de PowerPoint et vous fourni beaucoup de formes prédéfinies pour accélerer le maquettage (PageWeb, controles Windows UI, Windows Phone, ...).
Dans l'update 2, Microsoft a inclus SketchFlow un outil de mockup intégré à Blend. Celui-ci vous permet d'aller encore plus loin en créant une véritable maquette interactive avec une expérience utilisateur très proche de celle de l'application finale (clique et sélection d'éléments, navigation libre dans les différents écrans, réutilisation de composants, ...)

La collaboration et l'implication des utilisateurs

Pour obtenir une maquette de la meilleure qualité et acceptée par tous, il est important d'obtenir des retours et commentaires de la part de l'équipe et des utilisateurs. Les outils de collaboration sont variés : TFS, SharePoint, FeedBack Client, Yammer.... Dans ma société, nous avons mis en place un processus pour nos outils internes. Il permet un premier retour par l'équipe via SharePoint puis une deuxième boucle par les utilisateurs finaux via Yammer.

lundi 20 mai 2013

Afficher le bogue dans le Web Access

Dans un billet précédent Ajouter l'effort au type bogue, j'ai expliqué comment ajouter le suivi des temps au type Bogue. Afin de tirer parti des nouvelles fonctionnalités du Web Access, je vous propose de réaliser les modifications nécessaires pour l'y ajouter. A nouveau, je précise que cet ajout n'a de sens que dans le cadre de l'utilisation du processus Msf Agile 5.x ou 6.x
Celui-ci affiche l'ensemble des éléments de travail dont le type est dans la catégorie Task. Si vous souhaitez intégrer le type Bogue à l'outil de planification Agile, il faut l'ajouter à cette catégorie. Vous aurez alors la possibilité de gérer la capacité de l'équipe sur l'ensemble du travail restant des tâches et bogues.

Modifier le type bogue

Avant de l'intégrer, il nous faut à nouveau modifier le type Bug/bogue. Il est indispensable d'ajouter un champ Activity utilisé dans la planification agile et il est intéressant d'ajouter l'état New/Nouveau au type Bug/Bogue pour obtenir une meilleure cohérence entre les 2 types.

Ouvrez une console de commande en tant qu'administrateur et tapez les commandes suivantes pour télécharger les définitions du type Bug/Bogue et Task/Tache :
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
Si ce n'est pas déjà fait, vous devez Ajouter l'effort au type bogue en ajoutant les champs de référence Microsoft.VSTS.Scheduling.Xxxx.
D'abord, vous copiez la définition de champ de référence Microsoft.VSTS.Common.Activity depuis le fichier Task.xml et les collez dans le fichier Bug.xml sous le noeud FIELDS. Vous devez aussi ajouter le contrôle correspondant dans la colonne Planning dans la définition de l'interface.
<FIELD name="Activity" refname="Microsoft.VSTS.Common.Activity" type="String" reportable="dimension">
    <HELPTEXT>Type of work involved</HELPTEXT>
    <SUGGESTEDVALUES expanditems="true">
        <LISTITEM value="Development" />
        <LISTITEM value="Testing" />
        <LISTITEM value="Requirements" />
        <LISTITEM value="Design" />
        <LISTITEM value="Deployment" />
        <LISTITEM value="Documentation" />
    </SUGGESTEDVALUES>
</FIELD>
Vous ajoutez l'état "New" au noeud STATES en le copiant à partir de l'état "Active" du type Bug/Bogue :
        <STATE value="New">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
              <ALLOWEXISTINGVALUE />
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedBy">
              <ALLOWEXISTINGVALUE />
              <EMPTY />
            </FIELD>
          </FIELDS>
        </STATE>
Puis, vous remplacez la transition de l'état "" à l'état "Active" par les suivantes:
        <TRANSITION from="" to="New">
          <REASONS>
            <DEFAULTREASON value="New" />
            <REASON value="Build Failure" />
          </REASONS>
        </TRANSITION>
        <TRANSITION from="New" to="Active">
          <REASONS>
            <DEFAULTREASON value="Work started" />
          </REASONS>
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
              <ALLOWEXISTINGVALUE />
              <COPY from="currentuser" />
              <VALIDUSER />
              <REQUIRED />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
              <SERVERDEFAULT from="clock" />
            </FIELD>
            <FIELD refname="System.AssignedTo">
              <DEFAULT from="currentuser" />
            </FIELD>
          </FIELDS>
          <ACTIONS>
            <ACTION value="Microsoft.VSTS.Actions.StartWork" />
          </ACTIONS>
        </TRANSITION>
        <TRANSITION from="Active" to="New">
          <REASONS>
            <DEFAULTREASON value="Work halted" />
          </REASONS>
          <ACTIONS>
            <ACTION value="Microsoft.VSTS.Actions.StopWork" />
          </ACTIONS>
        </TRANSITION>
Enfin, vous ajoutez au minimum la transition de l'état "Closed" à "New" dans le noeud TRANSITIONS. Vous pouvez copier la transition depuis celle de l'état "Closed" à "Active". Vous pouvez aussi ajouter toutes les transitions depuis/vers l'état "New", cela permettra de déplacer depuis/vers n'importe quelle colonne du tableau le bogue:
        <TRANSITION from="Closed" to="New">
          <REASONS>
            <DEFAULTREASON value="Regression" />
            <REASON value="Reactivated" />
          </REASONS>
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
              <ALLOWEXISTINGVALUE />
              <COPY from="currentuser" />
              <VALIDUSER />
              <REQUIRED />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
              <SERVERDEFAULT from="clock" />
            </FIELD>
            <FIELD refname="System.AssignedTo">
              <COPY from="field" field="Microsoft.VSTS.Common.ResolvedBy" />
            </FIELD>
          </FIELDS>
        </TRANSITION>
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

Modifier les catégories

Vous allez ajouter le type Bug/Bogue à la catégorie Task pour qu'il apparaisse dans le tableau de taches. Ouvrez une console de commande en tant qu'administrateur et tapez les commandes suivantes pour télécharger en local le fichier des catégories :
cd %programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE
witadmin exportcategories /collection:http://tfsserveur:8080/tfs/DefaultCollection /p:TestProj /f:C:\Categories.xml

Vous allez ensuite modifier la catégorie Task pour lui ajouter le type Bug/Bogue comme suit.
  <CATEGORY refname="Microsoft.TaskCategory" name="Task Category">
    <DEFAULTWORKITEMTYPE name="Task" />
    <WORKITEMTYPE name="Bug" />
  </CATEGORY>
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 des catégories.
cd %programfiles(x86)%\\Microsoft Visual Studio 11.0\Common7\IDE
witadmin importcategories /collection:http://tfsserveur:8080/tfs/DefaultCollection /p:TestProj /f:C:\Categories.xml

Modifier la configuration du processus :

Ouvrez une console de commande en tant qu'administrateur et tapez les commandes suivantes pour télécharger en local le fichier de configuration du processus :
cd %programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE
witadmin exportcommonprocessconfig /collection:http://tfsserveur:8080/tfs/DefaultCollection /p:TestProj /f:C:\commonConf.xml
Vous ajoutez à la categorie Bug l'état "New" en "Proposed" :
  <BugWorkItems category="Microsoft.BugCategory">
    <States>
      <State type="Proposed" value="New" />    
      <State type="InProgress" value="Active" />
      <State type="Complete" value="Closed" />
      <State type="Resolved" value="Resolved" />
    </States>
  </BugWorkItems>
Et vous ajoutez à la categorie Task  le statut "Resolved" en "Resolved" afin de visualiser aussi cette colonne dans le tableau de taches :
  <TaskWorkItems category="Microsoft.TaskCategory">
    <States>
      <State type="Proposed" value="New" />
      <State type="InProgress" value="Active" />
      <State type="InProgress" value="Resolved" />
      <State type="Complete" value="Closed" />
    </States>
  </TaskWorkItems>
Ouvrez une console de commande en tant qu'administrateur et tapez les commandes suivantes pour télécharger sur le serveur la nouvelle configuration du processus:
cd %programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE
witadmin importcommonprocessconfig /collection:http://tfsserveur:8080/tfs/DefaultCollection /p:TestProj /f:C:\commonConf.xml
Note : Si nous n'avions pas ajouter le champ Activity au Bug/Bogue, nous aurions l'erreur du type suivant:
The following element contains an error: TypeFields/TypeField[type='Activity'].
TF400501: The value of this element is set to: Microsoft.VSTS.Common.Activity. Y
ou must set the value to a field that exists in the work item types that are def
ined in: TaskWorkItems. These work item types must also have the following field
 defined:  TypeFields/TypeField[type='RemainingWork']. The field does not exist
in the following work item types: Bug.

Afficher et gérer les bogues

Vous pouvez maintenant planifier la capacité de votre équipe en considérant le temps restant sur les bogues et visualiser ou modifier ceux-ci depuis le tableau de tache du Web Access.
Il vous faudra tout comme pour les taches vous assurer que le bogue est attaché en tant qu'enfant à un User story/récit utilisateur et qu'il est bien assigné aux bonnes zones et itérations. Je conseille de créer le lien et vérifier les infos au moment du triage.

have a nice day.

mardi 30 avril 2013

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.

lundi 15 avril 2013

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.

vendredi 5 avril 2013

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.