Retours sur le RivieraJug

En vacances dans le var, j'ai fait un détour à Sophia Antipolis pour assister à la 4ème session du RivieraJug dans les locaux de Amadeus.

La première présentation était sur scrum. Le speaker polonais était très tranchant dans ses réponses. Ce processus de développement me plait bien mais il casse un peu les habitudes mais cela à pour conséquence de mal passer auprès des organisations actuelles. J'ai aussi apprécié la citation "Managers don't feel good with scrum ... may be it's because scrum is transparent" (Les managers n'apprécient pas scrum ... peut être que c'est parce que scrum est transparent), le meilleur exemple est celui des réunions quotidiennes ou seule l'équipe de développement est autorisé à parler. Cela change énormément du mode chef de projet qui re-sauce un peut les faits pour avoir une marge de jours pour les corrections post livraisons.

En résumé de ce que j'ai compris, Scrum c'est :

• Un product owner qui s'occupe de recueillir les exigences et de les prioriser (et les changements d'exigence, dans le process le client a le droit de changer d'avis - cela correspond beaucoup plus à la réalité qu'un projet classique).
• Le scrum master, qui joue le rôle de facilitateur pour que le process soit fluide (ie un chef de projet qui ne fait pas de planning ou de fliquage mais ajoute de la valeur ajoutée en s'assurant que l'ensemble du process de développement tourne.
• Une équipe de développement de 2 à 7 membres dont chacun doit prendre les connaissances métiers techniques pour ne pas dépendre d'un départ d'un autre membre de l'équipe.
• Une vélocité (vitesse d'avancement) qui permet de mesurer le nombre d'éxigences réalisées par sprint. Cela permettra de faire un minimum de planification au fur et à mesure de l'avancement du projet.
  

La suite est sur les slides.

A voir si le processus est applicable à du développement EAI/ESB ou 70% du travail et des retards sont au niveau des contrats d'interfaces (spécifications). En tout cas pour un projet du type Driveo, c'est le processus que j'utiliserais à partir d'une équipe de 3/4 personnes.

La deuxième présentation sur Groovy m'a un peu déçu, le speaker a souhaité entrer dans les entrailles du code plutôt que de montrer à quoi groovy pouvait servir.

Pour conclure, dommage que le buffet fut court et pas très régional (au normandyjug il y avait du camembert, du cidre, des rillettes, etc... ;-).

Lectures de vacances : rattrapage sur l'architecture de solutions Java avec Rod Johnson

Suite aux conseils d'un indépendant J2EE, afin de compléter d'une part mes compétences d'architecte SOA chez Logica et d'autre part la partie serveur pour Driveo et Fermiers d'à côté, j'ai inclus les 2 livres de Rod Johnson (un des concepteurs de Spring) dans mes lectures de vacances.

Les 2 livres "Wrox / expert one-on-one" sont intitulés :

• Expert One-On-One J2Ee Design and Development
  
• Expert One-on-One J2EE Development without EJB
  
  

Si les 2 livres commencent à dater, il en reste au moins 70% de toujours valable. Le premier livre (2002/2003) prend sa source dans les difficultés des projets J2EE à base d'EJB de l'époque. Le deuxième livre sonne la fin des EJBs 2 et annonce les débuts prometteurs du framework Spring.

Il faut savoir que je ne suis pas un fan des EJBs. Je me souviens avoir squizzé des EJBs dans une couche de l'architecture pour gagner en performance et en productivité (le forfait était très fortement dans le rouge...).
De plus, j'utilise Spring pour Driveo et Fermiers d'à côté et le framework me le rend bien en terme de productivité.

Il faut dire que l'aspect pragmatique et l'orientation vers la recouvrance d'objectif métiers de Rod Johnson rejoint très bien l'évolution de ma vision de l'architecture d'un système d'information. Enfin, son combat contre les ayatollah de l'informatique me ravi.

Pour illustrer le propos, voici quelques reprises re-mixées à la Youen des 2 livres :

• L'approche UML/Génération de code n'as pas d'intérêt en terme de productivité. Cela reste une utopie (et ce n'est mon expérience qui va me dire le contraire). Par contre l'UML reste le meilleure langage d'analyse de la conception d'une application.
  
  
• Les DTO ne servent à rien et ne font que rajouter de la complexité à la communication entre les couches d'une application (DTO= object d'échange entre 2 couches d'une application). Pour Fermiers d'à côté, j'ai presque fini de migrer vers une version sans DTO. Pour Driveo, j'ai commencé sans DTO je n'ai aucun regret.
  Remarque Architecte SOA: ceçi n'est pas valable dans l'urbanisation d'un SI avec un ESB/EAI (avec en plus beaucoup de mode asynchrone). Les DTOs/Objets Pivots permettent un découplage fonctionnel très utile en terme de souplesse, de maintenance et d'évolution.
  
  
• Rod Johnson fournit enfin un discours cohérent sur le choix d'utiliser ou non les procédures stockées.Il faut dire que j'ai entendu tout et son contraire sur ce sujet. En voici les grandes lignes :


• Il est intéressant d'y placer une logique de persistence pour des raisons de performance et de simplicité. Ex: un éléments avec des sous éléments.
  
• Cela ne pose pas forcément un problème de sécurité. La couche de sécurité devant se trouver au dessus de la couche métier.
• Cela ne réduira forcément le volume de données nécessaire pour que la base de données soit le goulot d'étranglement.
  
• De plus cela permet :
  
  • De mettre à jour plusieurs bases de données depuis une seule procédure stockée.
    
  • On limite le nombre d'appel parle réseau entre la base de données et le serveur d'application Java.
    
  • On peut optimiser localement avec du code propre à la base de données.
    
  • Cela permet de simplifier le code java en cachant de la complexité au niveau de la persistance.
  • On peut réutiliser un historique.

Enfin, Rod Johnson reste mesuré dans ces propos. Il souhaite éviter les positions de types procédures stockées interdits ou obligatoires. Il faut s'adapter au contexte.


• Les TDDs est la meilleure approche d'amélioration continue dans le développement d'applications. Le gain est énorme en terme de qualité de livrable et en maintenance. Mon "bon sens" d'ingénieur Arts et Métiers (j'en ai mangé des cours de méthodes et d'amélioration continue pour les lignes d'assemblage mécaniques) me dit qu'une approche TDD apportera de bien meilleurs résultats qu'un chef de projet ceinture noir en CMMI (On peut sans doute dire que je mélange les torchons et les serviettes mais d'un point de vue décideurs/productiviste on atteint le même objectif : réussir et optimiser la réalisation d'applications informatiques de manière répétée).
  Remarque Architecte SOA : dommage que dans le monde des ESB (TIbco, Web Method) on soit très mal outillé sur ce point.
  

Du coup, j'ai re-priorisé ma roadmap de consolidation :

1. Construction des test unitaires avec JUnit (afin de diminuer les non régressions sur les nouvelles versions de Driveo) pour passer vers un mode full TDD.
   
2. Migration complète vers spring 2.5 (diminution du code avec les annotations, gestion des transactions, ouverture plus facile de services pour la construction du back office).
3. Tuning (cache, recherche compass/lucene).
   
4. Migration de ant vers maven afin de se brancher vers un système d'intégration continu (Hudson) et automatiser la compilation, les tests, le packaging.
5. Evaluation d'une migration de Ibatis vers Hibernate ou JDO. (Ca tombe bien tout est isolé dans une couche de DAOs).
   

Du travail pour mon retour de vacances ! (En plus des nouvelles fonctionnalités et du développement commercial de Driveo).