Soutenez-nous

Compte rendu des Valtech Days 2007

Valtech a organisé les 23 et 24 octobre 2007 sa seconde édition des Valtech Days. Ce fût l'occasion lors de la seconde journée d'assister à un forum ouvert (Open Space Technology), une première (de cette ampleur) en France d'après les organisateurs. Avec plus de 300 participants (soit une augmentation de 40% par rapport à l'an passé), l'évènement a eu un franc succès.

Article lu   fois.

L'auteur

Site personnel

Liens sociaux

Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Share on Google+ 

1. Présentation

L'inscription de 150 € HT pour ces 2 journées n'est finalement qu'une formalité pour ceux qui veulent investir une ou deux journées dans la veille technologique.
Avec quelques intervenants de renom, ainsi que des formateurs aguerris, la qualité des discussions ne pouvait qu'être au rendez-vous.

On citera notamment parmi les plus connus : Ludovic Dubost et Vincent Massol (XWiki), Pascal Roques (Guru UML), Régis Médina (Design-up), etc.

1.1. Logistique

L'évènement a eu lieu à Paris Expo - Coeur Défense (Paris - La Défense) dans des salles adaptées à ce genre de manifestation. Compte tenu de l'affluence, certaines salles se sont avérées trop petites lorsqu'une session était très attendue (Notamment la session animée par Régis Medina sur le Refactoring, ainsi que celle animée par Denis Peyrusaubes sur Spring).

Le petit déjeuner était offert et des points d'eau étaient disséminés près des salles de conférence. Sur les 2 journées, un déjeuner copieux et diversifié en libre service était offert

1.2. Les goodies

Lors de son arrivée, tout participant s'est vu remettre un sac Valtech Training, aux couleurs de nos hôtes.

Dans ce sac, on peut notamment trouver :
  • un stylo Valtech Training
  • un bloc note
  • le programme de la journée
  • un tapis de souris Valtech Training
  • le livre "Approches pragmatiques pour industrialiser le développement d'applications (co-écrit pas Jean-Louis Bénard - Brainsonic - et François Mérand - Microsoft)
  • les plaquettes de certains partenaires (Leirios, Microsoft, Adobe, Quest Software, Agitar Software, Rally Software)
  • le catalogue des formations Valtech Training

Sur les stands aménagés dans l'allée, le participant avait également l'occasion de se servir parmi les nombreuses balles anti-stress à l'effigie de Valtech, mais également d'emporter un t-shirt Valtech Days à sa mesure.

Quelques partenaires occupaient un stand, et notamment Microsoft qui mettait en jeu un écran plat.

2. Le programme

A chaque journée sa thématique :
  • le mardi : 24 sessions réparties sur 6 créneaux
  • le mercredi : un forum ouvert - Open Space Technology - lors duquel les participants ont été libres de faire le programme eux mêmes en faisant émerger les sujets de discussion les plus prisés

2.1. Les thèmes

Le thème de l'industrialisation regroupait des présentations assez variées telles XWiki, Team System, les tests, etc.

Le thème de l'architecture était quant à lui couvert par des présentations orientées technologie (SOA, RIA, Web, XForms) et produits (Spring, Abobe Flex, JBoss Seam, Google Maps).

Enfin, le thème le plus prisé, celui de l'agilité - vaste sujet. Au programme : méthodologie (UML ?, Offshore), mise en oeuvre de concepts agiles (DSL, TDR, Refactoring, binomage), gestion du changement, etc.

2.2. Les sessions

Pour ma part, j'ai eu pour chaque créneau un choix difficile à faire entre au moins 2 sessions.
Aucune excuse cependant, le planning était disponible bien avant la journée, il fallait donc se décider.

2.2.1. UML est-il soluble dans les méthodologies agiles ?

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.

Quelques liens :

2.2.2. Maintenir la qualité de service de vos applications JEE

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.

2.2.3. Simplifiez vos développements J2EE avec JBoss Seam

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.

Quelques liens :

2.2.4. De 'Fragile' à 'Agile'

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.

Quelques liens :

2.2.5. Spring, le framework à « tout » faire ?

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.

Quelques liens :

2.2.6. Valtech Cockpit, une plateforme intégrée pour projets distribués

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.

Quelques liens :

2.3. L'Open Space Technology

Première en France d'après les organisateurs, l'Open Space Technology - encore appelé Forum Ouvert en français - est une sorte de foire aux sujets : les participants construisent ensemble le programme de la journée et en sont acteurs par la suite.

Image non disponible

Environ 150 personnes étaient présentes pour cette seconde journée (la baisse était prévisible, mais cela constitue une très bonne affluence) et pour la plupart plein d'attentes, et pour certains plein de choses à partager.

2.3.1. Organisation et constitution du planning de la journée

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).

Image non disponible
un morceau du planning

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.

Pour ma part, le choix n'a pas été simple, mais j'ai retenu les sessions suivantes :
  • 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

2.3.2. XWiki par la pratique

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.

Quelques liens :
Image non disponible

2.3.3. Intégration Continue

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).

Quelques liens :

2.3.4. Réticences à l'agilité et arguments en faveur des projets agiles

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 ?
Quelques éléments de réponse
  • 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.

2.3.5. Caractéristiques d'un bon profil agile

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.

Quelques conclusions sur les qualités d'un profil agile :
  • 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
  • ...
Image non disponible
La technique des hexagones appliquée au thème du bon profil agile

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

2.3.6. Débriefing

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.

3. Conclusion et remerciements

Un évènement très agréable à suivre, bien organisé et riche en contenu.
Le contenu n'était pas exclusivement réservé à une technologie donnée, même si la part de Java était prépondérante.
Le thème de l'agilité est bien plus large et, même si la majorité des illustrations technologiques reposent sur des outils Java, ne se limite pas à telle ou telle technologie.

Un bon choix pour mener sa veille technologique.

Je remercie les organisateurs pour nous avoir proposé cet évènement, en particulier Laetitia Huard, Jocelyn Thielois, Eric Lefèvre, ainsi que tous les animateurs et facilitateurs.

Merci également à RideKick pour sa relecture attentive.

Toutes les photos illustrant ce compte-rendu sont extraites de Flickr, tous droits réservés à leurs auteurs.

4. Liens

Articles et tutoriels Borland C++ Builder
Accédez à une base de données Access avec les composants du BDE
Guide d'installation de la RxLib sous BCB 6
Présentation et utilisation du plugin borCVS pour Borland C++ Builder 6
Articles et tutoriels Java
Présentation de l'API Reflection
Gestion d'images en base de données avec l'API JDBC
Interview et reportages
Compte rendu des conférences JAX 2006, Eclipse Forum Europe 2006, EAKon 2006
Interview d'Eric Lefevre, consultant chez Valtech, au sujet de l'Open Space Technology
Compte rendu des Valtech Days 2007
Autres articles et tutoriels
Introduction à CVS
Présentation du langage NICE
Critiques de livres
Jakarta Struts Par la pratique (Eyrolles)
Initiation à JSP (Eyrolles)
Gestion de projets avec Subversion (O'Reilly)
Struts - Les bonnes pratiques pour des développements web réussis (Dunod)
Hibernate 3.0 : Gestion optimale de la persistance dans les applications Java/J2EE (Eyrolles)
Analyse et conception orientées objet - Tête la première (O'Reilly)
Gestion de projet eXtreme Programming (Eyrolles)
Gestion de projet - vers les méthodes agiles (Eyrolles)
Autres liens sur Developpez.com
La FAQ C++ Builder
Les Sources C++ Builder
Les FAQs JAVA
  

Copyright © 2007 Ricky81 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.