Je fais suite  à mon premier billet concernant l’Agile Tour 2011 pour vous faire part cette fois des conférences auxquelles j’ai assisté l’après-midi.

Améliorez l’efficacité de vos cérémonies agiles

Suite à la formation que j’ai suivi sur SCRUM, il m’avait paru que les différentes réunions n’étaient pas forcément évidentes à mener étant donné que chaque membre de l’équipe peut donner son avis. 7 à 10 personnes qui émettent chacune leur opinion pour à la fin prendre une décisionn,  cela ne doit pas être évident dans la vraie vie. J’ai donc décidé de suivre cette conférence qui devait me donner une partie des réponses à mes questions.

L’oratrice est une Coach (encore une) et certifiée SCRUM Master. Elle accompagne ou a accompagnée, depuis 15 ans, plusieurs équipes en phase de transition vers SCRUM. Tout au long de son discours, elle insiste sur la dimension humaine liée à la bonne gestion des cérémonies agiles. L’agilité nécessite un comportement et une façon d’être spécifique. Pour que tout se passe bien, il faut être ++ comme elle dit. ++ veut dire qu’on est soit même dans une idée plutôt positive de nous-même et avec les autres. On peut alors être constructif pendant la cérémonie agile puisqu’on est dans un pied d’égalité avec les autres membres de l’équipe. On est en phase de collaboration. Dans le cas contraire, la réunion ne pourra être constructive puisque les interactions entre nous et les autres membres de l’équipe seront parasytées par du négativisme (on se sent supérieur aux autres ou inférieur, on sent qu’on n’a pas notre place dans l’équipe).

Conduite du changement et gestion de conflits

Cette conférence est liée à la précédente toujours dans cette esprit des difficultés rencontrées par les équipes agiles. Cependant, l’oratrice, psychologue clinicienne, apparemment débutante dans la prise de parole en présence d’un public assez nombreux n’était pas vraiment à l’aise. Elle n’a fait que lire son support de présentation. On n’entendait parler de gestion de conflits, de stress mais cette lecture assez monotone  a complètement anihilé la conférence. Du coup, j’en ai pas retenu grand chose malheureusement. 45 minutes très longues en pure perte…

Ni Gladiateurs ni Bisounours – une équipe remarquable au quotidien

Avec la première conférence de l’après-midi, celle-ci était sans doute la meilleure de cette deuxième partie de journée. L’orateur, Christophe Thibaut, est un consultant senior ayant 20 ans d’expérience en développement et direction de projets. Il sait bien de quoi il parle et est plutôt très pragmatique.

Lors de cette session, il nous parle de la vie d’une équipe de développement en mode agile avec un focus sur les problèmes rencontrés dans ce mode de fonctionnement. Un des éléments qui revient souvent, et c’est le cas dans n’importe quelle équipe, est la gestion des conflits. Le problème dans l’agilité c’est que cela peut perdre un temps certain et créer une dynamique dans l’équipe très négative. En effet, l’efficacité d’une équipe agile réside dans la communication entre ses membres. Un conflit mal géré aboutit toujours à des blocages entre certains membres de l’équipe. Les interactions ne se font plus et l’équipe aura alors beaucoup de mal à s’autogérer et livrer dans les temps.

Christophe nous donne ainsi quelques élements pour éviter que les conflits fragilise une équipe agile. L’un des plus intéressants aspects de cette session fut alors la découverte des « core protocols » de communication. Je dis intéressant mais je ne l’utiliserais pas forcément dans la vie de tous les jours même en milieu professionnel. Pour ceux qui, comme moi, ne connaissent pas les « core protocols » c’est en fait un moyen de gérer la communication au sein d’une équipe à l’aide d’un protocole. Déjà pour moi, c’est pas l’idéal, s’il faut un protocole pour communiquer avec mon équipe c’est qu’il y a déjà un problème. Bref, ce n’est que mon point de vue après ce qui est important c’est la finalité des core protocols. Ils nous montrent qu’il est important dans une équipe que chacun de ses membres puissent indiquer à un autre membre que ce qu’il fait est bien ou pas bien, qu’une personne peut avoir envie de faire une pause, de faire autre chose, de demander de l’aide, etc…

Les core protocols permettent cela grâce à des mots clés. Je vais vous présenter dans la suite quelques exemples choisis par l’orateur.

Check in

C’est le mot clé qui est utilisé pour « entrer » dans l’équipe. Son utilisation indique aux autres membres de l’équipe que la personne est bien présente et motivée pour travailler sur ses tâches. Quand on arrive le matin, par exemple, la personne dit:

• Check in
• Je suis content d’arriver au boulot
• Je suis content parce que j’ai trouvé dans la nuit la solution à mon problème d’hier
• Je suis énervé car j’ai passé 2 heures dans les bouchons

L’équipe répond alors: Bienvenue!

Ask for help

Ce core protocol, comme son nom l’indique, est utilisé lorsqu’une personne de l’équipe a besoin d’aide. La personne dit alors:

• Quelqu’un peut m’aider j’ai un problème avec un bug que je n’arrive ps à résoudre depuis deux jours ?

Le membre de l’équipe qui le souhaite peut répondre alors oui et prendre le temps d’aider la personne qui a demandé de l’aide.

Check out

Sans justification, ce core protocol peut être utilisé par n’importe quel membre de l’équipe pour « sortir » de l’équipe. Un membre de l’équipe est fatigué, énervé de travailler sur la même tâche depuis 2 jours sans arriver à une solution, ne peut pas tenir ses engagement, etc… Il dit alors:

• Check out

Il va alors prendre une pause, boire un café et revient plus tard ou il rentre chez lui.

J’en ai présenté que trois mais il existe beaucoup d’autres core protocols comme Perfection Game, Pass, Protocol chec, Intention Check. L’avantage avec les core protocols c’est qu’ils forcent les membres d’une équipe à se parler et surtout à se dire ce qui va ou va pas. Ils nous apprennent qu’il est important de :

• faire des retours positifs à quelqu’un ainsi que des négatifs,
• de demander de l’aide à l’équipe,
• de faire une pause quand on arrive plus à avancer,
• …

Cependant, à mon sens, leur utilisation rends l’individu proche d’une machine. De plus, ils aboutissent à des contraintes puisqu’on est obligé de les utiliser lorsqu’ils sont mis en place dans une équipe. Cela déshumanise les individus sans oublier le fait que vu de l’extérieur les autres personnes doivent prendre les membres de ce genre d’équipe pour des fous ou des membres d’une secte. En tout cas, c’était intéressant de savoir que ce genre de moyen existe.

Les frontières de l’équipe

L’orateur, un consultant de SFEIR, a commencé sa conférence par un petit jeu basé sur les fameux oeufs en chocolat Kinder. Il a partagé 6 personnes du public en deux équipes de 3 avec chacune 3 oeufs. La première, spécialisée sur une tâche, s’est organisée en une personne qui devait sortir l’oeuf de son papier alluminium, la seconde devait manger tous les chocolats et la dernière était spécialisée dans la réalisation de la Kinder surprise. La seconde équipe elle multi-disciplinaire dont chaque membre devait faire les 3 étapes d’affiler avec son oeuf. Bien sûr, c’est l’équipe multi-disciplinaire qui l’a emporté. L’orateur en conclut par l’efficacité en agile d’équipe multi-disciplinaire.

Pour la suite, se fut en résumé, une nouvelle formation à SCRUM avec des illustrations basées sur la bande-dessinée Asterix. Une équipe d’irréductible, les agiles, représentée par le village gaulois au milieu de tous les autres (PO, client, équipes non agiles, …) que sont les différents camps retranchés romains.

Une session qui ne m’a pas vraiment laissée d’éléments instructifs.

Conclusion

Malgré certaines sessions très peu intéressantes, j’ai quand même eu beaucoup de retours intéressants sur l’utilisation de l’agilité dans le milieu professionnel. J’ai pu voir les difficultés rencontrées par les équipes agiles et surtout les moyens de les atténuer au maximum. En résumé, il n’est pas évident de mettre en place l’agilité mais, comme tout, l’important c’est d’adopter une attitude positive avec soi-même et les autres. Un élement important de l’agilité c’est qu’une équipe ne performe pas du jour au lendemain. Cela nécessite plusieurs mois de travail ensemble pour améliorer sans cesse les choses. Il est donc primordial, à mon sens, plus qu’avec des méthodes traditionnelles, que cette équipe ne soit pas dissoute après quelques mois. Cependant, l’agilité c’est aussi une façon d’être et de penser en équipe. Quelqu’un qui a une expérience dans l’agilité aura plus d’aisance à se réintégrer dans une nouvelle équipe agile puisqu’il aura, au moins, acquis l’état d’esprit agile. J’aurais aussi compris qu’au delà de l’équipe elle-même, le succès de la mise en oeuvre de l’agilité dans une entreprise est basé sur la confiance de ses dirigeants envers leurs équipes agiles.

Le 6 décembre dernier, j’ai participé à l’Agile Tour 2011 à Paris dans les locaux de Microsoft à Issy-les-Moulineaux. Après avoir suivi la formation SCRUM fin octobre, il était intéressant pour moi d’assister à des conférences autour de l’agilité. Je vais vous raconter le déroulement de ma journée et présenter les différentes sessions auxquelles j’ai assisté. Je le ferais en, au moins deux billets pour alléger la lecture (et que la lecture, pas les infos… ).

La plénière d’introduction

Cette journée, prévue pour être très riche en informations autour de l’agilité, a commencé par une récupération des badges et le programme de la journée. Un petit déjeuner est offert, histoire de donner à nos neurones de l’énergie pour suivre les différentes conférences. La première est une plénière d’introduction à l’agile tour. On nous y apprends que l’agile tour a commencé il y a quelques années à peine par quelques villes pour devenir aujourd’hui un évenement mondial organisé dans des disaines de villes des Etats-Unis à l’Australie en passant par le Canada, le Brésil, la France, la Chine, l’Inde, etc…

Il s’en suit une présentation brève des différents sponsors de l’évenement parmi lesquels Novédia. Il faut bien faire de la pub à tous ceux qui ont permis l’organisation de l’Agile Tour parisien.

La keynote de Martin Woodward

Suite à la plénière, Martin Woodward, Senior Program Manager de l’équipe Visual Studio, présente, en anglais (et se sera le seul),  comment Microsoft met en oeuvre l’agilité dans le développement de ces logiciels comme Visual Studio.

Martin nous parle de la valeur ajoutée liée à la mise en place de l’agilité. L’efficacité des équipes grâce à leur polyvalence. On y entend aussi parler d’intégration continue et de feedbacks réguliers. Deux principes qui permettent d’améliorer la qualité du logiciel chez Microsoft et la mise en oeuvre de nouvelles fonctionnalités.

La conférence est, plutôt, intéressante et animée. On voit bien que l’orateur est américain et habitué aux Key Notes.

Suite à la Key Note, les plénières sont terminées. Les conférences de l’Agile Tour 2011 qui suivent sont organisées en sessions de 45 mins ou 1h30. Il faut alors faire le choix entre 4 thèmes différents parmis les suivants:

• l’Agile en Entreprise
• la Qualité Logicielle & Test
• l’Equipe
• Ateliers / Idées de Coaching

Malheureusement, le programme récupéré en début de journée est très succint. On y voit que les titres des sessions. Le résumé du contenu de celles-ci n’étant disponible que sur le Web à cette adresse: http://at2011.agiletour.org/fr/programme_paris.html.
J’ai trouvé cela très léger pour choisir les conférences auxquelles on va assister. Bref, pour le reste de la journée, il faudra se baser sur le seul titre de la session pour se décider…

L’ALM agile, Facteur Clé de Succès des Projets Informatiques

Ma première session de 45 mins est celle-ci. Je ne sais pas ce qu’est l’ALM, encore moins agile. La notion de Facteur Clé de Succès des Projets Informatiques est plutôt pleine de promesses. J’y assiste dans le but d’en savoir plus.
L’orateur est un expert ALM. Il nous apprend que l’ALM est l’Application Lifecycle Management. En français, cela donne la gestion du cycle de vie d’une application. En résumé, c’est l’ensemble des phases d’un projet de développement, de l’analyse au déploiement en passant par le développement, bien sûr, les tests. Au cours de la session, l’orateur fait un focus sur Visual Studio Team Foundation qui intègre l’outillage nécessaire pour gérer ce cycle de vie pour des projets de développements agiles. Cela fait suite à la Keynote et c’est encore un peu de pub pour Microsoft. On est dans leurs locaux quand même…
On entends des mots qui sont des fondamentaux de l’agilité inscrits au Manifeste Agile comme:

• Livrez fréquemment un logiciel opérationnel
• Une attention continue à la qualité du Logiciel au travers des tests
• L’automatisation de processus comme la compilation, l’exécution des tests et le déploiement
• La transmission de l’information autour du projet avec des outils de communication partagés

Une démonstration des outils agiles intégrés à Visual Studio Team Foundation est faite. On voit, par exemple, comment gérer un Product Backlog, un Sprint Backlog, répartir les tâches entre développeurs, etc…
Une session plutôt intéressante même si tournée principallement sur les outils de Microsoft que je n’utilise jamais mais c’est toujours bon à savoir pour une prochaine discussion avec des développeurs .NET.

Améliorez votre Kanban!

Ne sachant pas ce qu’est un Kanban, j’assiste à cette session. L’orateur est un consultant agile de chez Octo, habitué à mettre en place l’agilité dans des équipes de développements.
Très rapidement, je sais, enfin, ce qu’est un Kanban. En fait, je connaissais déjà sans savoir ce que c’est comme beaucoup d’entre vous d’ailleurs j’imagine. Le Kanban est en fait le fameux tableau où l’on accroche les post-its avec les colonnes A Faire, En cours et Fait. Bon, ce tableau là c’est le Kanban le plus simple mais il en existe une infinité. D’ailleurs, l’orateur nouis propose de partir de ce Kanban et de l’améliorer afin d’obtenir un Kanban plus efficace et plus riche en informations. Venant du monde du développement, les informations sont très pragmatiques et rapidement opérationnelles.
Pour améliorer l’efficacité du Kanban, on nous conseille les élements suivants :

• positionner les fameuses User Stories plutôt que les tâches: pour accompagner ce positionnement, la définition du « Done » est très importante. Elle doit d’ailleurs être tenue à jour quelque part pas loin ou sur le Kanban lui-même.
• on peut ajouter des colonnes comme: En test, en pré-production, en qualification, etc…
• limiter le flux des User Stories à réaliser dans le A Faire: d’après l’orateur, il est inutile de charger le flux des User Stories à faire si l’équipe ne peut pas toutes les prendre en charge. Cela permet une meilleure fluidité et efficacité du déroulement des projets agiles.
• ajouter la ligne en or: elle permet de gérer des problèmes non prévus mais très urgent. L’exemple même est le bug en production. Cette ligne fera alors passer des tâches avant tout le reste.
• ajouter un bac rouge: il permet la récolte des User Stories qui ont posées problème pendant le projet. Il sert principallement au moment de la Rétrospective afin d’améliorer le Kanban, l’équipe, les process agiles mis en place.

Au cours de cette session, j’apprend que le Kanban est une méthode agile à part entière comme l’est SCRUM mais sans gestion de Sprints. J’ai vraiment appris pas mal de choses grâce à cette présentation même si le PPT était améliorable…

Kanban pour la préparation, SCRUM pour la réalisation

Pour continuer dans ma lancée « Kanbanienne » si je puis dire, j’assiste à la suite Kanban pour la préparation, SCRUM pour la réalisation. Le prochain orateur, SCRUM Master et Coach agile depuis 8 ans, nous fait un retour d’expérience sur la mise en place de l’agilité au PMU. Lorsque l’état a décidé de mettre en concurrence le marché du jeu, des entreprises historiques dans le domaine, comme le PMU, ont du évoluer afin de s’adapter aux nouvelles demandes de leurs clients. L’entreprise, assistée par un coach, a décidée de passer ces équipes à l’agilité.
Kanban a, alors, été utilisé dès l’initialisation du programme de refonte des applications en ligne du PMU. Il a permis aux équipes d’intégrer les principes agiles au plus tôt. L’orateur nous montre le Kanban qu’ils ont utilisé pendant la phase de préparation. Un Kanban plutôt complet. Il précise que pour la réalisation, ils sont partis de ce même Kanban sur lequel ils ont simplement changés le nom des différentes parties. La présentation et le retour d’expérience du coach agile nous montre clairement que l’agilité peut être introduite dans des équipes fonctionnant en mode traditionnel sur des programmes informatiques ambitieux. Les questions du public en fin de séance indique que cela n’est, certainement pas, sans problèmes. De gros efforts doivent être entrepris surtout par rapport au top management, non habitué à une telle organisation, qui est très inquiet par rapport à la réalisation concrète des projets. Il en ressort un élément très important de la réussite d’une mise en place de l’agilité qui est la relation de confiance obligatoire entre l’équipe et sa hiérarchie.

Ceci dis la livraison rapide d’un logiciel qui fonctionne permet de montrer l’efficacité de la méthode et incite le top management de croire en ce type d’organisation.

Suite à cette session, c’est la fin de matinée et donc la pause déjeuner. Un buffet complet nous est offert. Ouf, nul besoin d’aller chercher une sandwicherie autour de Microsoft où tout ou presque est plutôt loin. Comme cela a été le cas à chaque présentation, un grand merci aux sponsors!!

Dans un prochain billet, je raconterais la seconde partie de journée…

Voici la suite de nos aventures à la Devoxx 2011!

Ça y est, les partenaires ont envahi tout le rez-de-chaussée qui abritait le petit déjeuner gargantuesque du premier jour. Il y aura donc moins à manger… mais à la clé moults goodies, concours et autres t-shirts aux couleurs des sponsors de l’évènement. Et je dois dire que nous sommes revenus chargés de cette journée ! (dont un superbe mug HTML5 du plus bel effet, photo!)

Rangeons nos mugs, nos nouveaux vêtements trop voyant pour être vraiment portés… et entrons dans le vif du sujet :

University : « The Well-Grounded Java Developer – intro to Java 7″.

(lien résumé officiel Devoxx, speakers : Martijn Verburg et Ben Evans)

La session débute sous de bons auspices avec deux speakers motivés mais avec cette impression de parler en mâchant un chewin-gum (un accent bien américain donc). Ça commence par une question à l’assemblée de javaistes, pour savoir lesquels utilisent Java 4, puis 5, puis 6 (de plus en plus de bras se lèvent!)… et enfin 7 – et là tous les bras retombent. En effet, depuis juillet dernier la nouvelle mouture de notre langage préféré est arrivée « dans les bacs », mais elle n’a pas encore été adoptée par la communauté.

Introduction to Java 7

Le premier tiers de la présentation est donc dédié au passage en revue des nouveautés « alléchantes » amenées avec Java7.

Nous avons des nouveautés côté langage, le Project Coin :

• les nouveaux switch acceptant les string,
• les try-with-resources avec fermeture automatique des ressources,
• l’opérateur diamant <> qui allège l’utilisation des generics grâce à la déduction de type,
• le multi-catch permettant d’éviter la duplication de code (et bytecode), ainsi qu’un rethrow plus précis (le compilateur analyse les exceptions possible dans un catch)
• une nouvelle syntaxe pour l’écriture des nombres (séparation des milliers par des « _ »)

On ajoute à cela du côté des librairies :

• NIO.2 : une amélioration de la gestion des entrées/sorties (simplifiée!) avec possibilités de lecture asynchrone
• de nouvelles possibilités de réflexion (plus simple et optimisée) avec notamment la nouvelle instruction invokedynamic, sensée être aussi rapide que l’invocation statique classique en Java (il y aurait une amélioration de performance x10 pour les langages dynamiques tournant dans la JVM!)

et aussi :

• un nouveau look&feel pour Swing (Nimbus)
• JDBC amélioré
• nouvelles classes Helper (nouvelle classe Objects)
• meilleur support d’Unicode, et j’en passe…

Pour conclure ce chapitre, les speakers nous assurent que Java7 va nous aider à faire encore mieux notre métier. Les bonnes pratiques fusèrent durant la présentation, et nos orateurs insistent sur une statistique : une ligne de code couterait 32$ par an de maintenance ! Oui, tout de même!
Quelques morceaux de bravoure également dans cette présentation orientée « méthodologie » avec la mise en avant du côté social du développeur, voyez plutôt :

« Developers who communicate the best are the most influent on their projects. »

Polyglot and functional programming

Dans le monde Java, certaines âmes averties se posent ce genre de questions :

« Pourquoi le langage Java évolue-t-il si lentement ? »
Mais aussi :
« Pourquoi tant de langages de la JVM semblent beaucoup plus avancés que Java ? »

D’après nos deux compères américains, ces langages seraient tout simplement plus spécifiques que Java, souvent dédiés à répondre à des problématiques plus précises. Ils seraient comparables à des fenêtres sur l’avenir de Java. En quelque sorte des laboratoires desquels sortiront des nouveautés matures et non pas des changements par « effets de mode » polluant alors au fur et à mesure le langage.

« There are some features in Scala which everyone now regrets. »

Mais pourtant, parfois des nouveautés sont adoptées pour aider le programmeur, mais trahissent le plus souvent un problème de conception (exemple des nouveaux switch).
Il faut bien faire un peu de social aussi dans le monde de Java !

L’objet de cette partie est donc de nous sensibiliser à l’existence de plus de 200 autres langages fonctionnant dans la JVM :

• les ré-implémentations de langages : JRuby, Jython,
• ceux qui sont désigné comme des « Java-killers » : Fantom, Ceylon, Xtend, Scala
• les dynamiques : Groovy, Rhino, Clojure,
• les académiques : loke,  Steph…

Et on nous donne les clés du choix d’apprentissage d’un nouveau langage (simplicité, intégration avec IDE, employabilité, interopérabilité avec Java, tests…)

Vient ensuite le cas de la programmation fonctionnelle dans une approche centrée sur Java.
« Qu’aurions-nous besoin et que manque-t-il donc à ce sujet dans cette 7ème version de Java ? »
Avec de nombreux exemples à l’appui, on voit qu’effectivement, nous aimerions de temps à autre pouvoir passer des méthodes comme paramètres d’autres méthodes ! Les exemples des design patterns Map et Filter sont tout à fait éloquent (et je me rends alors compte, qu’en Flex/AS3 j’exploite justement beaucoup cette possibilité…)

Par chance nous apprenons que justement, Java 8 va nous apporter cette programmation fonctionnelle… en empruntant la syntaxe à celle de Scala ! La boucle est bouclée.

Modern Java Concurrency

Je dois avouer que le dernier chapitre sur la concurrence était quelque peu barbant pour terminer la matinée !

On nous a servi une fois de plus le discours sur la puissance des processeurs qui plafonne, sur la loi de Moore, et sur la nécessité qu’ont eu les fondeurs de puces de passer à du multicore… Le problème que cela pose donc : pour tirer profit de ce dernier retranchement devant la fin de l’amélioration de la puissance de nos machine, il faut que nos logiciels apprennent à gérer la concurrence.

Et le problème glisse donc tranquillement sur nos petites épaules de développeurs : NOUS allons devoir apprendre à gérer la concurrence !

Je ne détaillerai pas davantage la présentation qui fut une successions de nombreux exemples pratiques, pour s’achever sur la présentation de la nouvelle API Fork/Join de Java7 pour optimiser les calculs en tirant profit des machines multi-cœurs.

University : « The Groovy Ecosystem ».

(lien résumé officiel Devoxx, speakers :Andres Almiray)

Le speaker nous propose un tour d’horizon des projets Groovy les plus connus, et s’attarde notamment sur Grails, Griffon et Gradle.

Grails, le framework de développement rapide d’application Web basé sur Groovy.

Après les éloges de son très bon support par les IDE « communs » (comprenez Eclipse, Netbeans et IntellJ IDEA), nous avons droit au couplet sur sa facilité de mise en œuvre, son extensibilité avec plus de 600 plugins, etc…

Vient ensuite la partie croustillante de l’université : la démonstration !

Il s’agit donc, sans grande surprise, de la fabrication de toutes pièces d’une petite application CRUD. En quelque lignes de commande, on crée l’application, le modèle, les contrôleurs, les contraintes de validations pour les champs de notre interface, le multilinguisme avec la traduction française toute faite, etc… et tout cela codé en Groovy.

Le code est très succinct, car tout fonctionne sur base de templates, qu’on surchargera pour changer les comportements par défaut. Il est d’ailleurs aussi possible d’afficher le code final généré et de le modifier à loisir.

Griffon, le « penchant application lourde » de Grails.

On passe ensuite sur la rapide présentation de Griffon, et surtout la démonstration qui nous intéresse.

Une commande pour créer une structure d’application Swing, avec des modèles, contrôleurs et vues à adapter à nos besoins. Il semble que le langage soit particulièrement adapté à l’écriture d’interfaces Swing par sa clarté et sa puissance.

Gradle, un outil de build de nouvelle génération écrit en Groovy.

On nous le présente comme l’alternative attendue à Ant et Maven. A la fois puissant, puisque ses scripts sont écrits en Groovy, ce qui lui permet de profiter de ses nombreuses APIs. Il est aussi compatible avec ses concurrents, et peut par exemple utiliser les repositories et artefacts maven, tout en s’intégrant parait-il facilement dans les usines logicielles déjà en place.

Le produit est jeune cependant, et même si on nous promet que « l’essayer c’est l’adopter », cela fait un système de build de plus à apprendre à maitriser…
L’avenir nous dira si son adoption est réussie. A tester !

D’autres projets :

L’université se termine sur un passage en revue de différents autres projets de l’écosystème Groovy :

• Gaelyk (pour le déploiement de nos applications Groovy dans le cloud)
• Gant (pour faire de l’Ant en Groovy… sans xml!)
• EasyB (pour faire de la BDD dans nos projets java)
• Spock Framework (pour faire des tests unitaires et fonctionnels de manière plus intuitive et efficace)
• Gpars (pour la concurrence)
• Codenarc…

Et voilà que s’achève une session à la fois intéressante et dense en informations, animée par un très bon speaker!

Tools in action : « Pimp your ALM, with task-based development ».

(lien résumé officiel Devoxx, speakers : Michael Hüttermann)

Nous avons droit à une présentation des différents outils de travail d’un développeur sur un projet agile « orienté taches ».

On fait une passe rapide sur l’IDE Eclipse et le plugin Mylyn permettant de visualiser les taches créées par le métier/la recette, et sur la manière dont les commits référencent les tickets.
Ensuite on se tourne vers l’intégration continue de l’outil Jenkins et son fonctionnement avec :

• Jira (aidé du plugin Greenhopper) pour visualiser les tickets,
• Fisheye pour afficher les différentes versions de code et les deltas par révision,
• Artifactory comme repository de nos constructions,
• et enfin Sonar pour visualiser les métriques concernant la qualité de notre code…

En conclusion, pas une seule nouveauté croustillante ni aucune information récoltée pour un développeur sous Eclipse avec un minimum d’expérience.

Tel un « pitch » pour son livre – dans lequel, j’espère, il aura plus de choses à dire – notre speaker s’efforça de survoler d’un peu trop haut, le sujet. En insistant évidemment sur son l’excellence de son livre au passage. Le moins que l’on puisse dire, c’est qu’il avait vraiment envie de le vendre, son livre. J’ajouterais que la présentation était très courte, encore plus que le format prévu, pourtant de 30 minutes. Et finalement c’était peut être un moindre mal vu l’ennui engendré par ce « Tools in Action ».

Tools in action : « Jenkins: From Continuous Integration to Continuous Delivery ».

(lien résumé officiel Devoxx, speakers : John Smart)

Cette session aborde le problème du branching multiple de projet, et des problèmes du cycle de vie des branches tout au long d’un projet.

On commence par nous montrer les possibilité de Jenkins, notamment son intégration avec CloudBees pour le déploiement dans le cloud en cas de succès des constructions. Encore une fois Git est à l’honneur, avec sa simplicité d’utilisation et le merge de branches.
Idéalement dans le processus de livraison, nous devrions à un moment donné choisir les fonctionnalités (comprendre « branches » à pousser sur le « trunk ») pour confectionner le livrable.

Grâce à l’option de merge avant build de Jenkins, on peut construire la branche en validant son bon fonctionnement sur le trunk, avant de valider le build et s’assurer ainsi que notre branche est fiable avant de la pousser dans la livraison.

« Continuous Delivery is impossible without Continuous Quality ».

L’idée est de s’assurer constamment de la qualité de l’intégration à l’aide de Smoke Tests (on nous fait une démonstration avec thucydides dont je n’avais jamais entendu parler).

Jenkins, parmi sa panoplie d’outils, nous offre une vue synthétique de nos derniers builds, la Build Pipeline. Nous voyons immédiatement, par exemple, si un smoke test n’a pas fonctionné, stoppant ainsi le workflow de livraison. Nous avons aussi la possibilité de lancer des builds à partir de cette vue, pour par exemple pousser en production une (précédente) version spécifique.

Session de fin des 2 University Days : « The Fireside chat ».

(Intervenants : Tim Bray, Cameron Purdy, Mark Reinhold et Henrik Ståhl)

Pour conclure ces 2 premiers jours à la Devoxx 2011, une discussion est amorcée entre 4 personnes influentes du monde Java autour d’une table (mise en situation : imaginez un bar) et qui échangent sur divers sujets d’actualité.

A n’en pas douter, le discours n’est pas préparé, ça commence d’ailleurs plutôt mollement (discussion au sujet de la bouteille de vin posé à leur table…). Le dialogue se met en place doucement et ils parleront durant près d’une heure avant que le « médiateur » ne les arrête.

Et de quoi ont-ils parlé ? De Java tout d’abord, l’évolution du langage et des langages de la JVM.
De l’avenir d’HTML5 dans le web actuel.
Des smartphones et plus spécifiquement des nouvelles tendances et besoins amenés avec l’invention des iPhones et iPads.
De l’imprévisibilité de ces succès technologiques.
De nos habitudes en tant qu’utilisateurs de nouvelles technologies.
Finalement ils reparleront du web en général, et ils ne pourront s’empêcher de revenir à nouveau sur le sujet des smartphones.

Bonne ambiance et applaudissements vigoureux garantis !

Voilà donc terminées nos deux intenses journées, et je retiendrai la blague de Mark Reinhold :

« What’s the difference between Maven and Ant ? The creator of Ant has apologized ! »

Il n’a peut être pas encore testé Gradle !

Voilà, ce millésime 2011 de la Devoxx c’est vraiment fini, et cette année la JOP y était ! Nul doute que l’année prochaine, d’autres ambassadeurs de Novédia auront tout intérêt à y retourner!

Du moins pour mon collègue Mehdi Ben Haj Abbes et moi-même, l’aventure de la plus grosse conférence Java de nos contrées européennes s’est terminée mardi dernier, après deux longues journées remplies (à ras bord, mais qui se plaindra?) de conférences en tous genres. Précisément, lors de ces deux premiers jours à la Devoxx 2011, nous avions accès à deux formats de meeting :
- des « University« : ce sont de grosses sessions de 3h, dont le but avoué est d’entrer le plus en profondeur possible dans un sujet nouveau (du moins un sujet à la mode),
- des « Tools in Action » de 30 minutes chacun où, comme le nom l’indique, les speakers vont parler de leurs outils préférés développés autour de l’écosystème Java (du genre Sonar, Mylyn, jclouds, Jenkins, et d’autres noms farfelus dont certains m’étaient inconnus)

Chaque créneau horaire s’articulant autour de 4 salles de cinéma géantes et tout confort (j’entends par là, des salles de cinémas de province), le choix avant chaque session fut souvent cornélien… avec parfois quelques regrets, comme lorsque je me suis lancé naïvement dans une session de 3h, barbante au bout de 20 minutes. Heureusement dans ce cas là, à la Devoxx il est toujours possible de se lever et changer de salle! Car oui, à la Devoxx 2011, les show n’étaient pas tous du même niveau !

Je vais vous faire pour ma part un debriefing « à chaud » (du moins écrit à chaud…) des sessions que j’ai pu couvrir durant ces 48h intenses d’informations Javaesques. De quoi avoir un aperçu du quart des sujets sur ces deux jours.

Je publierai cet article sur deux billets blog distincts, pour des raisons de place et de format.

University : « Building Next-generation Enterprise Applications in Java a.k.a. Duke’s Duct Tape Adventures ».

(lien résumé officiel Devoxx, speakers : Bert Ertman et Paul Bakker)

Grosse session pure Java EE 6, tenue par deux speakers un peu déjantés (très bien pour commencer une journée après un réveil avant 7h du matin…).

L’idée c’est de voir ce que met à notre disposition la stack Java EE 6 et son CDI (la JSR299 pour les intimes) pour le développement d’applications « d’entreprise », dans un contexte où le framework Spring semble être LA solution communément choisie.
Concrètement, l’university s’est déroulée comme les « shows à l’américaine » en vogue sur le sujet, à savoir : un couple fonctionnel- »codeur exécutant » (mais attention, ultra performant dans ses exécutions !), un peu l’analogie du good cop / bad cop des séries du genre. Le fonctionnel formule des requêtes un peu « surréalistes » (exemple: « d’accord, c’est bien ce que tu as fait comme application, mais je viens d’être contacté par Amazon, on doit absolument leur fournir une API REST, tu as 4 minutes !« ) que bien sur notre développeur survitaminé semble exaucer sans sourciller, ou presque, mais ça, c’est l’effet démo.

C’est l’occasion pour moi de voir la magie de Forge (de JBoss) en action. Car bien évidemment le duo part d’une copie vierge (c’est à dire un MySQL, un serveur Glassfish, un JBoss, Maven et un IDE Intellj IDEA), et va nous réaliser en l’espace de quelques minutes un chef-d’oeuvre d’application CRUD déployable indépendamment sur Glassfish ou autre (quoique le « autre » n’a pas réussi à être démontré en… démo) avec UI en JSF 2. Je ne détaille pas davantage Forge pour l’instant (c’est un outil de RAD : Rapid Development Applications) car j’aurai l’occasion d’en reparler ultérieurement.

On passe donc en revue les étapes de création d’une application d’entreprise « légère », avec dans l’ordre d’apparition :

• pages JSF qui attaquent la couche de navigation avec gestion de conversations (dans l’exemple, le cas d’un « panier » web)
• cette couche appelle les services métiers
• la couche métier va persister nos entitées ejb avec JPA et faire les requêtes à l’aide de l’API Criteria
• des tests d’intégration sont mis en place très rapidement avec Arquillian (et merci encore à Forge)
• on nous montre la validation de formulaire avec Hibernate-validation (implémentation de référence de la JSR303 embarquée dans la stack Java EE 6, mais qui ajoute quelques possibilités comme la validation des e-mails)
• c’est ensuite le moment de nous montrer comment faire communiquer les beans Java entre eux à l’aide d’event et de listeners pour découpler les traitements entre services (ils nous donnent l’exemple de services d’envoi de SMS)
• logiquement vient ensuite un court laïus sur le scheduling et les batchs tellement simples à mettre en oeuvre qu’on se demande pourquoi on n’en fait pas tous les jours
• dans la même veine, vient le chapitre sur le messaging et le système de souscription/topic tout aussi simple avec ce sixième opus de Java EE
• on expose ensuite nos services en REST (et en 4 minutes donc)
• la présentation se termine sur le déploiement de l’application sur serveur JBoss (FAIL donc) et même dans le cloud avec OpenShift (Double FAIL pour l’occasion et pour terminer la session…)

Voilà donc pour conclure une session très intéressante, mais avec beaucoup de redites si vous aviez déjà pratiqué un tant soit peu JavaEE et sa 6ème mouture. C’était aussi l’occasion de vérifier que tout bon geek frustré va placer des « babes » dans un slide sur deux, et dans toutes leurs démos ! L’avantage, c’est que ça donne des photos… pas banales. Jugez sur pièces.

University : « Intro to HTML5 Game Development ».

(lien résumé officiel Devoxx, speaker : James Williams)

Voilà surement ma grosse déception de la Devoxx 2011. Le mot est lâché. Je m’explique….
Fanatique depuis tout petit de jeu vidéo (10 ans : « je veux faire de l’informatique, comme ça je pourrai faire mes jeux vidéos », 15 ans plus tard : « alors c’est une application pour vendre des tongs et des slips de bain sur l’internet convivial »…) je n’ai pas été insensible au titre accrocheur de cette session.
Si l’on ajoute qu’en plus j’essaie d’être attentif à ce qui se trame du côté d’HTML5 mais sans jamais avoir le temps de m’y mettre, je dois avouer que j’étais franchement séduit par l’idée de mêler l’utile à l’agréable. D’ailleurs, je ne devais pas être le seul : oui, la salle était pleine à craquer, plus encore que pour les autres conférences.
Nous avons donc eu droit à un étalage des spécifications d’HTML5 avec mini-exemples (comprendre 3 lignes de codes hors contexte) à l’appui.
En vrac, nous avons tout d’abord vu :

• ce qu’est le cache applicatif et sa gestion via le fichier Manifest,
• le concept de « workers » javascript et les échanges de messages avec la page hôte,
• l’existence de websockets qui seraient le TCP des applications habituelles,
• le support de WebSQL dans HTML5 (apparemment un SQLite-Like sur lequel tout le monde ne s’est pas encore mis d’accord),
• la possibilité d’attaquer de manière transactionnelle des DB indexées type NoSQL,
• le stockage de données côté navigateur.

Une fois ce tour « technique » du propriétaire, nous avons eu droit à une énorme quantité de slides concernant l’aspect « Game » de la conférence à savoir :

• comment lancer 2 sources audio en même temps, lire une vidéo,
• le système d’animations,
• le Canvas2D pour le dessin et toutes les techniques de dessin possibles et inimaginables,
• toutes les manières de transformer un canvas, d’afficher une image, la manipulation au niveau pixel des images,
• Tridens.js pour l’animation avec « timeline » et des « easing functions »,
• Raphael.js pour créer des scènes avec des SVG (Scalable Vector Graphics), et permettrait aussi des « easing functions », le support de « gestures » avec la souris, etc…
• Three.js pour faire du rendu de scene 3D WebGL (basé sur OpenGL) et toutes ses possibilités (gestion de caméras, de lumières, de meshes/shadings/materials… etc), la syntaxe de GLSL (type C) pour l’écriture de pixel et vertex shaders, l’application de textures, le chargement de modèles 3D, les animations (keyframes, cinématique inversée et tout le toutim…)
• Stats.js pour le debugging et le suivi du framerate / performance de l’application

On nous a ensuite détaillé les différentes possibilités de déploiement de nos applications et les business modèles en concurrence. PhoneGap et le rachat de Nitobi par Adobe sont mentionnés. Peut-être la partie la plus intéressante de la conférence…

Le show s’est ensuite terminé prématurément, n’ayant duré que 2h au lieu des 3 prévues, et laissant place à des échanges de questions/réponses… ce qui m’a laissé un peu de temps pour profiter de la fin d’une autre university.

En conclusion, c’était plus un listing des possibilités d’HTML5 qu’une entrée en matière. Pas de vrai démonstration ni de conseils pour se lancer/savoir par où commencer. J’attendais beaucoup de cette session, qu’elle soit moins linéaire et un minimum interactive, et j’ai d’autant plus été déçu.

Tools in action : « Spring Data JPA – Repositories done right ».

(lien résumé officiel Devoxx, speaker : Oliver Gierke)

Je ne vais pas parler de cette partie car Mehdi s’occupe de nous rédiger un bel article sur le sujet !
Je passe donc mon tour.

Tools in action : « Forge new Ground in Rapid Enterprise Java Development ».

(lien résumé officiel Devoxx, speakers : Lincoln Baxter III et Dan Allen)

Vient ensuite la présentation de l’outil Forge de Jboss. Peut être une des plus impressionnantes présentations de ces deux jours.
A la fois concise, poussée et ludique, cette session nous a permis de voir toute la puissance de Forge en action. Si j’avais pour ma part une petite idée de ce que propose cet outil, rien ne vaut une belle démonstration pour être parfaitement bluffé!
On débute avec un environnement Eclipse et le plugin Forge installé. Première impression de ce plugin : c’est bien intégré et vraiment plus pratique qu’une fenêtre en ligne de commande ouverte.
Concrètement, en quelques commandes, apparait une application type CRUD avec JSF 2.0, une base de données embarquée et un support de REST, le tout avec la configuration Maven adéquate. Forge nous permet non seulement de créer des entités JPA, mais aussi de les manipuler, leur rajouter des champs, etc… Des tests sont créés avec la même simplicité.
On nous apprend rapidement comment utiliser des plugins pour forge, mais aussi comment en créer et définir nos commandes.
Une session très intense de 30 minutes !

Tools in action : « Code Review with Git and Gerrit ».

(lien résumé officiel Devoxx, speakers : Chris Aniszczyk and Matthias Sohn)

Pour finir la journée, un « Tools in Action » un peu plus orienté méthodologie. En effet, après un bref descriptif du fameux Git qui va (tarde à?) remplacer nos vieux SVN (voire CVS pour les nostalgiques), après avoir vanté ses mérites  et avoir listé les grands projets qui l’utilisent, on nous parle de Gerrit. Mais qu’est-ce donc ?

Gerrit, c’est simplement un serveur Git, et c’est l’outil miracle pour « enfin » réussir à faire adopter les bonnes pratiques agiles à une équipe de développement. Oui, je parle bien de ces plans d’actions qu’on tente d’établir de sprint en sprint, où l’on répète que le pair programming, la revue de code et les tests sont des axes d’amélioration. Ces utopies annoncées à chaque rétrospectives… mais qui, une fois le sprint lancé, sont si dures à tenir pour toute l’équipe qui garde son nez dans le guidon.

Voilà donc Gerrit. Gerrit va nous prendre par la main, et nous apprendre un workflow agile de développement. Le pair programming, la revue de code, les tests et la validation des commits seront enfin inscrits dans un processus cadré. De concert avec Git, Gerrit, avec son système de commentaires sur les commits, de visualisation des commits (type Fisheye) et surtout le mécanisme de vote sur les commits des autres développeurs, va nous permettre de ne pousser sur la branche commune que des évolutions validées par des collègues. Chaque développeur va ainsi faire de la revue de code, s’impliquer dans celle-ci, apprendre et s’autoformer éventuellement, intéragir avec le développeur/commiteur et échanger avec lui sur ses lignes de code. Bref, l’utilisateur de Gerrit est responsabilisé via son vote à la validation d’une modification.

Le principe a l’air simple et efficace, l’effort louable, mais je continue de me poser une question après cette étalage de bonnes idées :
Gerrit n’est-il pas juste un plan d’action de plus inscrit sur un tableau lors d’une rétrospective puis oublié au sprint suivant ?

La suite du billet JOP à la Devoxx 2011… dans quelques jours !