Manager une équipe de développement Web

Technologie Web structurée autour de .Net

En tant que chef de projet responsable des technologies Web, mon job consiste à dessiner le contour des technologies de nos sites Internet. Beaucoup de veille, pas mal de jugeotte, aussi, histoire de ne pas se tromper, et de pédagogie, pour faire comprendre aux instances décisionnaires les opportunités et risques associés à toutes ces nouvelles technologies.

Dans un grand projet de refonte globale d'une plateforme Internet, les attentes des directions métiers de l'entreprise peuvent se résumer par un ensemble de macro-briques fonctionnelles.

Là où l'internaute ne doit distinguer qu'un frontal unique, à l'ergonomie cohérente et à la navigation unifiée, nous devons bâtir une architecture fonctionnelle complexe :

• une gestion de contenu opérationnelle, en mêlant les "contenus froids", qui bougent peu au cours du temps, et les "contenus chauds" : actus, news, évènements, témoignages... sous des formes et des gabarits variés : articles de fond, galerie d'images, vidéos...
• une couche de rendue RIA (Rich Internet Application) destinée à la mise en scène des produits,
• un module d'e-Commerce complet, intégrant l'ensemble du parcours client, de l'affichage des offres jusqu'à la phase d'achat, en passant par la gestion du panier et des commandes,
• sans compter qu'il faut bien relier ce module d'e-Commerce au reste du SI de l'entreprise, dans une optique multi-canal, le Web n'étant pas le seul canal de distribution et de vente,
• quelques aspects communautaires doivent être mis en place, forum, plateforme de blog, wiki, échanges de photos et de vidéo : l'entreprise n'est plus seule à communiquer vers ses clients, ses clients communiquent entre eux, et l'entreprise doit faciliter cette communication par le biais de son site Internet, c'est l'un des principes, malheureusement un peu galvaudé, du web 2.0, mais cette association du produit et de ses consommateurs est finalement assez proche de la vrai vie,
• enfin, rien n'empêche l'entreprise de déconcentrer sa dimension Internet et d'aide ses responsables régionaux à la mise en place de sites web locaux.

Le chef de projet technologie web a à sa disposition une palette d'outils, progiciels, techno, bases de données pour superposer sa carte applicative sur cette carte fonctionnelle. Cela peut très vite devenir extrêmement complexe.

• les outils de gestion de contenu ne manquent pas : eZpublish, Typo3, Dropal, Joomla, Spip, côté open source en Php, Noheto en Java, sans compter les ténors du marché comme Documentum, Vignette ou encore Interwoven,
• côté contenu riche, on peut opter pour Flex, avec quelques passages de code Action Script, et puis aussi des bout d'interface Ajax, développé en Javascript
• pour le e-Commerce, là aussi, quelques progiciels réputés : Websphere Commerce chez IBM, Intershop, PowerBoutique pour les PME ou encore de l'open source Php/MySql avec OS Commerce
• côté EAI, les solutions ne manquent pas non plus : Webmethods sous eclipse pour la gestion des processus, ou Tibco par exemple
• pour le communautaire, on va citer DotClear, toujours en Php/MySql
• enfin, pour les sites locaux, gardons l'existant bâti sur le framework open source DotNetNuke.

Ces applications sont toute en pleine maturité. Pas de mauvaise surprie lors du déploiement, donc. Mais attention à l'éparpillement des compétences! Imaginez les bureaux d'une équipe de développement Web :

Un couloir bordé de petits bureaux spécialisés. Avec le chef de projet au bout, et l'infirmerie juste à côté, car pour ce qui est des maux de crâne, à mon avis, le pauvre, il sera bien servi! Avec cette magnifique collection de compétences, difficile de manager sereinement son équipe. Sans compter qu'il n'aura jamais l'autorisation de recruter un backup pour chacune des compétences nécessaires. Que se passe-t-il quand l'application e-commerce plante, et que M Webssphere est en vacances?

Heureusemet, j'ai trouvé la solution : la structuration des applications web autour du framework .Net 2.0!

• MOSS 2007 pour la gestion de contenu, avec une utilisation des web parts et des master pages, classiques pour tout développeur expert en ASP.NET 2.0
• MS Commerce Server 2007 pour la gestion des produits, clients, commandes, règle marketing up-selling, cross-selling, etc ... dont les objets .Net sont accessibles facilement
• une couche d'EAI avec Biz Talk, l'EAI à la sauce Microsoft, directement conceptualisable au travers de Visual Studio
• du SilverLight 1.1 embarquant dans la couche cliente les fonctions principales du framework .Net, sans compter les fonctions du Microsoft Framework Ajax, pour toute la partie RIA
• et pour finir, pourquoi pas s'amuser avec Community Server, la plateforme de blogs, wikis et partage d'images construite sur le framework 1.1?

Quelques compétences de base : le framework .Net, la surcouche ASP.NET, la connaissance de Sql Server et un seul outil Visual Studio, qui permet de partager l'ensemble des projets applicatifs au travers de Team Foundation Server.

Avec une telle architecture, la vie du chef de projet devient soudain beaucoup plus facile. Exit l'infirmerie !

Abonnez-vous au Visual Studio Talk Show !

Je vous invite vivement à visiter le Visual Studio Talk Show, un site de podcast spécialisé sur le développement .Net avec Visual Studio, l'apport de la suite Team System et du serveur Team Foundation Server dans les méthodologies de développement agiles, le cycle de vie des projets de développements et d'autres sujets, toujours autour du framework .Net : Ajax, Silverlight, LinQ, Windows Communication Foundation ... enfin, tout ce qui peut interesser chef de projets, architectes, développeurs, voir maîtrise d'ouvrage un tant soit peu attentif aux technologies Microsoft.

Les émissions sont toutes en français, animées par Mario Cardinal et Guy Barrette , tous deux consultants séniors à Montréal, spécialisés dans les architectures autour des technologies .Net, Mario Cardinal ayant aussi un champ d'expertise avancé dans les processus agiles de développement.

Mise en garde : plus fort que Lost, Grey's Anatomy ou Prison Break, le site est addictif!

Des rôles plein d'agilité

J'aime bien cette image prise dans les locaux de Clear Channel Communications lors de leur évaluation de la méthode MSF pour la configuration de TFS et Team System .

Pour ma part, je n'ai pas (encore?) scotché sur les murs de mon bureau la description des rôles, des flux de travail associé, de leurs activités et sous-activités, je me suis contenté de les imprimer (il faut compter une bonne demie-journée!) et de les consigner dans quelques chemises. Je réfléchie encore à un archivage efficace, porte vue ou autre. Mais l'affichage de Clear Channel a celà d'exemplaire qu'elle montre bien la complexité de l'intégration de l'ensemble de ses rôles, de leur compréhension, de leur assimilation, puis dans un second temps, de leur adaptation, personnalisation, customisation à notre travail de tous les jours. Une tâche passionnante, qui demande aussi une certaine dose d'évangèlisme.

Agile Manifesto

C'est fait : je viens de signer le Manifeste Agile.

Tout est parti de Team Foudation Server et de Visual Studio Team Suite, finalement. Partant d'un besoin d'industrialisation de nos développements Web, je nous avais équipés de TFS et VSTS . Nous avions construit nos projets d'équipe selon la méthodologie Microsoft Solution Framework pour Agile Software Development (et non pour CMMI). Il s'agissait au départ de comprendre comment fonctionnait TFS et ce que je pouvais en tirer pour améliorer notre efficacité. Mais très vire, je me suis aperçu qu'avant de comprendre comment fonctionnait l'outil, il était préférable de comprendre la méthode. D'où mon retour au source sur l'Agile Manifesto. 

Pour ceux qui ne le connaisse pas, voici les 4 principes du Manifeste du Développement Logiciel Agile en français :

Les individus et les interactions doivent primer sur les processus et les outils
Le développement logiciel doit primer sur la documentation exhaustive
La collaboration avec le client doit primer sur la négociation contractuelle
L’ouverture au changement doit primer sur le suivi d’un plan rigide

Il me reste à évangèliser mon boss, mes collaborateurs et mes collègues de la maîtrise d'ouvrage. Puis à mettre tout cela en place dans TFS.

Team Foundation Server : THE Book!

Commandé en milieu de semaine sur amazon, me voici depuis hier en possession du Professional Team Foundation Server de chez Wrox, dans la collection Programmer 2 Programmer, vous savez, avec la photo des auteurs, juste un peu fatigués des nuits blanches passées à écrire l'ouvrage.

Les auteurs :

• Jean-Luc David, évangéliste chez Microsoft Canada, auteur de plusieurs ouvrage. A priori, son blog et son autre blog se sont arrêtés depuis la sortie de l'ouvrage.
• Mickey Gousset, MVP, consultant chez Notion Solutions. Son blog est bien actif, avec pas mal de download.
• Erik Gunvaldson, manager en développement chez Microsoft.

Un bien bel ouvrage, en tout cas.

Je vais me plonger dans la gestion des work items, la première mission que je me suis fixé, maintenant que le serveur est installé, que toutes nos solutions sont migrées dans le contrôleur de source, et que nos documents commencent à s'intégrer dans le portail Share Point.

Mise en place de Team Foudation Server

Lundi, mardi, mercredi : trois journées bien remplie par la mise en place de Team Foudation Server (TFS) avec l'aide inestimable de notre ami Daniel Tizon, consultant chez Winwise, responsable de l'offre TFS, et accessoirement Regional Director Microsoft. Autant dire que ses conseils sont des plus avisés, et que nous avions les oreilles grandes ouvertes et les yeux bien écarquillés pour ne rien manquer des petits trucs qu'il pouvait nous donner.

Entre parenthèses, ma philosophie, en terme d'appel à consulting externe, c'est de toujours prendre les meilleurs. Je suis persuadé que rien n'est pire que d'être mal conseillé, surtout quand on se lance dans une mini révolution comme celle-ci, qui va bouleverser nos méthodes de travail, nos habitudes collaboratives, notre suivi, notre manière de gérer nos archivages ...

Les trois jours ne furent pas de trop.

Lundi : installation du serveur TFS, sur un serveur virtualisé, paramètrage de la base de donnée Sql Server 2005, du portail Share Point, des backup, des power tools, du serveur de buil. Comme nous jonglions entre les versions US et les versions françaises, quelques petits paramètrages particuliers ont du être mis en place.

Mardi : installation du Team Explorer dans Visual STudio 2005, du plug-in pour MS Project, et un après-midi de formation théorique sur les concepts de TFS (j'aime bien la présentation qui fait de TFS un PGI dédié aux développements).

Mercredi : création de nos deux premiers projets d'équipe. Notre choix fut rapide : un projet pour nos sites principaux et un projet pour notre solution DotNetNuke. Et le grand moment : migration de nos sources contrôlés sous Visual Source Safe dans le contrôleur de source de TFS.

Depuis, nous évoluons dans un autre monde! notre conception du développement ne sera plus jamais la même. De l'artisanat, nous passons à l'industrie.

L'émotion est grande, car même si ce n'est encore qu'un début, je suis en train de vivre sur le terrain les expériences glanées ces dernières semaines au travers des différents séminaires d'architecture auxquels j'ai assisté.

Tech Days 2007 : Tests de performance et optimisation des applications

Animateurs : Arnaud Fontaine et Karim CAdi (Unilog Rhônes-Alpes) (Centre de compétences)

Encore des personnes avec qui nous travaillons !

Enjeux et objectifs :
- évaluation d’une nouvelle technologie ou d’une solution d’architecture,
- sur un projet, analyser les conditions de pic de charge et les contraintes de disponibilité,
- ou encore, évaluer une architecture hétérogène.

L’analyse de la performance au sein du cycle projet :
- en phase de prototypage : sizing a priori
- en phase de développement : profiling pour anticiper les problèmes de performance
- en phase de recette : nouveau tests de charges afin de valider/optimiser le sizing cible.

Aujourd’hui, sur le marché, trois offres sont en concurrence :
- les solutions open source : des outils variés et incomplet, aux coûts d’acquisition très faibles, mais à réserver pour des profils très techniques.
- les offres commerciales : des produits très (trop ?) complets, si coûteux, que bien souvent on se limite à une location le temps des tests, qui nécessite de faire appel à du consulting de haut niveau, en résumé, des solutions qui manquent de souplesse.
- enfin, Microsoft, qui s’est logé comme à son habitude dans une niche, celle des middle actors : prise en main rapide, coûts intermédiaires, pour des fonctionnalités moindres que les offres commerciale,s mais mieux packagées que les solutions open source.

Visual Studio Tema Suite Developper et Tester permet différents types de tests de charges :
- tenue de l’application en charges (analyse du comportement sur plusieurs jours pour vérifier si des dégradations n’apparaissent pas au cours du temps, fuite de mémoire, etc …)
- stress de l’application (sur une charge cible et un peu au-delà)
- test de capacité (clcul du nombre d’utilisateurs en fonction des temps de réponses et des machines)

Dans VSTS Tester, pour mettre en œuvre un test de charge Web :
- création d’un projet de test Web
- enregistrement du scénario de navigation
- problème : les appels asynchrones (Ajax) ne peuvent pas être enregistrés
- pour y remédier, il suffit d’utiliser l’outil Fiddler qui enregistre les appels Javascript
- ensuite, on diversifie les requêtes à partir d’une base de données afin de simuler l’appel du même scénario par des utilisateurs différents qui ne naviguent pas sur les mêmes produits, par exemple.
- le script est modifié afin de mapper le code enregistrer au contenu de la base de données, en précisant un mode aléatoire, pour être encore plus réaliste.
- on spécifie ensuite le pattern du test : nombre d’utilisateurs constants ou augmentation par palier
- enfin, on distribue les navigateurs (ils n’ont pas tous les mêmes temps d’actions), les réseaux (un modem stressera moins l’application qu’un très haut débit), et même le « think time » des utilisateurs, c’est-à-dire le temps qu’il faut à l’internaute pour comprendre ce qu’il doit faire sur la page qu’il a sous les yeux.

L’utilisation de l’outil est très aisée. Mais attention à la méthodologie, en particulier, ne pas modifier tous les paramètres en même temps.

Au départ, bien définir les hypothèses :
- ventilation des scénarios fonctionnels (avec l’aide de la maîtrise d’ouvrage)
- la navigation
- la bande passante (ADSL, LAN, 56K)

Effectuer un test étalon :
- fiabiliser les tests de références (être sûr qu’il fonctionne !)
- vérifier la reproductibilité de la procédure de test (si trop d’écart, il est nécessaire d’affiner, d’allonger la durée de test, d’une manière générale, il ne faut pas compter les 2 à 5 premières minutes du test)

Définir les conditions préparatoires avec soin :
- « think time » ou « think profile »
- % de nouveaux utilisateurs
- simulation du cache du navigateur côté client (avec ou sans cache, des variations de 30% peuvent être constatées)

Plan de test : une stratégie d’exploration :
- ne faire jouer qu’un paramètre libre à chaque fois,
- pas d’analyse en cours de campagne (il faut bien définir le test avant le début de la campagne)

Quelques tips appris sur le tas :
- dans le dimensionnement de la plateforme de test : isoler les agents et le contrôleur, limiter la consommation CPU en dessous de 80% côté agents, au-delà, de gros effets de bord apparaissent
- recours à la virtualisation : cela impose de comprendre la liaison entre le hard et le virtual server, et de penser (et comprendre) l’allocation de ressources (exemple : deux serveurs en cluster)
- isoler la plateforme de test du réseau de l’entreprise !

Etude de cas :
- virtualisation de 6 machines : 1 client (le VSTS Tester), 2 agents, 1 contrôleur (avec SqlServer 2005), 1 puis 2 serveurs cibles.
- objectif : 2000 utilisateurs
- premier test : au-delà de 120 utilisateurs, les requêtes non servies croient de manière exponentielle.

Synthèse :
- pour un architecte, les tests de charge peuvent être monter rapidement, une demi-journée de mise en place peut être suffisante
- penser à la virtualisation des environnements

Pour de la pré-production, l’outil parait encore jeune par rapport à l’offre concurrente :
- pas de simulation depanne
- profil de montée en charge basique
- capacité d’analyse assez faible
- mais l’ouverture du produit permet d’y ajouter de nombreux plug in.

Tech Days 2007 : Team Foundation Server, référentiel de projets pour des technologies non-Microsoft

Animateurs : Winwise (Centre de compétences)/Essilor

Visual Studio Team System, c’est bien, mais pour les applications en .Net 2.0, mais que fait-on pour les autres développements ? L’intérêt de cette session était justement de nous montrer, au travers d’un cas client, Essilor, conseillé par Winwise, que TFS peut aussi servir de référentiel pour d’autres technologies de développements.
Bien sûr, des outils périphériques sont nécessaires pour assurer une pareille intégration. Mais depuis la sortie de la gamme VSTS, beaucoup de gens se sont penchés sur ce problème, qu’ils soient éditeurs ou développeurs open source :
- les power toys,
- les outils de migrations VSS vers TFS (nous en aurons besoin d’ici peu quand nous allons nous même migrer vers TFS)
- SCCI pour Toad, Access …
- Outils complémentaires dont 80% de gratuit sur accentient.com/widgets.aspx
- Interface web de gestion de projet TeamPlain
- TeamPrise pour Eclipse (plug in d’intégration complète)
- Outil gratuit sur le bureau : Fissum

Le contexte Essilor :
- Premier producteur de verres ophtalmiques
- 26000 salariés
- 45 pays
- 80% du CA et des salaires hors de France

Le Services des Etudes Informatiques est scindé en deux :
- l’Amont, dont le champ d’intervention est la production, la distribution et la logistique : ERP Oracle Application, peu de développement, modules en place dans les usines, adaptation par site
- l’Aval, qui gère la chaîne des opticiens, de la prise de commande jusqu’à la livraison : les filiales sont autonomes, et l’environnement technique est très hétérogène, puisqu’on y trouve du Delphi, du SAS, de l’Oracle, du Biztalk, du Sharepoint, du VSS et d’autres contrôleurs de sources.

La DSI s’est donné deux objectifs :
- à court terme, regrouper tous les sources dans TFS : les développements sont tous effectués en interne, mais de manière délocalisée, puisque les équipes de développements sont géographiquement situées à Singapour et en Thaïlande
- à moyen terme, suivre la méthode Essilor (support CMMI).

La démarche :
1. migrer les projets Delphi (on commence par migrer les projets les plus complexes),
2. migrer VSS vers TFS (les projets les plus actifs),
3. PVCS vers TFS (multi-techno),
4. TFS de test vers TFS de production (consolidation).

La migration s’est faîte projet par projet, sur le schéma suivant :
- le matin : migration
- l’après-midi : formation.

Quelques chiffres :
- projets Delphi : 600 Mo par version, 6 Go au global. Stratégie suivie : reconstruction de l’historique, intégration complète dans Delphi : MSSCCI Provider + sourceXConnection. Temps passé : 5 jours.
- migration PVCS : TFS avec API complète de manipulation (sur des Web Services). Il a suffi d’écrire un script. Temps passé : 3 jours.
- Migration VSS : outil VSS Converter. Provider MSSCCI pour VS2003. (Attention : il n’y a pas de shelving sur VS2003).
- Enfin, migration TFS test à TFS prod : écriture d’un script. Temps passé : 5 jours. (Winwise mettra d’ailleurs cet outil à disposition).

En terme d’adoption, elle est immédiate chez les développeurs, une formationpour le Team Explorer est nécessaire pour les chefs de projets.

A l’issue de cette session, j’étais conforté sur deux points :
1. nous avons bien fait d’adopter TFS
2. nous avons bien fait de choisir Winwise pour nous aider à migrer et nous former sur TFS (chef de projet et développeurs, d’ailleurs !)

Tech Days 2007 : Intégration continue dans un contexte d'équipes distribuées (off-shore)

Animateur : Avanade (Centre de Compétence TFS)

La présentation est effectuée par Avanade, joint venture Accenture/Microsoft. Il s’agit d’illustrer les principes et bonnes pratiques du contrôle de l’externalisation, par l’utilisation de VSTS, au travers d’un cas client, Veolia Propreté, qui a confié à Avanade le contrôle des équipes délocalisées.

L’externalisation des développements informatiques nécessite une maîtrise totale des coûts et des risques associés. Cette maîtrise est assurée par :
- Le contrôle et la maîtrise de la qualité intrinsèque des applications,
- La réversibilité technique (à tout moment, la DSI doit être capable de récupérer un projet externalisé pour l’internaliser ou l’externaliser ailleurs).
- La maîtrise technique interne des applications.
- La mise en œuvre de contrat de services (qualité attendue, service …)
- L’exploitation d’une méthode de production industrielle (par exemple : prélèvement par échantillonnage sur la chaîne de fabrication logicielle).
- La définition et le partage d’indicateurs (de qualité de code par exemple).

Quelques mots sur le contexte client :

- Veolia Propreté
- 32400 salariés en France / 70000 dans le monde
- numéro 2 mondial
- nombreux métiers (collecte/transfert, dépollution, traitement)
- urbanisation des SI
- rationalisation des applications et des développements

Concernant le macro-process, rien de particulier :

- Cadrage général
- Choix de l’intégration
- Réalisation (pilotage par Avanade/fonctionnelle/technique)
- Réception/déploiement

La DSI a centré ses besoins de maîtrise de l’externalisation sur 3 axes :

- Contrôle en continu de la qualité
- Réversibilité (continue)
- Maîtrise de l’analyse d’impact

Les indicateurs de la qualité :

- Indicateurs usuels (lignes de code, ratio commentaire, etc …)
- Adhérence entre assemblage
o Instabilité = (couplage efférents)/(couplage efférent + afférents) où la notion de couplage équivaut à la référence d’assemblies
o Complexité cyclomatique : dans une méthode, nombre de segments et de nœuds dans la classe
o Manque de cohésion : rapport entre les méthode et les attributs

Bien entendu, Visual Studio nous aide pour effectuer ces différents calculs d’indicateurs.

En résumé, les axes majeurs des moyens mis en œuvre sont :

- Une maîtrise technique interne par une gouvernance adaptée
- Un référentiel de normes sur un large spectre des fonctions de la DSI
- Un contrat de service basé sur une transparence réciproque avec les intégrateurs

Dans la mise en pratique, toute la chaîne de contrôles est appuyée par TFS.

Chez Veolia, un serveur de sources a été mis en place pour récupérer les sources en provenance des intégrateurs. On peut résumer les différents process de la manière suivante :

1. Les intégrateurs livrent sur CD/DVD les sources de leur développement à la DSI
2. Les sources sont installés sur le TFS central chez Veolia
3. les build sont effectués sur le TFS de build de Veolia (avantage : la maîtrise des build est du côté de Veolia et non des intégrateurs)
4. le reporting est mis à disposition sur l’Intranet
5. la gouvernance et le pilotage des projets accèdent aux reporting.

Concernant la réversibilité, chaque projet est dupliqué dans un TFS de réversibilité technique, au sein d’une architecture virtualisée. Un audit de réversibilité est effectué en continu sur le serveur de réversibilité, pour que, à chaque instant, la DSI puisse récupérer tous les work item, les rapports et les build de l’intégrateur, afin de ne pas perdre l’historique des versions d’applications. Le défi : transfert des TFS (ceux de l’intégrateur) vers un autre Active Directory (celui de la DSI) : des scripts ont du être mis en  place pour aider à ces transferts.

Cette contrainte de réversibilité a demandé chez l’intégrateur un pré requis : l’utilisation standard et complète de TFS.

L’ensemble du process de livraison a été normalisé au travers de bons de livraison :
- étapes à suivre impérativement
- versions
- anomalies
- contenu

Lors de la réception, une analyse minutieuse est effectuée :
- analyse de la documentation
- analyse du code
- analyse de la réversibilité technique
- analyse des binaires

Mais un objectif de performance est assigné à ce processus :
- validation la plus rapide possible : 2 jours maximum
- automatisation de certains process de réception.

En synthèse de la session, pour suivre des développements externalisés, il est indispensable :
- de s’assurer d’une maîtrise technique interne,
- de mettre en place des processus industrialisés,
- de s’équiper de VSTS/TFS qui facilite l’étape de l’outillage.

Pour ma part, cette présentation m’a passionnée en tout point. Et donnée des éléments de réponse quant à comprendre pourquoi tant de projets d’externalisation et d’offshore échouent.

Tech Days 2007 : Quelle méthodologie pour quels indicateurs de gouvernance de projets ?

Animateur : EXAKIS (Centre de Compétence TFS)

Qu’est-ce qu’une méthodologie ?

- un ensemble de règles pour mettre en relation l’équipe projet
- un ensemble de normes et de références
- un workflow entre des exigences, des tâches, des bugs …
- des indicateurs de pilotage.

Dans Team System, deux méthodologies standard ont été implémentées :

- Microsoft Solution Framework (MSF) pour Agile Software Development (idéale pour les équipes petites et moyennes : jusqu’à 10 personnes)
- CMMI (pour les gros projets)

La suite VSTS peut se voir comme un ensemble de poupées russes imbriquées les unes dans les autres :

1. gestion documentaire et rapports : à destination de la maîtrise d’ouvrage
2. gestion des work items par le chef de projet technique
3. contrôleur de source et serveur de build : pour les développeurs
4. outils avancés de la suite comme analyse de code, tests unitaires, tests web, tests de charge, pour les architectes et testeurs.

La suite VSTS permet d’instrumenter toutes les étapes de la vie du projet dans un seul outil :

- choix et paramétrage de la méthodologie,
- définition des zones (conception base de donnée, écriture procédures stockées, développement classes, IHM, …) et des itérations (sur 1 mois maximum)
- gestion des work items (exigence, tâche, bug)
- requêtes et vues de work items
- rapports
- portail et espace documentaire

Par exemple, dans la méthode Agile fournie par Microsoft en standard, les work items sont rattachées à une personne (la granularité des tâches est suffisamment petite), à une zone (par exemple : procédure stockée), et ont un état (par exemple : actif).

Bien entendu, la méthode standard peut se customiser sans difficulté (à condition, toutefois, de le faire avant le démarrage du projet, et non pas en plein milieu !) à l’aide du Process Template Editor. L’impact des modifications effectuées n’est pas le même selon les catégories d’items :

- Modification des work items (par le Process Template Editor) : impact très fort. Le mieux est d’effectuer la customisation avant le premier projet. Bénéfice attendu : intégration optimale des termes et processus déjà utilisés au sein de l’organisation.
- Modification des requêtes : impact faible, et peu compliqué à mettre en œuvre.
- Modification des rapports : difficile, les rapports étant associés à OLAP, il faut une bonne connaissance d’OLAP et du cube TeamSystem. Il est préférable, a priori, de conserver les rapports standards, qui sont assez nombreux.
- Modification du portail : connaître SharePoint est indispensable. Permet un respect des normes de documentations en vigueur dans l’organisation.

Quelques démos nous sont présentées.

Utilisation du Process Template Editor pour personnaliser les work items.

En standard, la méthodologie MSF Agile structure les work items en :

- Scénarios
- Risque
- Qualité
- Tâche
- Bug

L’éditeur permet de personnaliser le nom, les champs associés, le workflow (par défaut, seulement deux états : actif/fermé) et l’IHM.

En ce qui concerne les rapports, il suffit de garder à l’esprit que les work items, qu’ils soient saisis dans Excel ou le Team Explorer, sont ensuite publiés dans la base de données de TFS et archivés dans le DataWarehouse. Pour créer un nouveau rapport, il faut ouvrir un projet de type Report Server (ou importer un rapport existant et le modifier). Quant à comprendre le cube OLAP de TFS, il faut s’y plonger avec le SQL Management Studio. Le plus simple reste tout de même Excel et ses tableaux croisés dynamiques.

Quant au portail, rien n’est plus facile que de lui ajouter des documents.

La gestion des rôles dans TFS est liée directement à l’Active Directory. Elle s’applique aux actions sur les work items (un développeur, par exemple, ne pourrait pas clore une tâche), mais les rôles ne peuvent pas être aujourd’hui utilisé pour l’IHM (on ne peut pas masquer certaines tâches à certains rôles, par exemple).

Enfin, TFS n’est pas MS Project : il ne connaît pas la notion de coûts (il gère les charges uniquement).

Tech Days 2007 : 360° de la stratégie à Visual Studio Team System

Animateurs : Jean-Christophe Cimetière et Eric Le Loc’h (Microsoft)

Puisque nous nous équipons dans quelques semaines de Team Foundation Server et d’un Team System Tester, cette journée s’annonçait pour moi riche d’enseignement en terme de retour d’expérience clients sur la suite Team System, un an après sa sortie.
Cette première session de la journée, animée par les deux évangélistes de la suite Team System, permettait un tour d’horizon complet de l’utilisation des différents produits de la suite.

Après un rapide rappel de la philosophie attachée à VSTS : une suite centrée sur les individus, l’équipe projet et la communication, afin de faciliter l’industrialisation des projets de développement informatique, sur toutes les étapes de la chaîne de production, de l’élaboration des besoins jusqu’à la mise en production, en passant par le suivi des builds, des tests et bugs.

Une démo nous est présentée, construite autour d’un scénario classique du process de développement : le traitement d’une anomalie :
1. l’analyste métier découvre un bug : il publie la description de l’anomalie détectée dans Team Foundation Server (TFS), via l’outil de son choix (Excel, par exemple). De nombreux plug-in existent, en effet, pour relier un outil office à TFS, il suffit seulement de s’acquitter d’une licence d’accès client pour permettre la liaison Office/TFS. (l’intérêt : l’analyste métier n’a pas besoin de connaître le fonctionnement TFS pour s’y connecter : pas de coût d’apprentissage !).
2. le chef de projet technique découpe le traitement de l’anomalie en tâches unitaires (développement, test, par exemple) (les work items : entités centrales de TFS) et les affectent aux membres de l’équipe (il peut aussi s’aider d’un MSProject ou d’un Excel afin de suivre la planification de ces tâches : comme pour l’analyste métier, la liaison avec TFS est native). Juste pour information, les équipes de développement de Microsoft utilisent Excel pour leur planification, plutôt que MSProject.
3. le développeur analyse et corrige le bug.
4. les tests, automatisés à partir de différents scénarios et jeux de tests stockés en base de données à partir de Visual Studio Team System pour Tester, sont rejoués, afin de vérifier la non-régression.
5. bien sûr, entre temps, une demande plus urgente a pu être envoyée au développeur. Que doit-il faire du code qu’il vient d’écrire pour corriger la première anomalie et qui n’a pas encore été validé? Il la pose sur une étagère virtuelle ! En effet, TFS autorise le processus de « shelving » : les développeurs ont la possibilité de mettre en étagère du code non validé, sorte de sauvegarde non archivée, qui peut ensuite être récupéré. De ce fait, les autres développeurs ne sont plus bloqués comme avec Visual Source Safe par les bouts de codes non archivés.
6. si la demande concernait une anomalie sur le site Internet, les tests d’intégration Web sont conçus pour jouer les scénarios préenregistrés, avec des jeux de données sous-jacentes, et comparés ensuite avec les résultats du jeu de tests, tout cela, bien entendu, en automatique. Il suffit ensuite au testeur d’analyser les non-conformités éventuelles.
7. enfin, quand tout est validé, le développeur peut lancer un archivage, à condition qu’il ait suivi toutes les règles de bonne pratique. En effet, des règles automatiques empêchent les check-in si toutes les tâches associées n’ont pas été fermées : temps passés, etc … Mais cela ce fait sans surcharge pour le développeur : quelques cases à cochers, quelques champs à renseigner. TFS : des procédures légères, qui ne rebutent pas les développeurs, et permettent un suivi optimal.
8. les build, ensuite, exécuté sur un serveur de build dédié, et non pas sur les environnements des développeurs, peuvent aussi jouer les tests de non régression.

Team Foudation Server est doté nativement d’un portail Share Point, qui permet une entrée unique vers l’ensemble de la documentation du projet (les cahiers des charges, les docs techniques, les doc utilisateurs, etc …) et aussi vers tous les rapports de pilotage et de suivi du projet. Ces rapports peuvent être globaux (suivi de projet classique, charges, temps passés, etc ..) mais aussi techniques et qualitatifs (codes couverts par les tests, par exemple).

Et bien entendu, comme TFS repose sur une base de données SQL Server 2005, le cube OLAP de TFS peut-être récupéré dans Excel 2007 pour mettre en œuvre des tableaux croisés dynamiques, entièrement automatiques, du plus bel effet.