Scrum, XP et TFS 2010

Teneur de la réunion

Comme son nom l’indique, cette réunion qui se déroule avant chaque nouveau sprint à pour but de planifier le sprint à venir.

Cette réunion est donc critique pour le bon déroulement de tout le sprint. A l’issue de cette réunion l’équipe devrait disposer d’assez d’informations pour travailler sereinement pendant plusieurs semaines.

Lors de cette réunion, l’équipe au complet et le directeur de produit vont donc débattre, en se basant notamment sur le backlog de produit afin de déterminer:

• Un but à atteindre pour le Sprint
• Un certain nombre « d’histoires » et de « tâches » qui découpent le travail à effectuer
• La durée du sprint ainsi qu’une date précise pour la démonstration de fin de sprint
• Une heure et un lieu pour la mêlée quotidienne

Il s’agit là de concepts qui méritent d’être précisés.

Le but du sprint

Définit par le directeur de produit, et résumé en début de réunion, il s’agit bien sûr de l’objectif à viser et à atteindre dans le prochain sprint.

Attention: Le but reste totalement fonctionnel et doit pas entrer dans les détails techniques!

Exemples de but:

« Implémentation d’un outil d’analyse des retour clients », « Implémentation d’un moteur de recherche », etc…

Les histoires et les tâches

Il est important de distinguer les histoires des tâches:

• Les histoires cadrent une fonctionnalité désirée de manière globale.
• Les tâches sont des sous-entités d’histoires qui découpent ces dernières en tâches unitaires

Exemple:

Pour l’histoire: « Recherche d’utilisateurs »

Nous auront les tâches:

• Écriture des scénarios de test
• Implémentation de la liste de utilisateurs
• Test, intégration et débogage
• Implémentation du formulaire de requête

Durée du sprint et date de démonstration

La durée des sprints est fixe en théorie cependant, au début de l’application de Scrum vous tatillonnerez pour trouver la durée qui vous convient le plus.

Il n’y a pas de règle dans ce domaine. En réalité cela va dépendre du type de projet sur lesquels vous travaillez, sur la taille de votre (vos) équipe(s) et surtout de votre expérience acquise au fil des sprints.

• Des sprints courts entraînent des livraisons plus fréquentes, donc des retours plus rapides du clients ce qui permet de perdre moins de temps pour les modifications et corrections. On a donc une entreprise plus réactive et plus agile.
• Des sprint longs permettent à l’équipe de mieux monter en puissance, de passer plus de temps sur l’implantation et la correction pour plus de qualité et cela entraine de surcroit une baisse de la charge de réunions et de démonstrations.

Les deux stratégies présentent donc leurs avantages et c’est à vous de trouver le bon compromis dans votre situation. Une valeur moyenne et acceptable pour les sprint semble être de 3 semaines mais encore une fois cela seras différent dans chaque entreprise.

Une fois la longueur du sprint fixée, il est important de tout de suite planifier la date et l’heure précise de démonstration pour le travail effectué lors du sprint. Cette date reste fixe et la démonstration aura lieu quelque soit l’état d’avancement.

L’heure et le lieu de la mêlée quotidienne

La mêlée quotidienne doit avoir lieu tous les jours à une heure et dans un lieu fixes. Il convient de décider d’une heure qui convient à tous les membres de votre équipe cependant on préfèrera programmer celle-ci le matin le plus tôt possible.

En effet il est plus simple d’effectuer cette réunion tôt le matin car chacun y fait un feedback sur le travail effectué la veille et annonce ce qu’il va faire dans la journée à venir.

Le Backlog de sprint, Quésaco?

A la base de tout projet mettant en œuvre la méthode Scrum, il y a la création du backlog de produit.

Le backlog de produit est le document cadre qui servira à la planification de tout le projet et qui servira de référence fonctionnelle sur les exigences du client.

Il se présente sous la forme d’une liste priorisée d’exigences, d’histoires et de caractéristiques décrites par le client. Ce document sera rédigé par le client, en la personne du Directeur de produit puis présenté et completé avec toute l’équipe de développement notamment pour l’estimation du temps..

Ce document, qui peut se présenter sous la forme d’un fichier Excel accessible mis à disposition de l’équipe sur le portail Sharepoint du projet ou dans un dossier partagé.

Structure du backlog

Le backlog comprend les champs de base suivants:

• Le champ Importance, qui définit comme son nom l’indique l’importance contractuelle de la réalisation de cette partie du projet.
• Le champ ID qui détermine un identifiant unique pour l’histoire en question.
• Le champ Nom, ou Description qui décris de manière claire et succincte la fonctionnalité désirée par le client
• Le champ Estimation qui estime en « points » la charge de travail. (L’unité de point fixée au début du projet correspond à des « Jours/Homme idéaux »: 1 point = 1 jour/homme idéal)
• Le champ Comment démontrer qui fait office de spécification de test ultra simplifiée (1 à 2 phrases succinctes).
• Le champ Notes qui permet d’ajouter toute information complémentaire indispensable à la bonne compréhension de l’histoire.

Bien sûr chaque projet est différent et ce tableau doit pouvoir s’adapter au contexte, à l’organisation, et à toute sortes de paramètres qui peuvent être important de préciser dans le backlog. C’est pourquoi vous êtes libres d’ajouter à ces champs d’autres champs que vous pourrez juger utiles tels que:

• Un champ Catégorie qui fera la distinction entre les nouveau développements et les optimisations par exemple.
• Un champ ID de suivi de bug si vous utilisez un système de suivi de bug.

On peut donner de nombreux exemple, et c’est à vous de juger si la nécessité de tel ou tel champs se justifie. N’oubliez pas cependant que ce document n’as qu’un rôle de cadre et qu’il ne doit en aucun cas être surchargé afin de rester lisible.

L’Importance

Le champs importance est déterminé selon une échelle totalement libre. En effet une histoire avec une importance à 80 ne seras pas forcément 4 fois plus importante qu’une histoire avec une importance de 20.

Simplement, il est important que chaque histoire ait une importance unique afin de créer une hiérarchie claire entre celles-ci et il est également important de laisser un écart suffisant entre chacune d’elle à la création du backlog. Il faudra être en mesure de pouvoir insérer de nouvelles histoires que l’on aurait pas forcément prévu.

Pour aider à déterminée l’échelle que l’on va utiliser, on peut se fixer 3 seuils avec un code couleur:

• >= 50: (Rouge) Histoire indispensable à la release. Si elle ne sont pas livrées à temps, cela entraînera des pénalités.
• 20 < x < 50: (Jaune) Histoire indispensable mais qui autorise un petit délai de livraison sans pénalité.
• <= 20: (Vert) Histoire secondaire qui pourront être livrées dans une version mineure suivante.

Une fois ceci effectué, on complètera le backlog avec le code couleur choisit pour une meilleur lisibilité du document.

A retenir

Garder bien en tête que le Directeur de produit doit rester focalisé sur les objectifs métier et ne pas se soucier des aspects techniques. C’est également le cas pour ce document qu’il rédige et qui ne servira que de cadre fonctionnel à l’équipe.

Création d’un work item

La gestion des work item s’effectue dans la console Team Explorer de Visual Studio ou depuis le site portail de projet.

Pour cet exemple, nous allons effectuer la création d’une nouvelle tâche depuis la vue Team Explorer de Visual Studio.

Connectez-vous à votre projet dans Team Explorer puis dérouler les sous-éléments du projet. Vous devriez voir un élément Work Item

Cliquez sur Add Work Item > Task

Saisissez ensuite les informations nécessaires puis cliquez sur Save Work Item.

Afficher et valider les Work Item

Une fois le Work Item créé, dans Team Explorer déroulez Work Items puis cliquez sur Open Work Items afin d’afficher tous les work items ouverts et de vérifier qu’aucun problème n’est survenu lors de la création.

Sélectionnez la tâche afin d’en visualiser les informations. De là vous pouvez changer l’état de la tâche, et faire remonter des informations pour les autres membres de l’équipe en fonction de son état d’avancement.

Relations entre les Work Items

La gestion des liens entre les work items est une des nouvelles fonctionnalités de Team Foundation Serveur 2010.

Le principe est de pouvoir reporter dans le système les relations de dépendances entre les éléments de travail. Ces liens peuvent être de type :

• Enfant <=> Parent
• Prédécesseur <=> Successeur
• Testé par <=> Test
• Lié
• Etapes partagées
• Scenario de test manuel (test case)

Ces relations sont mises en place grâce à l’onglet Links de chaque Work Item.

Nous allons mettre en œuvre ce principe afin de voir de quelle façon cela va changer notre approche dans la gestion de projet.

Lier des work items

Pour cet exemple je pars du principe que nous avons déjà plusieurs work item créés. Ici il s’agit de quelques tâches de développement et de tests qu’il est importants de lier à ces derniers.

Pour cet exemple je me base sur 2 tâches d’ajout de fonctionnalité au programme et 3 scénarios de test qui devront valider le bon fonctionnement de ces fonctionnalités.

Configuration des liens

Dans le Team explorer, éditez la première tâche. Ouvrez l’onglet Other Links puis cliquez sur Add (Link).

Sélectionnez le type de lien Successeur, puis saississez l’ID de la  seconde tâche ou cliquez sur Browse si vous ne connaissez pas son ID.

Vous pouvez saisir un commentaire pour votre équipe si vous le souhaitez.

Validez l’ajout en cliquant sur OK puis sauvegardez le work item.

La tâche dispose maintenant d’un lien vers sa tâche successeur. La seconde tâche dispose quand à elle d’un lien prédécesseur vers la première :

Affichage des relations

Afin de bien tester les options d’affichage des liens entre work item, j’ai ajouté les relations suivantes :

• La seconde tâche est successeur de la première
• La première tâche est testée par le premier test
• Le second test fait parti des tests de la seconde tâche
• Le troisième test est lié au second

Par défaut, l’affichage « plat » proposé par la requête Open Work Items ne permet pas d’identifier les relations entre work item du premier coup d’œil.

Cependant, Team Foudation Server 2010 propose deux nouveaux modes d’affichage beaucoup plus pratiques pour la gestion des work items.

Pour modifier l’affichage afficher la requête puis cliquez sur Edit Query :

Dans la liste Type of query, vous pouvez changer le type d’affichage :

L’affichage par défaut est une liste plate de work item : 1 ligne par work item. Vous pouvez donc changer de type d’affichage et sauvegarder la requête afin de valider la modification.

Mode Work Item et  Liens Directs

Cet affichage permet de liste sous chaque work item de la liste les liens qui lui sont associés. Cela est être très utile lorsque l’on souhaite connaitre tous les liens d’un ou plusieurs work item.

Mode Arbre de Work Items

Ce mode offre une vue d’ensemble des dépendances de types Parent <=> Enfant et Prédécesseur <=> Successeur sous forme d’un arbre.

Attention : les tests liés à des tâches ne sont pas inclus sous forme de branches mais listés à part.

Interface indispensable à la collaboration dans les équipes de développement, le portail SharePoint créé lors de la création d’un nouveau projet d’équipe rassemble toutes les informations et les outils nécessaire à un travail en équipe.

Accéder au portail

Pour accéder au portail de projet vous pouvez procéder comme suit :

• Dans Team Explorer (Visual Studio), effectuez un clic droit sur votre projet dans l’arborescence TFS, puis cliquez sur Show project portal

• Vous pouvez également accéder à ce portail par son adresse web qui sera de la forme :

http://nomServeurTFS/sites/nomCollection/nomProjet

Après vous être identifié, et si vous avez les droits d’accès au site bien entendu, vous arrivez sur la page d’accueil du site:

Ce site est basé sur la plateforme de sites collaboratifs SharePoint de Microsoft et en reprend l’apparence de la future version 2010. La navigation devraient devrait se faire naturellement pour toute personne ayant déjà eu une expérience utilisateur même basique de ces portails.

Pour les autres, pas de panique ! Voici une présentation des différents menus et outils de ce portail :

La Navigation

La barre de menu

La barre de menu horizontale propose des raccourcis vers 3 fonctionnalités régulièrement utilisées à savoir :

• La création d’un Work Item
• La création d’un rapport de SQL Server Reporting Services en format Excel
• La duplication du tableau de bord afin de créer plusieurs tableaux de bords spécifiques
• A la droite de cette barre de menus un champ de recherche permet d’afficher les détails d’un Work Item à partir de son numéro

Le menu vertical

Ce menu que vous retrouverez systématique à gauche des pages du site portail, permet la navigation entre les différentes informations disponibles :

• Home : Raccourci vers la page d’accueil du portail
• Portals : Sélection du portail de projet parmis les collections de projets du serveur TFS
• View all site content : Liste complète du contenu disponible sur le site
• Web Access : Accès à TFS Web qui offre une alternative web du Team Explorer de Visual studio
• Dashboards : Liste des tableaux de bords disponibles. Vous pouvez bien entendu créer mais aussi personnaliser ces derniers.
• Excel Reports : Liste des rapports générés au format Excel. Le système en offre une quinzaine déjà configurés dès l’installation mais vous pouvez également créer les votres.
• Reports : Liens vers le Gestionnaire de rapports de Reporting Services
• Documents : Liste les documents d’équipe du projet  par type : documents partagés, rapports, wikis, guide de processus et tableaux de bords
• Lists : Liste les informations de type « Liste SharePoint » qui est une type générique permettant la mise à disposition de nombreux types d’information de manière très simplifiée
• Process Guidance : Guide aide-mémoire rappelant les principes et étapes de la méthode de développement choisie (Agile ou CMMI de base)

Le fil d’Ariane

Le fil d’ariane permet de vous situer à tout moment sur le site et de revenir à des étapes précédentes de votre navigation.

Le menu personnel

Vous le trouverez toujours en haut à droite de la page que vous consultez. Ce menu vous permet d’éditer vos informations personnelles, de vous déconnecter ou bien encore d’accéder à l’interface de personnalisation de  l’affichage du site.

Le champ de recherche

Vous pouvez effectuer une recherche sur le contenu du site de projet.

Le menu Actions du site

Il vous permet d’ajouter et éditer du contenu sur le site de projet, ainsi que d’en modifier les paramètres si vous avez les avec les droits suffisants.

La gestion de projet

Dans la zone de contenu : Affichage du tableau de bords

• Affichage de graphiques de Reporting Services. L’affichage par défaut offre des graphiques d’analyse de l’efficacité de l’équipe par rapport aux estimations. Ces graphiques sont bien entendu modifiables et personnalisables

• Le Product Backlog est un journal permettant de voir les opérations en retard et par conséquent à effectuer en priorité sur le projet

• Le volet récapitulatif sur la droite fédère de manière succincte les principales informations nécessaires à une vision globale de l’état du projet en un seul coup d’œil à savoir:
  • Les évènements à venir
  • Les éléments de travail
  • Les dernières builds réalisées
  • Les derniers check-ins de code réalisés

La version 2010 de la suite Team System apporte son lot de nouveautés dans le domaine des tests et j’ai pensé qu’il serait intéressant de faire un petit état des différentes possibilités qui s’offrent à nous dans ce domaine.

Si vous voulez vous informer sur la mise en œuvre des tests je vous conseille vivement de consulter le blog d’Etienne Margraff.

Types de tests disponibles:

• Tests manuels

• Tests unitaires

• Tests unitaires de bases de données

• Tests fonctionnels de sites Web:
  • Tests de navigation:  types règle de validation > action avec possibilité d’ajout de boucles et conditions (Simulation des échanges http)

• Tests fonctionnels d’interface graphiques Winforms et WPF:
  • Enregistrement de scénarios: http://msdn.microsoft.com/fr-fr/vstudio/dd262186.aspx

• Tests de montée en charge:
  • Web services et BDD: stress tests
  • Génération de rapports détaillés
  • Définition précise de l’environnement matériel et logiciel

• Tests Ordonnés : Exécution de séries de tests dans un ordre prédéfini

Autres fonctionnalités:

• Enregistrement de vidéos lors de l’exécution des tests

• Captures d’écran

• Journaux d’erreurs et d’évènements à l’exécution des tests pour une traçabilité très poussée

• Planification et exécution de campagnes de tests avec le Test Plan Manager

• Tests unitaires impactés : sélection automatique des tests concernés lors de la modification d’une portion de code par un développeur

• Génération de rapports avec le reporting service de SQL Server

• Débuggeur historique (pas à pas inversé)

• Débuggeur déployable à distance en mode déconnecté: Visual Studio 2010 Remote Debugger

• Génération et déploiement des environnements de tests virtualisés avec Hyper-V Server et Lab Management

• Points de sauvegardes de la machine virtuelle avec Hyper-V
  

• Développement guidé par les tests

• Création de listes de tests dans Visual Studio (Test Suite Manager)

Webcasts:

Je vous recommande également la vidéo de présentation des TechDays 2009: Visual Studio 2010 : les nouveautés de l’édition Test

Team Foundation Build est le service de gestion et planification des builds de la suite Team System. Nous allons commencer par configurer ce service pour notre collection de projet puis nous créerons notre première build d’équipe.

Structure du service

Afin de mieux comprendre la structure du service voici un schéma l’illustrant :

On remarque qu’un serveur de build permet de gérer plusieurs contrôleurs et ce afin de pouvoir répartir la charge entre plusieurs serveurs assumant chacun le rôle de contrôleur.

Chaque Contrôleur de build est dédié à une et une seule collection de projets.

Ils permettent eux de gérer plusieurs agents de Build dans le but de simplifier au maximum les différents types de builds que l’on souhaite mettre en place et de coller au plus près à la structure de vos projets.

Les agents de builds effectuent directement les tâches suivantes :

• Récupérer et valider le code depuis le gestionnaire de sources
• Compile le code
• Exécute les tests

La structure de notre service de builds pourra donc être très simple comme très complexe en fonction de vos besoins.

Ainsi on peut imaginer attribuer un Build Agent par Collection de projets puis dans chaque contrôleur, créer un Build agent pour les builds complètes programmées chaque soir, un autre pour des builds spécifiques ou par module, et une dernière pour l’intégration continue (à chaque check-in).

Toutes les possibilités sont exposées sur le site msdn :

http://msdn.microsoft.com/en-us/library/dd793166(VS.100).aspx

Configuration du service

Ouvrez une session sur le serveur avec un compte membre des Administrateurs de la machine.

Depuis la console MMC Team Foundation Server Administration Console, ouvrez le detail du serveur de Build en cliquant sur Team Foundation Build.

Par défaut aucun service n’est configuré. Pour configurer le Service de Build :

• Cliquez sur Configure sous le nom de votre serveur

Dans la fenêtre de configuration :

• Cliquez sur Browse afin de sélectionner votre collection de projet
• Choisissez le compte TFSService afin d’exécuter le service de Build
• Saisissez le mot de passe du compte TFSService
• Cliquez sur Start

Configuration du Contrôleur

Une fois le service de build installé et lancé, cliquez sur New Controller.

Un contrôleur par défaut est créé, nous devons le configurer, cliquez sur Properties

• Spécifiez un nom plus parlant que Default controller
• Entrez une description si nécessaire
• Passez le statut d’Unreachable à Enabled
• Cliquez sur OK

Le contrôleur est alors configuré correctement mais n’est pas encore lancé, cliquez sur Start pour le démarrer.

Configuration de l’agent

Une fois le contrôleur correctement configuré et prêt, cliquez sur New Agent

Dans les propriétés du nouvel agent :

• Saisissez un nom et une description claire pour l’agent
• Sélectionnez le Contrôleur que l’on à créé pour la collection
• Changez le statut à Enabled
• Cliquez sur OK

Une fois toutes ces étapes complétées, vous devriez obtenir l’affichage suivant :

Virtualisation des contrôleurs

Si vous disposez d’un serveur puissant doté d’Hyper-V, vous pourrez créer une machine virtuelle par contrôleur. L’exécution de contrôleurs de build, et de leurs agents dans une machine virtuelle freine sensiblement les performances, mais offre une sécurité supplémentaire grâce à Hyper-V et sa gestion avancée des points de sauvegardes qui permettent un retour en arrière en cas de problème.

Microsoft préconise dans ce cas d’attribuer au moins un cœur du processeur ainsi qu’un disque dur physique par contrôleur afin de ne pas trop altérer les performances des agents.

Création d’une Build programmée

Pour cet exemple, nous allons programmer une compilation de l’intégralité du projet qui interviendra tous les jours ouvrés de la semaine à 1h du matin afin que les développeurs disposent d’une version à jour chaque matin à leur arrivée.

Ouvrez Visual Studio, puis dans le Team Explorer déroulez votre projet puis effectuez un clic droit sur le dossier des builds et enfin cliquez sur New Build Definition.

• Dans l’onglet Général, vous devez saisir un nom et une description pour la Build qui vous permettrons de l’identifier par la suite.

• Dans l’onglet Trigger, vous pouvez configurer les conditions dans lesquelles la compilation devra s’exécuter. Les possibilités sont les suivantes :
  • Manual : Déclenché par l’utilisateur
  • Continuous integration : Déclenché à chaque dépôt sur le contrôleur de code source
  • Rolling builds : Déclenchement après un intervalle de temps spécifique
  • Gated check-in : compile et teste l’intégrité du code avant de valider chaque dépôt de code
  • Schedule : Déclenché selon un planning déterminé

  C’est donc ce dernier que l’on va utiliser en programmant une nouvelle compilation tous les jours ouvrables à 1h du matin :

• Dans l’onglet Workspace, il s’agit de déterminer l’espace de travail sur lequel porte la compilation, par défaut il s’agit du dossier de travail de votre projet. Dans notre cas nous laisserons donc la valeur par défaut.

• Dans l’onglet Build Defaults, sélectionnez le contrôleur créé précédemment et saisissez un chemin réseau pointant sur un partage du serveur créé à cet effet :Important : Pensez à donner les droits en Lecture, Ecriture et Modification sur le partage au compte de service utilisé par Team Foundation Service (TFSService).

• Dans l’onglet Process, il est possible de définir un fichier template de Build codé avec le language XAML afin de personnaliser le processus de compilation.Nous nous contenterons pour l’instant de garder le template par défaut.

• L’onglet Retention Policy permet de configurer le nombre de builds conservés en historique pour chaque résultat possible (stoppé manuellement, échoué, partiellement réussi et réussi).
  

  Onglet Retention policy

Sauvegarder la Build Definition. Elle apparaît maintenant dans Team Explorer et sera exécutée en temps et en heure.

En lisant mes flux rss, je suis tombé sur un article de Brett Schuchert, rédacteur sur le blog Object Mentor qui nous fait part d’un concept original pour la réunion d’avancement quotidienne.

Pour rappel, la réunion d’avancement a pour but de faire le point sur l’avancement et décider des objectifs du jour de manière très succincte. Pour s’assurer que ces réunions ne tirent pas en longueur et que chacun aille à l’essentiel, il nous propose de les effectuer tous debout et d’en profiter pour effectuer quelques exercices.

La personne qui a la parole pourra par exemple porter un poids, d’abords léger, puis au fur de plus en plus lourd au fil du temps afin de profiter de cette réunion afin d’offrir une séance sportive quotidienne à votre équipe.
Cependant afin de ne pas se retrouver rapidement avec des développeurs aux bras de culturistes sur des corps de poulets, il est important de suivre un programme varié à la semaine.

Voici donc une proposition de programme que vous pourrez adapter à votre convenance (commencer avec des poids léger tout de même).

• Lundi haut du corps: avec haltères, bras le long du corps, levez le bras vers l’avant ou le côté.

• Mardi cardio: trottiner sur place, sautez en ramenant les genoux le plus haut possible.

• Mercredi bas du corps: haltère sur les épaules, flexion de haut en bas.

• Jeudi cardio: trottiner sur place, sautez en ramenant les talons aux fesses.

• Vendredi abdominaux: mains sur la taille, jambes légèrement écartées et tourner le buste de gauche à droite avec le plus d’amplitude possible.

Une idée vraiment pas bête tant l’exercice fait défaut dans notre métier. Qu’en pensez-vous?

Les Work Item sont les éléments de bases du travail en équipe sur Team Foundation server.

Ce sont des éléments de travail que l’on utilisera afin de guider le travail des membres de l’équipe en leur attribuant des tâches et en effectuant un suivi précis de celles-ci.

Les Différents Types de Work Items

Bug

Utilisé lorsqu’un bug est identifié, la tâche décris la manière de reproduire le bug, le comportement actuel ainsi que le résultat attendu.

Exemple : Le bouton de validation reste inactif même si tous les champs sont remplis.

Issue

Utilisé pour demander une modification d’un élément déjà existant exemple

Exemple : Changer le lien hypertexte vers l’aide par un bouton

Shared Steps

Les étapes partagées sont des tâches récurrentes des tests manuel qui seront donc réutilisées à chaque fois que l’on en a besoin afin d’éviter de recréer un nouvel item à chaque fois.

1. saisir le login
2. saisir le mot de passe
3. cliquer sur « connecter »

Task

Une tâche est typiquement une nouvelle fonctionnalité à implémenter

Exemple : Ajouter un champ pour une adresse e-mail de secours

Test Case

Les tests cases sont des scénarios de test manuel c’est à dire qui ne seront pas effectuer grâce à du code mais par un testeur qui effectuera les opérations demandées manuellement et effectuera un retour sur le résultat obtenu.

Exemple :

1. se connecter
2. aller sur « mon profil »
3. cliquer sur « parrainage »
4. entrez une adresse email de test
5. cliquez sur envoyer l’invitation

User Story

Les user story sont également des scenarios de tests manuels mais beaucoup moins détaillés que les tests cases. Il s’agit uniquement de décrire en language usuel la fonctionnalité que l’on souhaite tester et le résultat attendu et ceci en une à deux phrases maximum. Il s’agit d’un concept phare de la méthode agile extreme programming. On peut lier des tests cases à une user story afin de détailler les étapes.

Exemple : les clients peuvent inviter un ami par mail.

Les paramètres des Work Items

Tableau récapitulatif

Détail des paramètres

Status

• Title : titre du work item
• Assigned to : utilisateur qui devra réaliser la tâche
• State : état de réalisation de la tâche
• Area : partie du projet concernée par la tâche
• Iteration : iteration à laquelle la tâche doit être réalisée
• Reason : raison(s) de l’existence de cette tâche
• Activity :
• Automation Status : automatiser l’exécution

Planning

• Stack Rank : rang dans l’ordre de realisation des tâches
• Priority : degré d’urgence de la réalisation
• Story points : Nombre d’étapes dans le scenario de test
• Risk : degré de risqué d’échec estimé
• Severity : degré d’importance de la tâche
• Due Date : date de realisation prévue

Effort

• Original Estimate : estimation du temps nécessaire
• Remaining : estimation du temps restant avant réalisation
• Completed : temps de travail déjà effectué

Autres

• Description : description du work item
• History : raisons pour laquelle le work item à été créé
• Steps to Reproduce : étapes à reproduire dans le work item
• Links : lier des éléments au work item (work item, lien…)
• File Attachement : lier  des fichiers (image, fichier texte…)
• System Infos : état du system au moment du test
• Test Cases : tests manuels pour tester la correction du bug
• Steps : étapes de la tâche partagée
• Implementation : lier des tâches parentes et enfants
• Tested Work Item : lier des tests préalables
• Associated Automation : associer un test automatisé

Une fois l’installation et la configuration de TFS effectuée, (en suivant la procédure décrite dans le fichier d’aide TFSInstall.chm également disponible à la racine du Dvd d’installation de TFS) vous allez pouvoir commencer à en expérimenter les fonctionnalités.

Collection de projet

Une des nouveautés de la version 2010 est l’apparition de collection de projets permettant un classement beaucoup plus efficace de vos projets. Vous pouvez par exemple décider de créer des collections de projets par client pour une société de service, par service pour du développement en interne.

A chaque collection de projet est associé une base de donnée ainsi qu’un site portail permettant ainsi de désolidariser les projets n’ayant aucun lien.

Avant de créer notre premier projet nous allons donc créer une nouvelle collection de projet « ProjetsTestTFS » qui va contenir notre nouveau projet.

Ajouter une collection de projet

• Ouvrez la Team Foundation Administration Console

• Déroulez l’arboresence de votre serveur TFS et cliquez sur Team Project Collections

Il existe déjà une collection appelée DefaultCollection qui a été créée au moment de l’installation de TFS.

• Cliquez sur Create Team Project Collection

L’assistant de création rend l’opération très simple :

• Entrez un nom et une description pour la collection.

• Sélectionnez votre instance de SQL Server.

• Sélectionnez l’application Web SharePoint sur laquelle vous souhaitez installer le site de projet.

• Cliquez sur le bouton Verify afin de vérifier la validité des informations de configuration.

• Une fois toutes les conditions remplies avec succès, cliquez sur Create.

Une fois la création terminée, cliquez sur Complete. Vous verrez alors votre nouvelle collection dans la liste

Configurer les droits de la collection de site

Dans la Console d’administration de Team Foundation, dans la liste des collections de projets, sélectionnez la collection ProjetsTestTFS puis cliquez sur Administrer Group Membership

Double-cliquez alors sur le groupe Project Collection Administrator et ajoutez les comptes utilisateurs responsables de la création des projets dans la collection.

Projet

Chaque projet dispose de son propre site portail ce qui permet de gérer les droit séparément pour chaque projet afin de s’adapter à l’équipe.

Ajouter un nouveau projet

Vous allez maintenant ajouter un nouveau projet dans cette collection.

Ouvrez une session avec un compte disposant des droits d’administration sur la collection et ouvrez Visual Studio.

Attention : Vous devez impérativement avoir Team Explorer installé sur Visual Studio. Ce dernier est compris dans les versions Team Suite, architect, tester… Vous trouverez également son fichier d’installation sur le dvd de Team Foundation Server.

Ouvrez la vue Team Explorer et connectez-vous à votre serveur TFS, sélectionnez votre collection de projet puis cliquez sur Connect.

Une fois votre Team Explorer connecté à la nouvelle collection de projets, effectuez un clic droit sur la collection puis cliquez sur New Team Project.

• Saisissez un nom ainsi qu’une description du projet.

• Sélectionnez le template Microsoft pour les développement Agile.

• Vous pouvez ensuite laissez les autres options par défaut et lancer la création en cliquant sur Finish.

Votre projet est maintenant créé et vous le retrouvez dans votre Team Explorer.

Configurer les droits du projet

Effectuez un clic droit sur le projet dans le Team Explorer, puis cliquez sur Team Project Settings et enfin Group Membership.

Sélectionnez le groupe Contributors et ouvrez ses propriétés afin d’ajouter les membres de l’équipe du projet.

Une fois dans les propriétés du groupe, sélectionnez le type Windows User or Group, puis cliquez sur Add.

Renseignez les utilisateurs qui contribueront au projet, puis cliquez sur OK

Vous pouvez bien évidemment recommencer l’opération pour le groupe des responsables des Builds (Builders) et pour donner un accès en consultation (Readers).

Vos utilisateurs pourront maintenant participer au projet en se connectant avec leur compte. Cependant il faut encore donner les droits d’accès au site de projet sharepoint.

Configuration des droits d’accès au site portail

Connectez-vous au site de projet avec un compte administrateur de la collection (http://nomServeur/sites/nomCollection/nomProjet)

Nous pourrions attribuer les droits au cas par cas cependant il est plus prudent dans un souci de maintenance de créer des groupes d’utilisateurs et d’attribuer les rôles aux groupes plutôt qu’aux personnes.

Dans les paramètres du site (Site Actions > Site Settings) ouvrez la liste des utilisateurs autorisés (People and Groups) puis rendez-vous sur le formulaire de création d’un groupe en cliquant New > New Group :

• Donnez un nom au groupe

• Saisissez une description pour le groupe

• Gardez le compte administrateur de la collection de site comme propriétaire ou choisissez un autre compte qui sera en charge du groupe

• Attribuez les droits adéquats (ici Contribute)

• Cliquez sur Create pour créer le nouveau groupe

Une fois le projet créée la liste des membres apparaît, avec pour seul membre notre propriétaire défini dans le précédent formulaire :

• Cliquez sur New > Add Users

Renseignez alors le nom d’un utilisateur membre puis sélectionnez le groupe précédemment créé et cliquez sur OK pour valider.

Effectuez ces opérations pour tous les utilisateurs nécessitant un accès. Vous pouvez également ajouter des groupes de sécurité Active Directory comme membre d’un groupe SharePoint.

Team System est une plateforme collaborative complète destinée au développement d’applications en équipes.

La suite se compose de nombreux produits. Team Foundation Server est le noyau dur de la suite et de nombreux produits associés permettent d’en exploiter toutes les possibilités.

Les composants de Team System 2010

Côté Serveur :

• Team Foundation Server :

Il s’agit du cœur du système. Team Foundation Server fournit :

-         Source Control : gestionnaire de sources

-         Work Item tracking : suivi des éléments de travail (Work Item)

-         Builds Management : gestion des Builds

-         Test Case Management : gestion des tests

-         Lab Management : gestion des environnements de test

• Windows SharePoint Services :

Il s’agit du moteur de sites collaboratifs de Microsoft, utilisé pour les sites de projet, l’interface privilégiée de collaboration et de communication au sein de l’équipe.

Il propose par défaut un guide de processus, des documents de projet, des modèles et des fonctions de suivi des éléments de travail (Work Item).

• SQL Server Reporting Services :

Il s’agit d’un service de génération de rapport utilisé par Team Foundation Server pour fournir des outils d’analyse personnalisables au chef de projet et aux membres de l’équipe.

Côté Client :

• Visual Studio :

On ne présente plus le meilleur ami du développeur en environnement .Net. Les outils de Team Foundation Server sont parfaitement intégrés dans Visual Studio.

Il existe une version spécialisée pour chaque métier :

-         Visual Studio for Software Architects

-         Visual Studio for Software Developpers

-         Visual Studio for Software Testers

-         Visual Studio for Database Professionals

Il est également possible de n’installer Visual Studio Team Explorer pour la gestion et l’analyse des projets.

Visual Studio version Team System regroupe les fonctionnalités de toutes ces versions.

• Team Explorer :

Team Explorer est l’outil, intégré à Visual Studio permettant aux utilisateurs d’interagir avec le Serveur TFS. Il offre

• Web Access :

Ce service offre des fonctionnalités similaires au Team Explorer depuis une interface web. Il permet donc d’administrer vos projets depuis un ordinateur distant ou ne disposant pas de Team Explorer installé.

• Test & Lab Manager :

Le Test & Lab Manager est une nouvelle interface dédiée aux testeurs. Il permet la création, la planification et l’exécution des campagnes de tests, la gestion des configurations de test (couplé avec Hyper-V) ainsi qu’un suivi et un reporting des bugs.

• Test Runner :

Le Test Runner est un outil intégré au Test & Lab Manager permettant de guider les testeurs lors des phases de tests manuels et offrant également un support pour le suivi de ces derniers.

• Office :

Intégration au sein de MS Project ainsi que MS Excel pour le suivi des éléments de travail (work items).

• Expression :

Il s’agit de la suite d’outils centrée sur le développement web et multimédia et qui intègre également des outils d’interaction avec le serveur TFS.

Extensibilité

Microsoft a prévu la possibilité d’étendre le modèle de TFS avec le SDK (Software Development Kit) pour Team Foundation Server. Ceci pour permettre à la communauté d’utilisateur d’adapter le produit à leurs besoins et d’étendre ses fonctionnalités.

Configuration matérielle

Voici les spécifications matérielles minimales préconisées par Microsoft pour l’installation de Team Foundation Server :

Utilisateurs	Processeur	Disque dur	Mémoire	Configuration
Moins de 20	1 cœur >= 2,2GHz	8Go	2Go	1 Serveur*
20 à 250	1 cœur >= 3,6GHz	230Go	2Go	1 Serveur
250 à 450	2 cœurs >= 2,8GHz	500Go	4Go	1 Serveur
450 à 2200	2 cœurs >= 2,8GHz	31Go+137Go raid1	3,5Go	2+ Serveurs**
2200 à 3600	4 cœurs >= 2,2GHz	31Go+137Go raid1	3,5Go	2+ Serveurs

* Configuration à 1 serveur : Team Foundation Server 2010, Team Build Server, SharePoint et MS SQL Server sur la même machine.

** Configuration à 2 ou plus serveurs : Configuration répartissant les différents services sur plusieurs serveurs afin de répartir la charge.