Compte rendu des Valtech Days 2007

Pascal Roques, formateur Valtech, et expert UML reconnu mondialement, a expliqué comment selon lui UML pouvait cohabiter avec les méthodologies et pensées agiles.

Il a notamment commencé par rappeler l'origine d'UML (RUP) et son utilisation la plus aboutie actuellement (MDA).
Il a également rappelé qu'UML n'est pas une méthode mais un langage, ce qui ne fait pas d'UML un "concurrent" aux méthodes agiles. Néanmoins, la puissance et surtout complexité d'UML peut s'avérer être un frein à son utilisation dans le cadre de projets agiles.

Après avoir évoqué successivement le RUP, OpenUP, puis XP et Scrum, avec pour chacune de ces méthodologies un focus sur les attentes en terme de modélisation, Pascal Roques s'est focalisé sur l'approche "Modélisation Agile".

La modélisation agile, dont l'un des acteurs est Scott Ambler reprend les valeurs d'XP pour les appliquer à la modélisation.
Cette approche est également soutenue par Craig Larman (guru Scrum chez Valtech)
On y retrouve notamment la volonté de simplifier (un modèle à but unique), de ne pas se surcharger de modèles (ne pas vouloir tout maintenir et oser jeter ce qui n'est plus primordial), la modélisation participative et visuelle sans nécessairement recourir à des outils informatiques (tout du moins des logiciels simples d'utilisation) et dans un but de réflexion et non de documentation.

En conclusion, Pascal Roques estime donc qu'un sous-ensemble UML a sa place dans les méthodologies agiles : juste ce qu'il faut de modélisation, tant que cela reste simple, compréhensible, et que cela guide la mise en oeuvre et non se dédie à la documentation.
Présentation très intéressante et extrèmement enrichissante.

• Le blog de Pascal Roques
• Agile Modeling
• Le forum Conception

Laurent Sion, expert JEE chez Quest Software, a présenté brièvement sa société, puis a exposé à l'assistance une démarche de qualité dans la mise en oeuvre d'applications JEE de développement à la production.

Après avoir rappelé l'importance de cerner et traiter les problèmes le plus en amont de la production, Laurent Sion a présenté les axes d'études et outils utiles à chaque phase de la mise en oeuvre d'une application.

Concernant la phase de développement, il a notamment évoqué l'importance de déceler les problèmes de mémoire (fuites mémoire, usage du Garbage Collector, analyse mémoire), d'audit du code (algorithmie, contension, interblocage), de profiling.
Il en est arrivé à la conclusion qu'il est nécessaire de pouvoir automatiser la majorité de ces tests unitaires de performance (JUnit / HTTPUnit, profiling, couverture de code, rapports, vérification de non régression) pour pouvoir assurer une bonne qualité en sortie de développement.

Puis, il nous a présenté les problématiques qu'il recommande de traiter en pré-production, notamment sur les axes d'assemblage de composants et d'interaction avec des applications externes.
L'étude des serveurs et de la répartition de la charge (en distinguant les différents tiers constituant l'architecture), du CPU, des IO et de la mémoire des machines, ainsi que du trafic réseau, doivent permettre d'aboutir à un dimensionnement de la plateforme.

Enfin, au niveau de la production, l'objectif est de mettre en oeuvre un supervision technique, ceci afin de détecter au plus tôt les baisses de performance d'un service en particulier, de les corréler à un ou plusieurs composants techniques, puis de localiser le composant en cause via un diagnostic pouvant aller jusqu'au détail de la requête SQL.

En conclusion, dans cette démarche, les différentes étapes (développement, pré-production, production) de mise en place de l'application forment un tout, et la qualité de service est favorisée, à l'image d'un asservissement, par la mise en oeuvre à tous ces échelons de ce genre de recommandations.
La présentation manquait néanmoins de concret et est restée assez théorique à mon goût. On reprochait presque à Quest Software de ne pas avoir assez voulu mettre en avant ses produits.

Nicolas Chapon, consultant Valtech Technology, a présenté la solution JBoss Seam comme un choix pertinent - voire un standard - dans la galaxie des frameworks Java EE.

Il a notamment rappelé quelques similitudes avec Rails, mettant en avant la simplicité du framework (scafolding, notamment de tests unitaires TestNG, peu de fichiers de configuration, etc.) et a mentionné que la version 2 de JBoss Seam était attendue pour la fin 2007.
Il a également fait le parallèle entre Spring et Seam, en estimant que Seam un framework d'intégration JEE 5 comme Spring en est un pour J2EE 1.4.
Enfin, il a rappelé les fondements de ce framework (annotations, intercepteurs, etc.) et que Seam était le principal inspirateur de la JSR Web Beans, futur standard JEE 6.

Nicolas Chapon a par la suite présenté les simplifications apportées par Seam : la simplification des interactions entre JSF et les EJB3, le mécanisme d'injection dynamique, les 2 nouveaux contextes que sont le contexte conversationnel et le contexte processus, la prise en charge du contexte de persistance JPA, la simplification de JSF l'utilisation d'Hibernate Validator, l'intégration de librairies Ajax, etc.
Il a notamment fait un focus sur le contexte conversationnel qui se trouve entre la session et la request, et qui permet d'avoir une gestion de la mémoire plus saine et moins contraignante reposant sur des scénarios métier. Visiblement un bon compromis entre la tentative de limiter le scope session quitte à systématiquement remettre des informations dans le scope request, et la mise en session systématique avec des tentatives de purge de la session bien souvent intrusives.
Concernant JPA, la durée de vie du contexte de persistance semble notamment étendue à la durée de vie d'une conversation, et permet ainsi de mettre de côté tout problème potentiel de lazyloading.
Les améliorations autour de JSF semblent également très intéressantes : gestion des redirect HTTP et support du GET, gestion du PageFlow (notamment le back du navigateur), des composants de type grille avec gestion de la sélection (on récupère directement l'objet sous-jacent sélectionné), etc.

Enfin, l'IDE Red Hat Studio Developper (en beta actuellement, licence GPL) a été mentionné. Cet environnement de développement basé sur la plateforme Eclipse est la fusion d'Exadel avec JBoss IDE.

Une présentation très intéressante. Elle donne envie de s'intéresser à JBoss Seam.

• Le site des équipes JBoss
• Présentation de Web Beans par Gavin King
• Démarrer avec Seam
• Red Hat Developer Studio
• Le forum JBoss

Le début de l'après midi fût l'occasion d'assister à la présentation de Patrick Smith - Agitar Software - sur le thème des tests, et en particulier les "characterization tests" qui permettent de décrire le comportement de l'application.

Cette session fût l'occasion de rappeler qu'agilité rime avec minimisation des coûts du changement, sans pour autant éviter ce changement.
Partant de cette définition, Patrick Smith a essayé de catégoriser les tests Agiles comme suit :

• Tests de spécification (ex. FIT)
• Développement guidé par les tests (TDD)
• Tests servant de documentation
• Tests de non régression
• Tests mettant en évidence un bug
• Tests permettant de décrire ce que fait le logiciel

Toutes ces variantes de tests peuvent se regrouper sous 2 formes : les tests unitaires et les tests d'acceptation (acceptance tests), chacun répondant à une préoccupation particulière et recourant à un langage différent (de programmation pour les tests unitaire, à une langue comme le français pour les tests d'acceptation).

Il a ensuite cité Michael Feathers qui, dans son ouvrage Working Effectively with Legacy Code aborde le paradoxe du test sur les applications existantes :

• too complex to test
• too risky to sumplify

Partant de ce constat, il nous a exposé le raisonnement suivant basé sur les tests de caractérisation (characterization tests).
Le but de ces tests est de décrire le comportement de l'application, sans pour autant servir ni à vérifier son fonctionnement, ni à documenter, ni à concevoir.
L'objectif est de se servir de ces tests pour améliorer la qualité du code tout en maitrisant le changement, avec pour but ultime de favoriser les tests (pas ceux de caractérisation évidemment qui ne servent que de support à la mise en oeuvre.

Néanmoins, il est nécessaire d'appliquer ces tests sur toute l'application pour garder la maitrise du remaniement.
Par contre, étant donné que leur mise en place ne nécessite aucune intelligence humaine, ils peuvent être générés et/ou délégués à une unique personne.

Sur la base de cette réflexion, Patrick Smith nous a présenté l'offre de sa société en la matière (Java), notamment AgitarOne Test Generation et AgitarOne Agitator.
Il nous a également renvoyé vers le site http://www.junitfactory.com/ qui propose gratuitement une génération de tests de caractérisation, et qui se base sur la version commerciale AgitarOne.

Je ne connaissais pas cette approche, et cela s'avère être plein de bon sens.

• Le blog de Michael Feathers
• JUnit Factory
• Agitar Software
• Le forum Tests
• Le forum Tests Java

Thème classique depuis quelques années désormais, le framework Spring nous a été présenté par Denis Peyrusaubes, formateur chez Valtech Training.
Il a commencé par insister sur le fait que Spring constituait un méta-framework et n'avait aucune raison d'être seul, pour souligner qu'affirmer vouloir faire un projet "Spring" était dénué de sens.

Après avoir présenté les raisons historiques à la naissance de ce framework (complexité des EJB et recours à un Serveur d'Application notamment), il nous a donné un aperçu des différents modules que sont :

• Core
• ORM
• DAO
• AOP
• Context
• Web
• Web MVC

Sa présentation s'est ensuite focalisée sur la partie IoC et ses avantages : changement d'implémentation, facilitateur de tests, couplage moins fort des composants.
Puis, il nous a présenté le principe des proxies et intercepteurs, notamment pour la mise en oeuvre et la configuration de la sécurité / authentification, des traces, des transactions, bref autant de thèmes transverses au métier d'une application.
Enfin, via quelques exemples des JdbcTemplate et HibernateTemplate, il a expliqué en quoi les bibliothèques / surcouches Spring apportaient de la lisibilité et de la robustesse au code.

Denis Peyrusaubes est ensuite revenu sur les pièges de Spring, notamment une utilisation extrème de l'IoC qui peut être néfaste à la compréhension du système : l'IoC reste censé pour la gestion des dépendances entre les couches architecturales d'une application.
Il a également recommandé de ne pas oublier que compte-tenu de la nature de Spring, la maîtrise du (des) framework(s) sous-jacent(s) restait indispensable.

Enfin, il a rappelé que Spring était un framework très structurant, qu'il était un standard de fait, mais non normalisé.
Alors que Spring doit une partie de son salut à la complexité des EJB 2, ce sont les EJB 3 et leur caractère normalisé qui pourraient peu à peu faire de l'ombre à Spring. L'avenir nous le dira.

Présentation agréable, bien que ciblant plutôt un public débutant.
Quelques rappels ne font néanmoins pas de mal, notamment face à l'évangélisation de Spring.

• Le site de Spring
• La FAQ Spring
• Le forum Spring

Jean-Michel Legrand, consultant chez Valtech Technology, a commencé par présenter la problématique de fonctionnement d'un projet distribué - comprendre géographiquement parlant.
Il a notamment souligné les objectifs et points critiques de tels projets, à savoir une visibilité en continu entre les différents sites, ainsi qu'une partage d'artefacts (code, documentation, etc.).

En s'appuyant sur des constats concernant le suivi de la documentation, des indicateurs et de l'avancement, mais aussi du coût, il a présenté l'initiative Valtech Cockpit mis en place pour les projets réalisés à Valtech India avec la méthodologie Scrum.

Valtech Cockpit est constitué d'un ensemble d'outils open source regroupés sous la forme d'un portail / application web, le tout étant extensible et configurable.

• Confluence pour la documentation à la mode wiki
• JIRA pour la planification et le tracking (un pour le Product Backlog, un autre pour l'Iteration Backlog)
• CVS pour la gestion de configuration

Valtech Cockpit s'intègre également à une utilisation du plugin Mylyn dans Eclipse pour la gestion des tâches.

Via l'utilisation de Valtech Cockpit, les équipes paraissent davantage impliquées, n'éprouvent aucune difficulté à renseigner régulièrement leur avancement, simplement car la plateforme est facile d'accès et sans contrainte (contrairement à un fichier Excel qu'il faudrait remplir).
Les managers peuvent quant à eux directement accéder aux tableaux de bord et les partager avec leurs équipes.

Valtech Cockpit est un projet interne Valtech, mais Valtech ne semble pas exclure de le mettre à disposition au cas par cas.
Une fois le portail en place, un nouveau projet peut se créer en un simple clic.
Valtech Cockpit n'est pas dépendant de la technologie employée sur le projet qui souhaite l'utiliser, et permet de réduire l'intervention humaine qui peut s'avérer très coûteuse dans le cadre de projets distribués.

Le projet devrait à l'avenir intégré un SSO LDAP, ainsi que des métriques de qualité.

C'est un bel exemple d'adaptation des outils et non des hommes dans un contexte offshore, qui peut très bien également trouver sa place sur des projets non nécessairement distribués, mais constitué d'une équipe d'une certaine taille.

• Confluence
• JIRA
• Valtech Cockpit

Eric Lefèvre, en charge de l'Open Space Technology, a réuni l'ensemble des participants dans une salle.
Il est revenu sur la journée passée et nous a expliqué le fonctionnement de la journée.

Au cours de la première journée, des panneaux et post-its étaient disponibles près des salles, permettant à chacun de proposer un sujet qui l'intéresse.
Force est de constater que les panneaux étaient déjà bien remplis au soir de cette première journée, et la tendance à une préférence au thème de l'agilité se confirmait.

Nous avons donc constitué des groupes d'une dizaine de personnes pour nous présenter et échanger entre nous sur ce que nous attendions de cette journée.
Puis vint le moment de proposer les sujets du jour en essayant de les répartir sur la journée et les salles disponibles : ce fût donc un défilé de participants qui annonçaient un sujet au micro puis en collaient un post-it (de la veille, ou nouveau) sur le panneau faisant office de planning.
Puis chaque participant est venu marquer d'un point les sujets qui l'intéressaient, et les dépositaires des post-its réorganisaient le planning en tenant compte des autres sujets (regroupements, échanges de salle ou d'horaire en fonction de la popularité des sujets).

Le planning de la journée était fait, il pouvait cependant évoluer au cours de la journée en cas de nouveaux thèmes ou de réorganisation.

• XWiki par la pratique
• Intégration Continue
• Réticences à l'agilité et arguments en faveur des projets agiles
• Caractéristiques d'un bon profil agile

Vincent Massol, CTO d'XWiki, était présent cette seconde journée pour sortir du cadre d'une présentation et répondre en pratique aux interrogations des participants.
Il nous a notamment présenté le scripting avec Velocity (Groovy est également supporté), l'éditeur de classe et la simplicité de construction d'un formulaire (le tout en ligne évidemment).
Il a également évoqué les 2 plugins de recherche dont dispose XWiki : Hibernate et Lucene, et nous a montré le plugin Eclipse qui via des appels XML / RPC permet de consulter le portail et de le modifier dans Eclipse (y compris dans un mode déconnecté).

Parmi les informations saisies au vol, on apprend que toutes les images sont stockées en base de données, qu'XWiki est optimisé en matière de montée en charge en s'appuyant sur 2 caches : un cache de document, un cache de rendu.
Vincent Massol nous a également parlé du futur et notamment d'XWikiWatch qui est un agrégateur RSS collaboratif principalement destiné aux entreprises dans le cadre de la veille.
Il a également évoqué une intégration de GWT à venir pour la gestion du texte enrichi.

• XWiki.org
• XWiki
• La présentation XWiki de la première journée
• Créer un site associatif avec XWiki

A l'origine, la proposition d'Eric Lefèvre ciblait une présentation d'Hudson.
Néanmoins, un certain nombre de personne était demandeur sur d'autres thèmes comme Maven, Continuum, et d'autres produits touchant à l'intégration continue.

Eric Lefèvre a donc proposé un tour de table afin de faire ressortir les sous-thèmes les plus prisés pour se concentrer sur ceux-ci.
Nous en sommes donc restés à Hudson et à Maven 2.

Sur le thème Hudson, on apprend que le développeur de Sun est très actif / réactif, que l'application se présente sous la forme d'un .war qu'on peut lancer via la commande java -jar ou déployer dans Tomcat par exemple.
La page principale listant les différents Jobs est très sobre et permet de lancer manuellement un build, et de voir d'un coup d'oeil ce qui se passe (build en cours, état des builds, durée, dernier lancement, etc.).
En terme de fonctionnalités, Hudson est simple à manier même s'il ne dispose pas de fonctionnalités évoluées que des outils comme Cruise Control peuvent proposer.
On apprend notamment que Hudson est à l'origine pensé pour ANT, mais qu'il supporte Maven 2 ainsi que des déclarations plus libres (Shell par exemple).
Hudson permet de schéduler un build à une fréquence donnée, en tenant compte ou non de l'existence de modifications depuis le précédent build (auquel cas le build n'est pas fait).
Il est également possible de gérer des dépendances au niveau d'un build : les builds prérequis, des actions à mener post-évènement, etc.

Hudson permet de tenir compte de différentes configurations : on peut donc par exemple envisager deux configurations différentes en jouant sur le JDK.
De plus, Hudson permet des builds distribués, d'une part pour répartir la charge, mais aussi pour gérer des configurations reposant sur le système d'exploitation.
A noter également que contrairement à Continuum, Hudson refait un checkout complet à chaque build, ce qui permet de minimiser les risques de parasitage et n'est certainement pas bien pénalisant.
Enfin, il faut savoir qu'Hudson gère toutes les informations dans des fichiers plats stockés sur le système de fichiers.

Sur le thème Maven, ce fût l'occasion pour certains de découvrir les grands principes de l'outil et du fameux pom.xml. En effet, beaucoup de personnes utilisent encore ANT.
Parmi les points intéressants discutés figure la gestion des dépendances, et notamment des versions des différentes librairies requises sur le projet. Ce fût l'occasion de montrer la valeur ajoutée de Maven en la matière, permettant de rationaliser la déclaration des librairies et de s'assurer que tous les acteurs du projet disposent bien des mêmes versions de ces librairies.
Sur le thème de la gestion des librairies, beaucoup de personnes semblent avoir rencontré des difficultés à mettre en place un proxy d'entreprise. Seul Artifactory a été mentionné comme retour positif.
Eric Lefèvre nous a également montré comment se présentait un site Maven et comment il se générait, ainsi que quelques plugins de base, comme la génération de la JavaDoc.

Parmi les discussions transverses, on notera également quelques demandes sur des technologies autres que Java : on retiendra notamment qu'Hudson peut être utilisé pour d'autre technologie, en recourant à la configuration de scripts shell / bat au niveau de la définition des Jobs, ainsi que l'existence de variantes de CruiseControl pour DotNet et Ruby.
Côté build et projets Eclipse, quelqu'un a également évoqué Buckminster, mais personne n'avait de retour d'expérience.
Petite anecdote également sur les 2 plugins SVN disponible pour Eclipse : Subclipse et Subversive qui se sont menés une petite guerre, avec Subversive qui semble avoir pris le dessus en étant désormais un projet dans l'incubateur Eclipse.
Enfin, certaines personnes ont relevé qu'Eclipse 3.3 permettait désormais de définir un reformatage automatique avant commit sur le SCM, et se posaient donc la question de l'existance d'outils tiers permettant de faire ce genre d'opération avant commit (on peut penser par exemple à Jalopy) et comment cela pouvait se mettre en place de manière transparente (je ne sais pas si finalement une réponse claire et concrète a pu être donnée).

• Le site d'Hudson
• Le site de Maven
• Introduction à Maven 2
• La FAQ Maven 2
• Le forum Maven

Cette session avait pour but de permettre aux participants souhaitant imposer les méthodes agiles de faire part des difficultés qu'ils rencontraient, et de donner la parole à ceux exerçant des méthodes agiles pour donner les conseils / démarches permettant de convaincre les décideurs.

En terme de constat, les réticences à la mise en place de méthodologies agiles se trouvent parmi :

• un problème culturel
• Les très grandes SSII observent encore, et attendent pour minimiser les risques, mais elles y passeront une fois qu'elles considéreront les méthodes agiles comme éprouvées
• La contractualisation peut poser problème, car cela fragilise l'obligation de résultat
• Nécessite une implication plus forte du client, notamment en matière de fréquence
• Nécessite des équipes polyvalentes
• La peur de se dévoiler (le client va voir qu'on est en retard)
• Les bénéfices ne sont pas visibles immédiatement
• Le client doit prendre davantage de risques, pourquoi accepterait-il ?

• Une première étape pour un passage progressif vers les méthodes agiles peut se focaliser sur la mise en place de mesure et d'indicateurs sur les projets existant, afin de mettre en évidence les points à améliorer
• Des mesures comme celles de Scrum s'adaptent très bien à CMMI
• Les bénéfices des méthodes agiles sont visibles à 2 - 3 ans
• L'agilité n'enlève en rien la nécessité de gérer les évolutions / changement et d'arbitrer
• Tout le monde est capable de réaliser la plupart des tâches, le risque de perte de savoir lié au turnover est réduit

On relèvera également la distinction nécessaire entre l'approche itérative et l'agilité.
Ces deux approches sont complémentaires, mais il ne faut pas systématiquement associer l'approche itérative à l'agilité. La pratique des itérations est bien plus ancienne et se résume à un découpage permettant de réaliser une application en plusieurs étapes et de se reposer sur les premières étapes pour construire les suivantes. Parmi les grands principes de l'agilité, complémentaires à l'approche itérative, se trouvent la volonté d'aller à l'essentiel en priorisant les fonctionnalités les plus nécessaires à l'utilisateur, ainsi que l'approche qualitative reposant sur des échanges réguliers et des mises à disposition d'application fréquentes.

Parmi les choses séduisantes, on notera également l'analogie évoquée avec la construction d'une maison : le propriétaire souhaite suivre régulièrement les avancées et avoir son mot à dire, il n'a pas en général envie d'attendre la livraison de la maison pour se rendre compte qu'on l'a mal compris et que ce n'est pas la maison de ses rêves.
Nul doute également, que le futur propriétaire de la maison prendra ses responsabilités s'il se rend compte que quelque chose ne lui plait pas et qu'il souhaite que certaines choses soient revues.

Cette dernière session regroupait des questionnements sur le recrutement de profils agiles, les qualités d'un profil agiles, les arguments pour attirer un profil agile, l'homme au sein d'un projet agile, ce qu'est un profil non-agile, etc.

Pour se recentrer sur l'un de ces thèmes, Eric Lefèvre a demandé à chaque participant de noter sur un post-it en forme de flèche le numéro du thème qu'il souhaitait aborder en priorité.
Une fois que tout le monde avait fait son choix, chacun est allée reporter sa flèche sur la liste des sujets, et le choix était fait (sans que personne ne soit influencé).

Nous avons donc traité la question des caractéristiques d'un bon profil agile.
Là aussi, grâce à l'animation d'Eric Lefèvre, chacun a noté sur un ou plusieurs post-its hexagone ce qu'il pensait être la ou les qualités d'un profil agile.
Puis nous avons regroupé le tout dans un grand hexagone fixé au mur, avant de réorganiser le tout pour réaliser des regroupements.

• adaptation, polyvalence
• honnêteté, esprit d'équipe
• ouverture d'esprit, grande culture technique
• critique, y compris envers lui même, force de proposition
• inventivité, partage
• est courageux
• ...

Retrouvez les notes de la session ainsi que les illustrations sur le Wiki de l'évènement.

Le débriefing aurait du se faire avec l'ensemble des participants et comprendre une restitution des différentes sessions, mais étant donné que les autres sessions avaient fini avant celle sur les qualités d'un profil agile, bon nombre de participants étaient déjà partis.
Nous avons donc été quelques uns à témoigner de notre ressenti sur ces 2 journées. On retiendra la satisfaction générale, avec notamment les échanges de la seconde journée, son interactivité, la liberté qu'avaient les participants en naviguant au gré de leur ressenti dans les sessions, des gens qui à la fois apportent et reçoivent, une très bonne organisation.
Certains ont conseillé certains aménagement côté organisation de la seconde journée, en particulier une constitution des sujets la veille et une animation plus homogène. En effet, le constat a été fait qu'il n'y avait pas toujours un facilitateur pour chacune des sessions de l'Open Space Technology, c'est à dire quelqu'un qui aide à structurer la session sans pour autant en être le principal orateur.
Enfin, certaines personnes ayant découvert le principe du forum ouvert ont regretté de ne pas avoir osé / pensé amener du matériel pour eux mêmes apporter des éléments concrets aux sessions.