Formation Scrum Product Owner certifiante animée par Arlen Bankston les 12 et 13 décembre 2011.

Cette formation inclue les petits déjeuners, pauses cafés, déjeuners (restaurant La Cavalina), supports de cours, pokers cards, une copie de l’ouvrage « Scrum en action » de Guillaume bodet, l’abonnement à la Scrum Alliance et la certification Scrum Product Owner bien entendu.

Si cette formation vous intéresse ou que vous souhaitez de plus amples informations, n’hésitez pas à nous contacter au 01 53 89 99 99 ou par courriel (info@xebia-training.fr).

Actualité éditeurs / SSII

• Spring Suite Tool (STS) 2.8.0
• L’avenir des clients Java passera par JavaFX

Agilité

• Estimations
• Les métriques du bonheur

Le coin de la technique

• Continuous Deployment

Actualité éditeurs / SSII

Spring Suite Tool (STS) 2.8.0

SpringSource vient de sortir la dernière version de son IDE basé sur Eclipse : Spring Source Tool Suite (STS) 2.8.0. Il inclut désormais Eclipse Indigo SR1, avec le support de Java 7. Il ajoute également le support de Spring 3.1 pour la configuration des beans : profiles et c-namespace. De plus, l’intégration avec Maven s’améliore avec le passage de m2eclipse 0.12 à m2e 1.0 (attention tout de même, ce dernier introduit la notion de connectors qui sont requis pour lier les plugins à Eclipse mais n’existent pas pour tous les plugins Maven, certains l’ont subi avec difficulté).

Vous utilisez Spring mais pas STS? Vous devriez essayer! Tous les plugins pour Spring sont présents et le téléchargement inclut les dernières versions de Maven (3.0.3), Spring Roo (1.1.5) et tcServer (2.6.1).

L’avenir des clients Java passera par JavaFX

Durant la dernière conférence JavaOne 2011, Oracle a dévoilé sa stratégie concernant les applications clientes Java. Sans surprise, Oracle mise sur JavaFX.
Pour rappel, JavaFX est une API pour développer des RIA (desktop ou mobile), apparue il y a quelques années, mais qui n’a pas rencontré le succès escompté. Face à cet échec, une nouvelle version 2.0 de JavaFX a été présentée à la conférence JavaOne 2010.
Parmi les nouveautés marquantes, on peut noter l’abandon du langage Fx Script pour une API full Java. Cela permet notamment l’utilisation d’autres langages compatibles avec la JVM, tels que Groovy ou Scala. On voit aussi apparaître un descripteur d’interface graphique au format FXML. Celui-ci sera accompagné d’un outil graphique (standalone pour le moment), Java Fx Scene Builder, facilitant la création des interfaces. Cet outil fera son apparition courant 2012. Enfin, JavaFX pourra embarquer des composants HTML5 et JavaScript via l’utilisation de WebKit. Le projet Avatar pousse même encore plus loin, en proposant des applications hybrides avec des interactions entre le monde JavaFx et HTML5.

Afin d’accélérer son développement, JavaFX va devenir open-source et sera intégré directement dans le projet OpenJDK. En parallèle, J2ME, l’API mobile historique de Java, va être unifié aussi dans le prochain JDK.

L’objectif d’Oracle est de diffuser JavaFx sur un maximum de périphériques possibles: desktops, mobiles et tablettes. Potentiellement, tous les périphériques compatibles avec la JVM pourront supporter JavaFX. Une version bêta est d’ores et déjà disponible pour Mac OS X. Une version pour Linux (Ubuntu) fera son apparition en 2012. Au final, JavaFx 3 sera intégré dans le JDK 8 prévu pour 2013 et sera compatible avec toutes les plateformes.

Agilité

Estimations

Un sujet revient régulièrement lorsque l’on parle d’agilité, c’est celui de la planification et de l’estimation de la durée d’un projet. InfoQ a d’ailleurs publié récemment 3 articles dédiés au sujet.

Le 1er article parle de la problématique d’estimer un projet dans sa globalité. Un tel problème fait toujours bondir les agilistes ! En fait, plus le contexte est connu et maîtrisé par l’équipe de développement, moins il est malhonnête de faire des estimations. Mais celles-ci sont généralement difficiles. Une idée évoquée est de démarrer avec un scope fixe permettant d’éduquer graduellement le client à l’Agile afin de lui ouvrir les yeux sur le mirage du périmètre fixe. Dans les commentaires, on trouve des avis contradictoires, mais tous valables. Adam Nemeth par exemple, s’exclame que les estimations sont inévitables: nous sommes payés pour résoudre les problèmes qu’ont d’autres et ils attendent les solutions pour une date donnée. Il est par exemple inconcevable de sortir le site internet des JO d’été de 2012 en hiver par la faute d’une erreur dans le chiffrage des tâches. Mais, plus loin dans son commentaire, on se rend compte que lui est capable de bien planifier car il a la chance de travailler dans un environnement stable avec des patterns de problèmes identiques pour lesquels il a pu mettre en place une solution qui s’applique à chaque fois. Dans un tel environnement « idéal », il n’est pas inconcevable de pouvoir chiffrer aisément avec une bonne approximation.

Le second article se demande si le temps est venu d’arrêter d’estimer les user stories. On retrouve là aussi, en caricaturant, une distinction entre ceux qui pensent qu’il vaut mieux créer un produit de qualité et ceux qui pensent que les estimations sont, bien que science inexacte, un mal nécessaire. Les commentaires, une fois de plus, ne sont pas inintéressants. Josh Gough y décrit ce dans quoi certains se reconnaîtront: il parle des « guesstimates » (estimation basées sur rien de concret) et des « wishtimates » (lorsque la date prévisionnelle de fin de projet prise en compte est la date idéale) qui sont souvent utilisées en lieu et place d’estimations vraiment réalistes. Pour lui, elles sont généralement basées sur des aspects politiques ou des facteurs psychologiques qui donneront à la personne inexpérimentée qui est en charge une fausse sensation de contrôle. Que faire lorsque le management attend de vous non pas un intervalle de risque mais une date fixée dans le marbre ? Il préconise de manière pragmatique d’essayer de s’appuyer sur des données empiriques et factuelles ainsi que de sensibiliser les personnes à la complexité des projets, des tests et du risque. Plus loin, ce même Josh Goush utilise une analogie avec le travail d’un peintre. Confieriez-vous la peinture de votre maison à un peintre vous ayant fixé un prix sans même vous avoir demandé le nombre de pièces et leur taille ? En développement logiciel, c’est le même principe exception faite que la taille et le nombre des pièces est extrêmement dur à appréhender. Et nous revenons ici au principe de base de l’agilité qui est d’adapter le projet au fur et à mesure de son avancement aux besoins changeants du client. D’où l’impossibilité de déterminer une fois pour toutes un chiffrage en amont du développement.

Enfin, un troisième article se demande ce que signifie le « rythme soutenable » évoqué dans le manifeste agile et comment y parvenir. Le lien avec la difficulté d’estimer un projet est vite réalisé: il est fréquent que des estimations initiales prétendent tenir compte de tous les évènements imprévus (!). Dans ce cas, il n’y a plus que les heures sup’ pour absorber les vrais évènements imprévus qui ne manquent pas de survenir. Au final il semble que tout le monde s’accorde à dire que les premières victimes d’un rythme élevé sont toujours la qualité et les bonnes pratiques.

Les métriques du bonheur

Qui a dit que les métriques, si chères à notre gestion de projet, sont tristes et vous donnent le cafard le lundi matin en stand-up? Que dire des courses à l’indicateur, pour atteindre l’objectif chiffré, quoi qu’il en coûte!
Anders Laestadius, coach agile suédois de son état, nous propose une liste de quelques métriques que son expérience lui indique comme nécessaires:

• la mesure de bonheur ou de stress de l’équipe, pour la partie management
• le pourcentage de duplication de code, ainsi que la couverture de tests, pour la partie conception de l’application
• Le release burn down et lead time pour suivre l’engagement du projet envers le client.

Avancement du projet

L’un des incontournables de la méthode SCRUM est la mesure du Release Burn Down. Anders préconise le suivi de la Release plutôt que du sprint, ce qui est plus en accord avec la vision client.
Lors de l’utilisation de la méthode Kanban, il préfère utiliser le « Lead Time ». Il consiste à mesurer le temps que met une tâche pour sortir du système. Il permet de connaître le taux de « réactivité » de l’équipe et sa capacité à absorber une certaine charge de travail dans un intervalle de temps donné.

Santé technique de l’application

Selon l’auteur,le taux de duplication de code est le meilleur indicateur de qualité de code pour une application. Un code trop souvent dupliqué soulève un problème de conception avec du refactoring à prévoir. De plus, cela est source de bugs et d’effets de bord. Facile à détecter, et relativement facile à corriger.
Pour le taux de couverture de code, le Test Driven Development reste la solution numéro 1 pour l’améliorer efficacement. Les outils de couverture de code, comme Cobertura, permettent de rapidement voir les portions de code non testées, pour améliorer encore et toujours la robustesse de nos applications.

L’équipe

L’indicateur de « bonne humeur » d’une équipe permet de voir d’un autre point de vue l’équipe. On ne parle plus d’effort, de vélocité ou de taux de progression. La bonne humeur est directement liée à la motivation de l’équipe à respecter l’engagement du sprint. On peut aussi utiliser l’indicateur de « Stress ». Cela permet aussi de détecter, lors des creux, des problèmes qui déstabilisent l’équipe, pour mieux les résoudre ensuite. Mais attention, stress et motivation ne sont pas forcément contradictoires. Le daily scrum meeting ou la séance de rétrospective de SCRUM sont les moments privilégiés pour mesurer cet indicateur.

Le coin de la technique

Continuous Deployment

Pour ceux qui n’ont pas encore entendu parler du déploiement continu, Ranjan D. Sakalley nous propose une excellente introduction sur le sujet.
Ce processus n’est que la suite logique de l’intégration continue. Il consiste à déployer son application le plus rapidement, le plus sûrement et donc, le plus souvent possible. On est toujours dans l’esprit d’avoir un cycle de travail court avec un retour rapide sur ce qui a été développé, pour corriger au plus tôt et ainsi réduire le coût global de mise en oeuvre de l’application. De célèbres exemples, comme Flickr et Github sont capables de mettre en production leurs applications plusieurs fois par jour, oui par jour!
Pour arriver à un tel niveau de maturité, il faut se doter d’une couverture de tests exemplaire et surtout, cela impose la nécessité d’automatiser tous ces tests.
L’exemple donné révèle rapidement le besoin d’avoir une équipe de 50 testeurs pour arriver à recetter une application de taille moyenne en 2 heures. On précise aussi que l’investissement initial a été de deux développeurs pendant deux mois pour la création des scripts de tests.
Si on doit livrer son application plusieurs fois par jour, on voit tout de suite la nécessité de l’automate.
L’article souligne aussi que l’automatisation des tests simples et répétitifs libère du temps aux testeurs qui peuvent ainsi aller plus en profondeur sur le code existant, pour ainsi trouver des bugs plus profonds. Cela rend au passage leur journée de travail plus intéressante, ce qui n’est pas rien en ces jours d’hiver qui s’obscurcissent!
L’auteur nous rappelle aussi qu’il est autant nécessaire de tester les aspects fonctionnels que non-fonctionnels, comme la tenue de la charge ou la performance.

Ce sujet est un bon complément aux deux derniers ateliers organisés chez Xebia sur le déploiement continu, où l’on a vu comment le plugin Apache Tomcat Maven, Rundeck et DeployIt, avec Jenkins, nous aident à faire du déploiement en zéro clic après un git-push sur un repository de code. Nous publierons très prochainement un billet sur le sujet, ainsi que sur toute l’infrastructure mise en place sur Amazon EC2, avec notre stratégie d’Infrastructure as a code. Restez à l’écoute si ces sujets vous intéressent!

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

• JavaOne
• Google Dart
• Google Cloud SQL
• Apache TomEE

Agilité

• SCRUM se met au crowdsourcing

Actualité éditeurs / SSII

JavaOne

La conférence JavaOne 2011 s’est tenue la semaine passée à San Francisco. Comme chaque année, elle a été l’occasion d’un grand nombre d’annonces, de keynotes et de plans sur le futur de Java. On notera après avoir pris la température auprès de la communauté, que celle-ci semble moins inquiète que dans un récent passé: Oracle est là depuis un moment maintenant, les choses semblent s’être stabilisées et clarifiées. La récente arrivée de Java 7 ne doit pas y être pour rien. Parmi les diverses annonces, on retiendra surtout :

• Java 8 est retardé à début 2013. Nous aurons le temps de vous reparler des nouveaux apports.
• Java ME tend à se rapprocher de Java SE et vise à en devenir un sous ensemble. L’intérêt est d’unifier les communautés de ces 2 versions.
• Java EE 7 est en préparation, orienté Cloud et multi-tenancy
• JavaFX n’est pas mort. Les mauvaises langues diront que le projet ressort du placard chaque année pour JavaOne. Mais Oracle semble décidé à le faire avancer: il devrait progressivement devenir complètement OpenSource et une version 3 est prévue, intégrée directement dans le JDK 8.
• Pour rêver un peu, quelques pistes pour le JDK 9 ont été évoquées. On parle de VM s’adaptant toutes seules aux applications (plus de XmX et autres barbaries ?!), d’un nouveau Meta Object Protocol améliorant le support entre langages… Là encore, nous aurons laaaargement le temps d’en reparler !

On regrettera encore malgré tout l’absence de speakers de Google, à cause du procès opposant celui-ci à Oracle et alors que la compagnie n’est pas la moins active dans l’écosystème Java.
Le blog suivant recense nombre d’articles sur JavaOne et vous pourrez retrouver quelques roadmaps sur le podcast JavaSpotlight.

Parmi les autres annonces intéressantes, on notera l’annonce du serveur Apache TomEE qui est maintenant certifié EE 6 Web Profile. C’est un serveur Java EE qui se veut léger, basé sur un Tomcat tout ce qu’il y a de plus standard avec utilisation d’une librairie Apache pour chacune des fonctionnalités requises par la norme Web Profile: on retrouvera ainsi Apache OpenWebBeans, Apache MyFaces, Apache ActiveMQ, Apache OpenJPA et Apache CXF.
Et pour finir, Oracle a annoncé une nouvelle solution NoSQL. Le géant des bases relationnelles compte donc se diversifier en élargissant son offre. Retrouvez tous les détails de cette solution basée sur Java chez infoQ.

Google Dart

A l’occasion de la GotoCon, Lars Bak le créateur de la machine JavaScript V8 de Chrome et Gilad Bracha auteur du langage NewSpeak ont annoncé la naissance d’un nouveau langage de script pour les navigateurs nom de code Dart. L’annonce concerne le disponibilité de ce langage en Technology Preview, il n’est pour le moment pas supporté par Chrome.
Ce langage inspiré de la syntaxe JavaScript offre de plus le support de la concurrence de type acteurs. Notez de plus qu’il permet de créer des applications pour iPad.
Quelques caractéristiques du langage:

• Orienté objet avec classe, interface, et héritage
• Typage optionnel
• Mono-thread

Selon le paradigme acteur, les pocessus dart sont isolés et ne peuvent communiquer entre eux que par une API de messaging.
Dart supporte différents type d’éxecutions:

• JavaScript – Avec le compilateur DartC les .dart sont compilés JavaScript.
• DartVM – Une machine virtuelle permet d’éxecuter directement les scripts Dart.
• Un utilitaire permet de créer et packager une image binaire de la heap qui pourra être exécutée par la suite.

Côté outillage, Dart propose un éditeur basé sur Eclipse avec support de l’auto-complétion. Bref, avec Dart, Google semble vouloir proposer une alternative à JavaScript permettant enfin de structurer son code et probablement de réconcilier les Javaïstes avec la programmation côté navigateur. Une belle initiative à laquelle nous souhaitons un franc succès.
Pour plus d’information:

• L’annonce sur InfoQ
• Dartlang.org
• Google code de Dart

Google Cloud SQL

Google App Engine, la solution de cloud PaaS made in Google offre dorénavant la possibilité d’utiliser une base de données relationnelle de type MySql.
Ce service nommée Google Cloud SQL répond à de nombreuses demandes d’utilisateurs, qui souhaitaient une manière plus simple de persister ses données que la solution BigTable.

Comme on pouvait s’y attendre, ce service ne nécessite aucune maintenance, ni administration. Une interface d’administration est néanmoins fournie. Vous avez la possibilité d’importer ou d’exporter votre base de données MySQL. De plus, il offre un mécanisme de réplication géolocalisé des données sur des centres de données.

Pour le moment, ce nouveau service est gratuit et mis à disposition d’un nombre limité d’utilisateurs. Par ailleurs, les quotas fixés sont plutôt modestes: 5 requêtes par seconde et la taille d’une requête est limitée à 15MO. Si vous êtes intéressé, c’est ici pour s’inscrire.

Apache TomEE

Apache a profité de JavaOne pour annoncer la sortie de TomEE en version Bêta. La particularité de ce serveur web est d’être certifié JEE 6 Web Profile.
Il s’ajoute à la liste des serveurs open source déjà existant compatibles JEE 6 Web Profile: GlassFish, JBoss et Apache Geronimo.

Ce serveur est assemblé à partir d’un simple Apache Tomcat, auquel ont été ajoutées différentes implémentations Apache pour fournir tous les services EE.
Voici les implémentations des différentes briques de la stack JEE embarquées dans TomEE:

• CDI: Apache OpenWebBeans
• EJB: Apache OpenEJB
• Javamail: Apache Geronimo JavaMail
• JPA: Apache OpenJPA
• JSF: Apache MyFaces
• JTA: Apache Geronimo Transaction
• Connector: Apache Geronimo Connector
• JMS: Apache ActiveMQ
• Web Services: Apache CXF

La philosophie d’Apache TomEE est d’offrir une solution simple et légère pour faire du JEE. Ce serveur semble bien prédisposé pour les solutions de Cloud avec notamment sa faible taille mémoire (< 24 Mo).
Toutes les informations et le téléchargement se trouvent ici.

Agilité

SCRUM se met au crowdsourcing

La plus populaire des méthodes agiles marque un tournant significatif dans son histoire. Les co-créateurs ont décidé de laisser la possibilité à chacun de proposer des modifications ou des extensions au cadre de base. Cette annonce intervenue peu avant le week-end serait presque passé inaperçue. Il y a quand même eu quelques réactions spontanées, notamment David Anderson, le meneur du mouvement Kanban, qui se demandait sur Twitter qui serait le premier à proposer une extension Kanban pour Scrum.

De notre côté on se demande qui sera la première SSII française à proposer une extension de SCRUM pour remettre un rôle de chef de projet et de MOA dans tout ça ? Heureusement pour veiller aux dérives, il existe un comité de revue des propositions dont on connait au moins 2 personnes: James Coplien et David Starr. Ce comité est en charge de revoir les propositions et interagir avec leur auteur. L’histoire nous dira si ce comité, censé veiller au grain, adopte une ligne plutôt rigide ou permissive. Dans tous les cas le modèle pour proposer une modification ou une extension (c’est le même) demande de bien préciser le contexte dans lequel l’élément proposé est utile, à la façon d’une approche par pattern. Il faut également que la proposition soit appuyée par un sponsor et on nous promet une réaction sous 3 mois. Il est possible de voir en ligne la liste des extension proposées. Pour l’instant on en trouve une seule qui émane de David Starr, du comité de revue. Elle traite, d’après le titre, du découpage en tâche dans le sprint planning. Ah, mais ce n’est pas ce qui avait été supprimé de SCRUM en Juillet ça ? D’ailleurs les explications sur les modifications du Sprint Backlog provenaient également de David Starr. Donc si j’ai bien compris, il explique pourquoi ça disparait de SCRUM et ensuite il propose une extension pour le réintroduire si l’on veut. Bon, j’espère juste que SCRUM ne va pas finir comme le RUP avec un site web qu’on peut configurer à partir d’une bibliothèque d’extensions…

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

• Modification du guide SCRUM
• Nouvelle certification Agile au PMI

Le coin de la technique

• Betamax 1.0 refera t’il l’histoire ?
• Git: à chacun son flow

Agilité

Modification du guide SCRUM

L’été est souvent le moment privilégié par nos élus pour faire passer en douce des lois sans faire trop de bruit. Cela vous a peut être échappé mais cet été Jeff Sutherland et Ken Schwaber ont publié une mise à jour de SCRUM en 6 points. Je ne sais pas s’ils avaient eux-aussi la volonté d’introduire ces changements sans trop faire de bruit (un peu quand même), mais certains sont assez marquants, nous vous les détaillons ci-dessous:

• l’équipe SCRUM est désormais nommée « équipe de développement », fini la métaphore des poulets et des cochons. Ce changement de terminologie peut laisser quelque peu sceptique, car la notion d’équipe pluridisciplinaire ne transparaît pas très bien derrière le terme développeur. Dans la nouvelle Scrum Team donc, tout le monde sera développeur, que vous soyez programmeur, testeur, analyste, manager, ou quoique ce soit. Faut-il se réjouir de cette appellation ? Elle a en tout cas pour vertu de nous mettre face à l’objectif premier: développer un produit. Cela me fait penser à un célèbre dirigeant Américain qui n’avait pas hésité à déclarer « Ich bin ein Berliner » pour montrer sa solidarité. Chers cochons, quoique vous fassiez, aujourd’hui n’hésitez pas à clamer « Ich bin ein Developer ».
• La notion d’engagement est supprimée: ce sont les SSII qui vont faire la grimace, nombre d’entre elles bâtissaient des forfaits agiles sur cette notion d’engagement en début d’itération (ça ne les empêchera de continuer cela dit). C’est peut-être ce qui a poussé les créateurs de SCRUM à supprimer cette notion à double tranchants, l’engagement étant la base du mécanisme de soumission librement consentie. Il est maintenant remplacé par la notion de « prévision de ce qui peut être réalisé dans le sprint, cette prévision étant affinée tout au long de l’itération », c’est plus long à dire mais on risque moins de se faire manipuler
• Le burndown d’itération n’est pas obligatoire: les créateurs de SCRUM nous rappellent que ce qui est important est le suivi du reste à faire et pas la façon dont on le suit
• Le Release Planning n’est pas un élément de SCRUM: un changement en forme de précision, les auteurs signalent tout de même qu’il est utile de le faire, ouf !
• Le backlog de sprint est supprimé: sans doute le changement le plus marquant, la corvée du découpage en tâches estimées en heures ne sera plus imputable à SCRUM. Les auteurs auraient pu ajouter une phrase du type « nous déclinons toute responsabilité si vous continuez à découper, estimer, et suivre des tâches » tellement cette pratique donne la migraine aux équipes qui débutent, et tellement les équipes familières avec SCRUM s’en débarrassent avec bonheur. Ce sont les éditeurs de logiciel de gestion de projet agile qui vont faire la grimace: si ça continue les équipes SCRUM n’auront plus besoin que de post-it.
• Le product backlog n’est pas priorisé mais trié: là encore ce changement a le mérite de mettre l’accent sur le fond et pas sur la forme, même si la nuance est subtile. La priorisation amenait parfois des débats pas forcément constructifs entre l’équipe, qui a besoin d’éléments prêts à être réalisés (« ready »), et le Product Owner, pour qui tout est prioritaire même les points les plus flous. Ici on demande au Product Owner de classer, régulièrement et dans l’ordre qu’il souhaite, les éléments du haut de la liste devant être « ready ».

Vous pouvez consulter le guide SCRUM dans sa version 2011.

Nouvelle certification Agile au PMI

Le PMI (Project Management Institute) est une association mondialement connue spécialisée dans les méthodologies de gestion de projet.
A travers son guide PMBOK, elle propose des bonnes pratiques et une méthodologie regroupant un ensemble de processus classés par domaines d’activités.

Face aux succès des méthodes agiles, une communauté agile s’est formé au sein du PMI et prépare une version 5 agilisée du PMBOK courant 2012.
En outre, le PMI va proposer sa propre certification agile nommée ACP (Agile Certified Practitioner) d’ici la fin de l’année.
Actuellement, les certifications Scrum (proposées par la Scrum Alliance) consistent simplement à assister à une formation de 2 jours donnée par un coach Scrum certifié. Ces certifications sont même de plus en plus discréditées.
La formation ACP consistera en un examen sous la forme de 120 questions à réponses multiples. Il est d’ores et déjà possible de participer au programme pilote, si vous répondez aux critères d’éligibilité. Reste à voir si ce questionnaire sera suffisamment significatif pour avoir une réelle valeur.

Le coin de la technique

Betamax 1.0 refera t’il l’histoire ?

Une nouvelle librairie vient de débarquer en version 1.0: Betamax. Similaire à VCR déjà connu des Rubyistes, Betamax est destiné à ouvrir de nouveaux horizons aux tests unitaires. Cette librairie agit en effet comme un proxy http à ceci près qu’elle enregistre les requêtes et les réponses afin de pouvoir rejouer ces dernières. On voit donc immédiatement l’intérêt: on peut écrire ses tests unitaires pour qu’ils aillent requêter un vrai serveur avec de bonnes données. Ensuite, lorsque le test sera rejoué sur un autre environnement ne disposant pas forcément d’un accès au serveur, c’est Betamax qui se substituera à celui-ci en renvoyant les données qu’il a précédemment enregistrées.
On voit tout de suite l’intérêt que l’on peut tirer d’une telle librairie qui permet de se passer d’écrire un énième mock pour faire ses tests. Par contre, ceux-ci ne sont alors plus si unitaires que ça et pourraient même devenir assez lourd (un serveur -Jetty- est démarré). Il faudra donc sans doutes faire attention à ne pas en abuser.

L’analogie avec le monde de la vidéo est prolongée assez loin: Betamax enregistre par exemple les requêtes dans des fichiers appelés « tape ». Espérons tout de même pour lui que Betamax parvienne cette fois-ci à s’imposer !

Git: à chacun son flow

Vous connaissez Git, le SCM du moment. peut être connaissez vous aussi Git-Flow, un ensemble de raccourcis destinés à donner un cadre à l’utilisation de Git. Scott Chacon, évangéliste chez GitHub, compare sur son blog l’expérience de Git et son l’utilisation qui en est faite chez GitHub par rapport au standard qu’est git-flow. Il s’avère que GitHub dispose d’un flow assez simple:

• Tout ce qui est dans la branche master doit est soit déjà déployé, soit va l’être sous peu. C’est LA règle principale.
• Pour toute nouvelle fonctionnalité, une nouvelle branche est créée à partir de master. Pour peu que les branches aient un nom bien choisi, la page « branch list » de GitHub permet d’avoir rapidement une vue d’ensemble des nouveautés en cours de développement.
• Les commit locaux ET les push vers le serveur sont encouragé. C’est une différence importante par rapport à git-flow. Les push réguliers participent à la volonté de transparence, pour savoir tout le temps ce qui se passe sur le projet et éventuellement pouvoir collaborer.
• Le mécanisme de pull request est un outil inestimable. Il permet de faire des revues de code, des propositions, laisser des commentaires…
• La branche n’est mergée dans master qu’après validation par une tierce personne.
• Une fois la fonctionnalité pushée sur master, vous pouvez et DEVEZ immédiatement déployer. Si vous ne le faites pas, c’est la personne qui suivra qui prendra ce risque. Or, vous ne voulez pas que les problèmes de votre code tombent sur d’autres que vous. On voit donc dans l’article une jolie capture sur laquelle on voit qu’en une journée, des dizaines de déploiements en production ont eu lieu (oui, il y a bien marqué des dizaines de déploiements en production ). A n’en pas douter, nombreux sont ceux que cette performance laissera rêveurs !

Bref, même si Scott Chacon prêche pour sa paroisse en vantant Git et GitHub, il est intéressant de voir comment l’entreprise utilise en interne l’outil qu’elle propose à des tiers.

La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Agilité

• Tout le monde se lève pour Daily

Le coin de la technique

• Avenir de Javascript

Evénements de notre communauté en France et à l’étranger

• JavaPosse #357 : Courage in Software Development

Agilité

Tout le monde se lève pour Daily

Fabrice Aimetti, Consultant agile et serial traducteur sur tout ce qui touche à l’agilité nous offre une nouvelle traduction d’un vieil article de Jason Yip intitulé « It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings ».
Cette traduction parle donc des bonnes pratiques du Daily Stand-up Meeting. Nous passerons vite sur la mise page qui ne fait pas bien ressortir le plan car c’est le contenu qui importe. Et celui-ci est dense ! Si pour vous le principe du « Daily » n’est pas encore très clair, si vous le faites tous les jours un peu au hasard en espérant qu’il soit mieux aujourd’hui que la veille, si son intérêt est remis en cause par les membres de l’équipe… alors vous avez là un outil indispensable. Tous les aspects y sont abordés, avec des exemples d’objections et de solutions:

• Les bonnes pratiques
• les acteurs
• les sujets à aborder
• les horaires
• la motivation

Par contre, n’oubliez pas que « le Daily » ne constitue que l’une des réunions de la méthode Scrum avec le poker planning, la revue de sprint et la rétrospective. Le tenir de façon journalière ne fera en aucun cas de vous une équipe agile si l’esprit de Scrum n’est pas respecté.

Le coin de la technique

Avenir de Javascript

Javascript est un langage que tout développeur Web a déjà pratiqué. On l’apprend souvent sur le tard, plus ou moins dans la douleur, et les ressentis sur ce langage sont très variés.

L’existence du serveur Node-JS, de l’intégration dans le JDK d’un moteur Javascript (Rhino qui devrait d’ailleurs recevoir sous peu des améliorations) et la montée en puissance de HTML5 (voir notre précédent billet) dénotent l’importance que prend Javascript dans la communauté mondiale, et plus seulement dans le développement côté client.

Les développeurs issus des technologies côté serveur se posent beaucoup de questions sur ce langage souvent mal perçu.

Si faire un module Javascript pour encapsuler des données est aisé, créer une classe et faire de l’héritage l’est beaucoup moins (très bon exemple donné ici). On reproche souvent à Javascript sa verbosité et sa complexité de lecture pour cette approche objet.

Mais sommes-nous dans la bonne direction quand nous faisons cela?
Lorsqu’on utilise un framework qui n’offre pas les moyens de réaliser une solution comme on le souhaiterait, il y a deux possibilités :

• soit ce framework n’est pas complet et je peux proposer une évolution
• soit le framework a été volontairement restreint à certaines fonctionnalités car elles représentent le consensus de la communauté sur les bonnes pratiques.

Javascript est un langage à typage dynamique et vouloir le restreindre à une conception objet pure serait lui enlever sa force. Les prototypes en Javascript sont justement présents pour modifier, au cours de la vie du programme, la structure des objets en fonction des besoins.

Il est difficile pour nous autres, développeurs « objet », de ne pas savoir de quel type sera notre paramètre dans une fonction, ou encore de ne pas faire d’héritage. Mais il est de notre devoir de désapprendre ce que l’on a durement acquis sur la POO et adopter une nouvelle approche en Javascript, en acceptant dès le départ son mode de fonctionnement, plutôt que d’y trouver des solutions de contournement.

HTML 5, les API REST avec JSON rendent les langages beaucoup plus communicants en facilitant et standardisant les échanges de données. La coopération est donc inévitable.

Une autre approche existe avec Google GWT qui considère le Javascript comme un langage compilé à partir d’un autre. Javascript serait ainsi le ByteCode des temps prochains ?

Vous pouvez suivre ce long débat sur l’article « JavaScript is Dead. Long Live JavaScript! » de Peter Michaux qui a récemment généré du buzz sur cette thématique.

Evénements de notre communauté en France et à l’étranger

JavaPosse #357 : Courage in Software Development

Le podcast américain populaire aborde le sujet du software craftsmanship sous la forme d’une discussion de groupe lors de leur dernier roundup. On y parle manifeste agile et craftsmanship, DRY (simple design), de l’humilité d’accepter les échecs, de code retreats et du modèle de Dreyfus d’acquisition des compétences. Une discussion intéressante, par l’opposition des points de vue, qui résume assez bien les tendances actuelles autour du mouvement.
A écouter, pour anglophiles, pour une durée d’un peu plus d’1 heure.

Actualité éditeurs / SSII

• IBM dévoile WebSphere 8
• Sortie de Play! Framework 1.2
• Nudge, une plate-forme hébergée de monitoring de performance applicative (SaaS)
• Sortie de Rails 3.0.6 corrigeant une faille de sécurité de type XSS

Le coin de la technique

• Red Hat prépare Ceylon, un nouveau langage pour la JVM

Evénements de notre communauté en France et à l’étranger

• Scrum Day 2011: comme si vous y étiez!

Actualité éditeurs / SSII

IBM dévoile WebSphere 8

Nos confrères du Monde Informatique et du Journal du Net reviennent sur la conférence Impact 2011, qui se tenait à Las Vegas les 12 et 13 avril derniers, au cours de laquelle IBM a notamment présenté les grandes lignes de la version 8 de son célèbre serveur d’applications.

Disponible en version bêta depuis le mois de mars — la sortie officielle étant prévue pour juin — cette dernière version est 100% compatible avec Java EE 6. Parmi la longue liste de fonctionnalités au programme de cette nouvelle mouture, citons le support des standards suivants :

• Enterprise JavaBeans (EJB) 3.1
• Java Persistence API (JPA) 2.0
• JavaServer Faces (JSF) 2.0
• JavaServer Pages (JSP) 2.2
• Servlet 3.0
• JAXB 2.2
• JAX-WS 2.2, et notamment le support de Web Services Security API (WSS API) et WS-Trust, censés faciliter le SSO à l’aide de web services.

WebSphere 8 devrait apporter également:

• une meilleure prise en charge des applications OSGi;
• une meilleure intégration des web services utilisant WS-Security SAML Token Profile 1.1;
• un support de SIP Servlet 1.1 afin de favoriser l’utilisation d’applications de communication;
• le support du cache L2 de JPA à l’aide de DynaCache (le cache par défaut utilisé dans WebSphere);
• une intégration simplifiée avec WebSphere MQ.

IBM semble également avoir voulu contenter les développeurs d’applications (il était temps, diront certains): non seulement le serveur semble démarrer plus rapidement, mais surtout le processus de déploiement a été simplifié, et il sera désormais possible de (re)déployer une application avec un simple drag’n drop.

Sortie de Play! Framework 1.2

La version 1.2 du framework Play! vient tout juste de voir le jour. Pour ceux qui ne le connaitraient pas encore, Play est un framework web orienté haute productivité. Comme son cousin Grails, il repose sur des conventions, est extensible via des plugins et supporte le rechargement à chaud des modifications du code.

Les nouveautés apportées par cette nouvelle version sont nombreuses :

• ajout d’un système de gestion de dépendances basé sur Ivy, permettant de récupérer des modules Play ou toutes autres librairies requises,
• support du Long Polling et des Web Sockets, pour les connections asynchrones,
• introduction d’un mécanisme de gestion des évolutions des schémas de bases de données,
• ajout du concept d’Invocation permettant la mise en place de mécanismes équivalent aux Servlet Filters ou à l’AOP (pour la déclaration des transactions à l’arrivée d’une requête par exemple),
• support des bases H2, maintenant embarquées par défaut,
• possibilité de lancer les tests JUnit directement dans Eclipse (sans passer par la page de tests),
• une meilleure documentation du framework, avec notamment une Cheat-Sheet, toujours accessible en mode déconnecté.

Cette version 1.2 est accompagnée de la version 0.9 du plugin Scala pour Play. Ce plugin permet l’utilisation du langage Scala pour développer vos applications Web avec le framework Play. Outre une meilleure intégration de Scala dans le framework Play, cette nouvelle version du plugin apporte une nouvelle couche d’accès aux bases de données nommée Anorm. Anorm permet l’accès en SQL à vos données et utilise des fonctionnalités du langage Scala (le Combinator Parsing) pour mapper le résultat des requêtes avec vos objets. D’importantes évolutions sont encore attendues dans la prochaine version de ce plugin, qui devrait encore améliorer son intégration et sa documentation.

Cette nouvelle version apporte donc d’importantes améliorations et confirme la simplicité qui est au coeur de la philosophie de Play.

Nudge, une plate-forme hébergée de monitoring de performance applicative (SaaS)

La société Level5 Consulting vient de sortir Nudge, une offre hébergée de monitoring d’applications en production. Les cibles sont des logiciels de type web ou batch développés en Java/JEE.

Utilisateurs, vous aurez à disposition des fonctionnalités permettant de :

• collecter et agréger des temps de réponse,
• identifier les requêtes SQL consommatrices,
• suivre la consommation mémoire et CPU,
• agréger des données par module et/ou processus métier,
• créer de métriques personnalisées par API,
• gérer des alertes et des SLA,
• collecter des informations sur les incidents de production.

Vous bénéficierez aussi d’un support d’expert sur l’optimisation d’application. Vous pouvez dès maintenant découvrir Nudge gratuitement ou bien tester une application de démonstration disponible sur le site de l’éditeur. Pour plus de détails, consultez l’article de Developpez.com sur le sujet.

Sortie de Rails 3.0.6 corrigeant une faille de sécurité de type XSS

C’est le 6 avril que la dernière version (3.0.6) de l’outils Rails est sortie. C’est une version importante puisqu’elle corrige, entre autre, une faille de sécurité. En effet, une vulnérabilité de type XSS (Cross Site Scripting) peut être exploitée si la méthode auto_link est utilisée dans les sources. Cette dernière en effet avait la fâcheuse habitude de marquer automatiquement ses paramètres comme étant html safe, et ce, quelle que soit leur origine: ceux-ci n’étaient donc en vérité jamais contrôlés. Il était donc possible d’exécuter du code javascript malveillant en l’injectant dans un paramètre de type string. Le billet mentionne trois solutions pour palier ce problème: mettre à jour votre version de Rails, installer un patch ou… ne pas utiliser cette méthode

Cette mise à jour apporte quelques autres ajouts, dont vous pouvez retrouver le détail sur le blog du projet.

Le coin de la technique

Red Hat prépare Ceylon, un nouveau langage pour la JVM

Le « buzz » de la semaine c’est bien sûr la diffusion d’une présentation (et de sa deuxième partie) que Gavin King a faite à Pékin lors de la QCon, où il révèle qu’il travaille pour Red Hat à un nouveau langage pour la JVM : Ceylon. Bien que Gavin ne prévoyait pas de parler officiellement du projet de son équipe aussi tôt, il a confirmé la nouvelle ; d’abord sur son blog, puis lors d’une interview pour InfoQ.

Alors de quoi s’agit-il ? La première chose à noter est que Gavin King se défend de vouloir créer le langage du futur pour la JVM ou un « Java Killer ». Il se dit d’ailleurs « fan apologétique » de Java et propose donc Ceylon comme un langage fortement inspiré de celui-ci, sans les frustrations qu’il occasionne. Les principales frustrations étant selon lui :

• les librairies du SDK, vieilles et mal conçues ;
• la difficulté de définir une interface utilisateur en Java (il blâme d’ailleurs le complément quasi-automatique de Java pour beaucoup de besoins : XML) ;
• le manque d’un vrai système de modules (il dénonce à cet égard la complexité de Maven et d’OSGi, en se prononçant en faveur du framework JBoss Modules) ;
• le manque de fonctions d’ordre supérieur et/ou de première classe ;
• la gestion de la concurrence (il fustige le fait que tout objet Java puisse être un sémaphore et juge qu’un langage ne devrait pas avoir de primitives de synchronisation, ce rôle devant selon lui être assumé par des librairies spécialisées) ;
• ce qu’il appelle les « verrues » du langage : getters/setters, tableaux et types primitifs, la gestion des valeurs null, les checked exceptions, la généricité (surtout des points qu’il juge obscurs comme la notion de type erasure ou les wildcards) et le système de typage d’une manière globale.

En pratique — et en résumé — Ceylon propose les points suivants :

• de garder tout ce qui fonctionne bien dans Java et en a fait le succès : la JVM, la garbage collection, pas de pointeurs, le typage statique, la lisibilité ;
• le tout objet : tout est type et il n’y a pas de types « primitifs » (mais on peut encore utiliser void pour spécifier le non-retour d’une fonction) ;
• la possibilité de faire des mixins, c’est-à-dire d’implémenter des méthodes dans des interfaces (tant qu’il n’y a pas besoin d’initialisation) — fonctionnalité sans doute inspirée du Projet Coin ;
• une généricité à la fois plus simple et plus restrictive : les paramètres-types (type parameters) peuvent, à l’aide des mots-clés in et out, être déclarés covariants ou contravariants, ce qui élimine la nécessité de passer par des wildcards, qui n’existent d’ailleurs pas dans ce langage: si Box prend un paramètre-type T covariant, une variable de type Box<Integer> est alors assignable, sans transtypage explicite, à une variable de type Box<Number>. Cela conduit Gavin King à imaginer deux interfaces List<T>, l’une covariante avec T et prenant en charge les opérations de lecture, l’autre contravariante prenant en charge les opérations d’écriture (qui modifient la liste) ;
• une structure intrinsèquement récursive: « une classe n’est qu’une fonction retournant à l’appelant une fermeture renfermant tous ses membres » (à la manière de ce que fait JavaScript) ;
• des fonctions d’ordre supérieur et de première classe : une fonction peut ainsi être passée en paramètre d’une autre fonction, une fonction peut contenir d’autres fonctions (ceci découle de la structure récursive du langage), une fonction peut être assignée à une variable, etc… — cependant, les fonctions anonymes (fonctions lambda) ne sont pas autorisées;
• classes et interfaces peuvent spécifier par avance l’ensemble des sous-types qu’elles peuvent avoir ;
• pas d’opérateur de transtypage (casting), mais la possibilité d’utiliser une structure switch particulière :

switch(maVariable) case (is UnType) {...} case(is UnAutreType) {...} else {...}

• des contrats plus forts :
  • des valeurs ne sont nullables que si explicitement déclarées comme telles (avec un « ? » derrière le type) et il faut alors obligatoirement les tester avec :

    if (exists maVariable) {...} else {...}

  • les attributs d’une classe ne sont modifiables que si déclarés comme tels avec variable, et il faut alors utiliser l’opérateur := plutôt que = pour leur réaffecter une valeur ;
• des niveaux de visibilité simplifiés : shared (public) ou privé par défaut ;
• des getters/setters implicites pour les variables d’instance ;
• pas d’exceptions vérifiées (checked exceptions) ;
• pas de surcharge (overloading) de méthodes mais en revanche des valeurs par défaut pour les paramètres ;
• pas de surcharge d’opérateur mais des équivalents/méthodes que l’on peut redéfinir pour un type les supportant. Par exemple > est équivalent à .largerThan() qui peut être redéfini par les implémentations de Comparable ;
• une syntaxe alternative où il est obligatoire de nommer les arguments des méthodes, ce qui donne au final un langage descriptif que Gavin envisage comme une solution face à XML pour décrire des interfaces — l’exemple suivant, tiré de la présentation de Gavin King, est en effet assez parlant:

Table squares {
    title = "Squares";
    rows = 10;
    Column {
        heading = "x";
        String content(Natural row) {
            return $row;
        }
    }
    Column {
        heading = "x**2";
        String content(Natural row) {
            return $row**2;
        }
    }
}

Au rayon des choses étranges :

• pas de mot-clé new ;
• un seul constructeur autorisé (définitivement pas d’overloading donc), qui plus est fusionné avec la définition de la classe :

class Counter(Natural initialValue) {
	if (initialValue > 100) {
		throw OutOfRangeException()
	}
	...
}

• le support de la curryfication ;
• la documentation est conçue comme partie intégrante du langage (un peu comme dans Noop).

Que penser de cet énième langage fondé sur la JVM?

On retrouve en effet dans Ceylon beaucoup de fonctionnalités également présentes dans d’autres langages dérivés de Java (Scala, Groovy, Gosu, Fantom, pour ne citer qu’eux). On les retrouve aussi dans la réflexion de Stephen Colebourne pour définir un futur grand langage pour la JVM, qu’il a notamment présentée lors de la réunion du Paris JUG du mois de mars.

On constate donc bien que le but n’est pas de révolutionner le monde Java, et par ailleurs beaucoup de critiques ont déjà fusé sur le fait que Scala propose mieux depuis longtemps ou que ce langage propose tellement peu qu’il pourrait être mort-né.

Cela étant, les idées proposées sont plus que jamais d’actualité, et l’initiative étant portée par Red Hat et Gavin King (Hibernate, JBoss Seam), on peut légitimement espérer qu’elle fasse bien plus d’effet qu’un pétard mouillé.

Quoi qu’il en soit, il y a encore beaucoup de travail sur le projet : bien que le langage soit en étude depuis deux ans, aucun compilateur n’a encore vu le jour.

Evénements de notre communauté en France et à l’étranger

Scrum Day 2011: comme si vous y étiez!

Les webcasts du Scrum Day sont en ligne sur le wiki du FSUG. Revivez l’intégralité de l’événement, comme si vous y étiez! Les présentations du grand amphithéâtre ont été filmées, les autres sont diffusées en commentaires audio accompagnés de slides.

Il reste quelques places disponibles sur le site du scrumday, dépêchez-vous si vous n’êtes pas encore inscrit.

Actualité éditeurs / SSII

• Apache Harmony: encore des couacs

Agilité

• Rien ne va plus

Le coin de la technique

• Sortie de MongoDB 1.8

Actualité éditeurs / SSII

Apache Harmony: encore des couacs

On se souvient des déboires récents du projet Apache Harmony: en opposition frontale à Sun puis à Oracle depuis 2007 au sujet du TCK, l’ambitieux projet d’implémentation Java sous licence Apache a vécu une année 2010 plutôt difficile. Jugez-en plutôt: en août 2010, Harmony fait les frais du procès fait à Google par Oracle pour violation de brevets Java au sein de la plateforme Android; la Fondation Apache a eu beau clamer n’y être pour rien, le mal était fait. En octobre, comme nous l’avions signalé ici même, c’est au tour d’IBM de quitter le navire pour rejoindre le très officiel OpenJDK, projet concurrent soutenu par Oracle; un mois plus tard, c’est au tour d’Apple de rejoindre les rangs d’OpenJDK, fragilisant encore davantage Harmony. Puis enfin, après une passe d’armes que nous avions retranscrite ici puis là, nous vous annoncions avec regret, en décembre dernier, que la Fondation Apache, en représailles face à l’immobilisme d’Oracle, venait de claquer la porte du JCP.

Et voilà que la semaine dernière, Tim Ellison, président du PMC (Project Management Committee) du projet Apache Harmony, annonce sa démission, en prétextant le manque de plus en plus cruel d’effectifs et en posant même clairement la question de l’opportunité de déplacer le projet vers le tant redouté mouroir des projets Apache.

Apache Harmony a-t-il un avenir? On peut en effet en douter. Lors de la conférence « TheServerSide Java Symposium 2011 » à Las Vegas mercredi dernier, James Gosling n’a pas mentionné directement Harmony, mais a laissé entendre qu’Oracle avait fait quelques gestes: en direction de la communauté d’une part, avec l’adoption récente des spécifications de Java EE 7; et d’autre part en direction de ses concurrents, en enterrant la hache de guerre avec IBM et Apple.

Ces gestes, bien entendu, auront un prix. Or les intentions d’Oracle face à Google ne sont pas claires. Si les développeurs Android restent imperturbables, il semblerait bien qu’Oracle n’ait pas dit son dernier mot: Adam Messinger, qui s’exprimait aussi pendant la même conférence, a souligné qu’Oracle voyait en grand l’avenir de Java ME; en ligne de mire, on le devine, se trouve la plateforme Android prônée par Google.

Dans ce paysage assombri par les enjeux stratégiques entre poids lourds de l’informatique, et quelle que soit l’issue du différend qui oppose Oracle à Google, Harmony apparaît de plus en plus comme le prix à payer pour que l’on revienne enfin… à l’harmonie.

Agilité

Rien ne va plus

Il y a des semaines comme ça… tout allait bien quand 3 annonces coup sur coup font voler en éclat nos plus profondes convictions. Imaginez qu’enfant on vous apprenne que le Père Noël… Chut ! Ce n’est pas notre rôle de vous le révéler. Toujours est-il que 3 articles sont venus nous secouer récemment. L’agilité que l’on vous vante tant ? Et bien, non, finalement, ce n’est pas le remède miracle. Et Java, notre langage tant aimé ? Finalement, il nous ralentirait plus qu’autre chose ! Mais cela se comprend, c’est la notion même de programmation objet qui ne sert plus à rien ! Voyons de quoi il retourne.

• A la conférence « TheServerSide Java Symposium 2011 », Jon Kern a donné une présentation dont la trame était que l’agilité n’est pas le remède miracle à tous les projets et toutes les situations. Non ?! Et bien si. Il s’en explique d’ailleurs dans une interview donnée quelques jours plus tôt: pour lui, passer à l’agilité requiert un changement dans les mentalités, dans tout le processus projet de l’entreprise. Il évoque aussi la possibilité d’être flexible dans la mise en place de l’agilité mais semble malgré tout d’accord avec John Clifford (dont nous vous parlions récemment) qui mettait en garde contre l’application de seulement quelques morceaux choisis de Scrum et le risque de se croire alors agile.
• Java, notre beau langage, ferait souffrir les entreprises. Il serait trop verbeux, offrirait trop de choix et les projets seraient coûteux et complexes à maintenir. C’est développez.com qui nous rapporte les propos de David Duquenne, DG du groupe Open Wide Technologies. Mais finalement, plus que le langage lui-même, il semble que ce soit l’utilisation qui en est faite, à travers l’incorporation à tort et à travers de multitudes de composants open-source dont on ne maîtrise ni le développement, ni les licences, qui soit à surveiller. Quelques pistes sont évoquées pour éviter ces écueils: l’utilisation de Frameworks (ceux de Open Wide ?!), l’intégration continue, le recours aux approches agiles ou à de nouveaux paradigmes tels que le MDA ou la programmation fonctionnelle.
• La programmation fonctionnelle, parlons-en justement. A l’université de Carnegie Mellon (Pittsburgh), elle remplacera en 1ère année l’apprentissage de la programmation orientée objet, cette dernière devenant optionnelle plus loin dans le cursus. Est-ce un choix raisonnable ? L’article d’InfoQ qui nous apprend la nouvelle ne semble pas complètement d’accord.

Le coin de la technique

Sortie de MongoDB 1.8

MongoDB a annoncé la sortie de la version 1.8 de la base de données NoSQL. La version précédente — 1.6 — datait d’août 2010. Cette nouvelle version ajoute plusieurs fonctionnalités, corrige quelques bugs et améliore nettement certaines fonctionnalités existantes.

Les release notes se trouvent ici. La version 2.5 du driver Java de MongoDB a par ailleurs été publiée la semaine dernière.

La nouveauté la plus attendue et la plus plébiscitée par les utilisateurs de MongoDB est la journalisation: grâce à l’écriture d’un journal des transactions, la récupération après un crash sera beaucoup plus rapide, et la pérennité des transactions sera renforcée au sein du système de stockage.

L’activation de cette option se fait uniquement au démarrage en ajoutant l’option « --journal » à la commande de démarrage. Les fichiers de journalisation seront alors stockés quotidiennement sous le répertoire « journal ». Suite à un arrêt normal du système, ceux-ci seront automatiquement purgés; suite à un crash, en revanche, au redémarrage de MongoDB l’ensemble des transactions décrites dans ces fichiers sera re-exécuté. L’option « repair » ne sera plus nécessaire.

Par ailleurs le sharding, fonctionnalité introduite dans la version 1.6, a bénéficié d’importantes améliorations internes qui permettront une meilleure performance et une meilleure reprise sur erreur, même si ces changements ne seront pas forcément ressentis par tous les utilisateurs.

Et enfin, parmi les autres fonctionnalités, on peut citer le support de l’authentification au niveau des jeux de répliques (replica sets), des nouveautés liées aux index, ou encore la recherche spatiale « sphérique »: jusqu’alors plate, la Terre est enfin redevenue ronde pour MongoDB!

Actualité éditeurs / SSII

• IE6 : End of life !
• cdnjs.com un content delivery network pour javascript

Agilité

• Traiter l’urgence dans une équipe agile

NoSQL

• Infinispan au Paris NoSQL User Group

Actualité éditeurs / SSII

IE6 : End of life !

IE6 Countdown est un site lancé par Microsoft pour mesurer la baisse de part de marché d’IE6 dans le monde (et accessoirement promouvoir IE7 et 8). Ce dernier affiche 3,9% pour la France, alors que la Chine plafonne à 34,5%. Le «_grand gagnant_» est la Norvège, qui affiche seulement 0,7% de part de marché. La firme de Richmond encourage vivement à migrer vers IE7/8, avec pour argument un tableau comparatif, où l’on peut observer que presque aucune feature des navigateurs modernes n’est supportée : gestion des fenêtres par onglets, barre de favoris, compatibilité avec les standards du Web. Les développeurs Web quant à eux, peuvent même rajouter une bannière sur leur site, qui invite les utilisateurs ayant une version d’Internet Explorer antérieure à la 7, à le mettre à jour :

Enfin, bien qu’un grand du Web tel que Google ait récemment cessé de supporter IE6 sur Google Docs et Google Sites (Gmail et Google Calendar suivront dans l’année), le navigateur est encore très largement répandu en entreprise, avec son OS Windows XP. De ce fait, nous ne serions que trop vous conseiller d’inviter vos clients respectifs à monter de version, notamment pour des raisons de sécurité et de compatibilité. Pour les autres, Microsoft assurera tout de même le support jusqu’en Avril 2014.

cdnjs.com un content delivery network pour javascript

cdnjs.com est, comme son nom l’indique, un Content Delivery Network pour javascript : un nouveau service en ligne utilisant l’infrastructure AWS d’Amazon pour mettre à disposition des bibliothèques javascript. Google et plus récemment Microsoft proposent déjà ce type de service, mais uniquement pour les bibliothèques javascript les plus populaires… d’après leur propre usage. L’idée de cdnjs.com est d’apprécier à travers les votes de la communauté les bibliothèques javascript les plus utilisées afin de les héberger. Les sites web utilisant ce service bénéficient alors d’un cache http commun.

Agilité

Traiter l’urgence dans une équipe agile

Serge Beaumont, notre confrère de Xebia Pays-Bas, vient de publier un intéressant article sur les différentes manières de traiter les situations d’urgence dans les équipes agiles. C’est un sujet toujours difficile, car, par définition, la charge de travail requise pour traiter ces situations est inconnue. Donc peu estimable et planifiable.
Il commence son article par regretter la bonne vieille époque des projets waterfall où il n’y avait jamais de maintenance à faire. Ahhh, le bonheur que ça devait être que de travailler sur des projets parfaits, sans bugs, sans… Ah, attendez: une lecture plus attentive précise que c’était en fait l’équipe de maintenance qui était chargée de corriger la pile de non-sens créée par d’autres. Les pauvres…
Sur un projet agile, les livraisons régulières responsabilisent les équipes elles-mêmes qui verront revenir plus rapidement leurs propres erreurs.
Plusieurs scénarios sont envisagés:

• un Product Owner jouant le rôle de « firewall » et élimine bon nombre de problèmes (qui bien souvent n’en sont pas !)
• ce même Product Owner peut mettre les urgences au planning du sprint suivant et n’accepter que les vraies urgences

Pour les vrais problèmes, ceux qu’on ne peut pas éviter de traiter immédiatement, il est envisageable de garder à chaque début de sprint un buffer leur étant destiné. Mais notre confrère nous met en garde sur le fait que ce serait sans doute une fausse bonne idée: dès que votre MOA aura connaissance de la présence de votre buffer, ils n’auront de cesse d’essayer de le remplir. D’où la règle numéro 1 du buffer: le buffer n’est pas pour les éléments du backlog. La règle numéro 2, pourtant extrême, permettra de relativiser l’importance des demandes: un remplissage du buffer entraîne un abandon du sprint en cours. Extrême ? Mais efficace ! Les gens réfléchirons par 2 fois à la priorité de leurs demandes. Le principal reste tout de même de fixer la cause racine et donc d’améliorer la qualité. Logique, non ?

Finalement, l’auteur donne un conseil pour les équipes qui doivent faire beaucoup de maintenance: Kanban bien que proche de Scrum propose un process plus adapté. Nous vous renvoyons à notre article sur « Kanban in action » à Devoxx.

NoSQL

Infinispan au Paris NoSQL User Group

Manik Surtani, est venu au Paris NoSQL User Group présenter Infinispan, la In Memory Data Grid de JBoss dont il est le lead technique. Nous retiendrons :

Objectif : concurrencer Coherence

L’objectif d’Infinispan est de proposer une alternative Open Source à Oracle Coherence, Gigaspace ou IBM eXtreme Scale.

Les topologies

Infinispan propose deux topologies de déploiement :

• Embedded Mode (aka peer-to-peer) : l’application est fusionnée avec la grille de données : les JVM qui portent la(les) application(s) participent à la grille et portent des données. C’est la mode d’intégration qui permet le plus grand nombre de fonctionnalités mais qui apporte aussi le plus grand couplage.

• Client-Server Mode :
• L’application se connecte à la grille de données avec un connecteur comme elle se connecte à des SGBD.
• Il existe quatre protocoles : REST/HTTP, MemCached, Hot Rod (protocole bi-directionnel interne d’Infinispan) et les Web Sockets. Hot Rod sera le protocole le plus riche qui facilitera la haute disponibilité grâce à l’autodécouverte de la topologie de la grille et permettra les continuous queries. Seul Hot Rod impose java côté client. Les WebSockets sont temporairement remises en cause par les failles de sécurité inhérentes à cette technologie. 

Les APIs

Infinispan propose aujourd’hui une API bas niveau de style key-value store et travaille sur une API de haut niveau de style JPA qui manque cruellement à certains concurrents . Ces APIs seraient utilisables en mode « Embedded » et en mode « Client-Server » avec le protocole Hot Rod.

Fort de l’expérience de JBoss sur les annotations JPA et Hibernate Search, on peut espérer une API élégante.

Le plus : Hibernate Search

Infinispan apporte une fonctionnalité originale qui le différencie de ses concurrents : l’intégration d’Hibernate Search qui permet de créer des index secondaires plus sophistiqués que ceux « à la SQL » qu’on voit dans les autres In Memory Data Grids. Il est tout de même probable que cette richesse d’indexation ne concerne que peu de cas d’utilisation.

La road map

Le projet est dynamique et prometteur et il reste encore beaucoup de travail comme :

• l’envoi de traitements dans la grille (map/reduce, entry-processors, etc) qui est encore en version beta,
• le choix de language de programmation pour réaliser des traitements dans la grille. La réflexion se place aujourd’hui autour d’un langage neutre comme javascript ou de java,
• des optimisations de la gestion de la mémoire pour gérer des JVM de grande taille (> 10 Go),
• l’intégration de JBoss Marshalling avec l’ajout d’une API de versioning pour sérialiser les données dans la grille,
• l’ajout d’une query language pour requêter les données.

Scénarios d’utilisation d’Infinispan aujourd’hui

Le principal scénario d’utilisation d’Infinispan aujourd’hui est un « distributed key-value store » qu’on peut même installer sous forme « Data as a Service » pour reprendre l’expression de Manik Surtani.

Les utilisations en In Memory Data Grid haute performance avec des traitements au coeur des données sont a réserver à un public averti .

Agilité

• Craftsmanship, le débat fait rage dans la blogosphère!
• Les dangers qui guettent Scrum

Actualité éditeurs / SSII

• JAX-RS 2.0

Evènements de notre communauté en France et à l’étranger

• Code retreat à Grenoble

Agilité

Craftsmanship, le débat fait rage dans la blogosphère!

Bien que facilement traduisible, littéralement artisanat, le terme Craftsmanship, son application au développement logiciel, son sens profond, son implication au quotidien semblent échapper au plus grand nombre, et même susciter la perplexité ou la controverse. Pour preuve, la multitude d’articles postés sur les blogs ces dernières semaines qui en débattent.

Petit résumé des faits marquants:
Tout a commencé le 11 janvier par le post d’un article de Dan North, Programming is not a craft, dans lequel ce dernier exprime ses craintes et son scepticisme au sujet du Craftsmanship. Ses craintes tout d’abord d’un égocentrisme exacerbé de la part des développeurs ne s’identifiant plus à des créateurs de logiciels mais à une sorte de caste de supercodeurs intéressés uniquement par la beauté intrinsèque du code et non plus par les besoins du client. Il rappelle que les craftsmen doivent être sans égo, humbles, avec comme focus les livrables plutôt que le processus.
Il insiste enfin sur la nécessité de fournir des réponses adaptées au besoin. A un besoin simple, une réponse simple, pas de fioritures, de décorations inutiles, l’objectif est la production de logiciels, pas de l’art. Il ne voit pas d’intérêt dans le Craftsmanship ou plutôt aimerait voir le manifeste réécrit en terme d’obtention de résultats et de satisfaction client.

Robert C. Martin, une des figures emblématiques du mouvement, réplique le 17 janvier dans Software Craftsmanship: What it’s all about et tente une explication de ce qu’est ou n’est pas le mouvement Craftsmanship.
La lassitude d’écrire du code de mauvaise qualité, de faire du « mauvais » boulot, et par ailleurs la volonté de faire les choses bien.
Il réaffirme que le mouvement ne prône pas le fait de mettre le code au centre de tout, d’oublier que notre travail est avant tout de satisfaire le client.
La différence réside dans la non acceptation de faire les choses « mal ». La seule façon de faire les choses vite est de les faire bien.
On atteint la satisfaction des clients en écrivant le meilleur code possible, en faisant la meilleure conception, en testant, en pratiquant pour devenir meilleur chaque jour dans notre travail.
Toutes ces résolutions ont pour objectif la satisfaction client, via un travail personnel, une attitude humble, de remise en question.

Suit le retour de Martin Fowler dans Craftsmanship And The Crevasse dans lequel il s’inquiète également du fait que le mouvement puisse rouvrir la fossé entre le développement et le client que l’agilité avait comblé. En se concentrant trop sur le développement proprement dit, il voit un risque de minimiser le rôle de la communication avec le client, de ne pas atteindre les objectifs.

Réponse de Robert Martin dans Brining Balance to Force dans lequel il rappelle le 4e point du manifeste « We value not only customer collaboration but also productive partnerships » qui selon lui devrait suffire à rassurer et atténuer les craintes. Il insiste également sur la nécessité d’un bon équilibre entre les considérations techniques et non-techniques comme la communication. Tout est une question d’équilibre, les deux sont importantes, il ne faut négliger ni l’une, ni l’autre.

Nous le voyons, les craintes sont importantes sur le sujet et certainement légitimes si l’on regarde les personnalités qui s’en inquiètent. Il y a une grande incompréhension sur l’intérêt même du mouvement par rapport au mouvement agile, avec une peur forte de délaissement des problématiques client. Mais ce qui frappe dans les échanges est le fait que tout le monde est finalement d’accord sur le rôle central du client. On est plus dans l’incompréhension que réellement dans la discorde, Robert Martin s’efforçant d’expliquer que le mouvement Craftsmanship ne va pas à l’encontre de ces préoccupations.

Les risques de dérives existent forcément et il ne faut surtout pas les négliger. Les différentes réactions illustrent un manque de clarté sur la définition même du Craftsmanship, et les interprétations qui peuvent en être faites. Il faut être vigilant et ne pas sombrer dans le tout technique et un faux sentiment de supériorité, néfaste pour tout le monde. Le « JE fais le choses bien. Les autres font n’importe quoi » est à bannir, et est à l’opposé des principes même du mouvement.

D’ailleurs pourquoi opposer qualité des développements avec satisfaction client et résultats ? Est-ce satisfaisant de délivrer une fonctionnalité qui, en terme de fonctionnement général, répond aux attentes de l’utilisateur, mais n’est pas fiable, ne peut évoluer, est difficilement maintenable ? Il est pourtant bien connu que le manque de qualité coûte cher, très cher au final. Alors pourquoi ? La question mérite elle aussi d’être posée.

Nous assistons, depuis quelques années, à une percée très forte des méthodes agiles (Scrum par exemple) dans le développement logiciel. Cet assainissement des pratiques de développement est un vrai succès mais il cache aussi un autre phénomène. Là où les premières heures de l’agilité étaient plutôt orientées sur la pratique du développement avec l’eXtreme Programming, les principales méthodes utilisées aujourd’hui (Scrum et Lean) ne se préoccupent plus trop de la programmation mais plus des processus, la qualité du produit devant en émerger tôt ou tard… ou jamais.

S’ajoute à cela l’arrivée massive de chefs de projet traditionnels, de concepteurs, d’architectes, non convaincus par l’agilité mais persuadés d’y trouver une reconnaissance, une ligne sur un CV. Le problème est que petit à petit, l’agilité est de moins en moins bien appliquée. On fait du Scrum avec des cahiers des charges, des backlogs figés et des vélocités prédéfinies, sans rétrospective… Tests et conceptions sont négligés au profit de la production immédiate… on s’éloigne simplement de l’objectif principal, la production d’un logiciel de qualité, la relation client, pour aller vers moins de pragmatisme, plus de processus.


Le Craftsmanship tend au contraire à revenir aux fondamentaux, prônant la qualité et la productivité face à la production, l’apprentissage et la transmission du savoir, sans pour autant rejeter le mouvement agile dont il est issue.
 Comme l’écrit Robert Martin, le Craftsmanship n’est pas en désaccord avec les méthodes et pratiques agiles, bien au contraire. Si nous regardons un peu l’historique du mouvement, il est issu majoritairement d’agilistes convaincus. Pour parvenir à produire un logiciel de qualité, il est fort probable qu’un craftsman optera pour un processus de développement agile et des techniques issues de l’agilité comme celles contenues dans l’eXtreme Programming. Alors pourquoi ce mouvement?

Tout comme l’agilité, le Craftsmanship est un mouvement de pensée. Il existe, de même, plusieurs écoles, plusieurs façons de l’appréhender. Contrairement à l’agilité, il n’existe pas de méthodes, de pratiques, bien définies du Craftsmanship. C’est avant tout une attitude, un état d’esprit, et c’est à mon avis ce qui complique sa compréhension mais qui le différencie également. Là où les méthodes agiles parlent de travail en équipe, de processus, d’ensembles de techniques, le Craftsmanship est axé sur le développeur en tant que personne. En plus d’un cadre favorable au développement logiciel, le développeur doit être à même de fournir, avec une productivité maximale, le logiciel attendu avec une qualité optimale. Pour ce faire, il se doit de progresser continuellement, d’apprendre de nouvelles techniques pour les utiliser de manière appropriée en fonction du contexte. Les techniques utilisées sont des conséquences de l’attitude, pas un pré-requis. Les craintes exprimées sur l’égo du développeur sont, de mon point de vue, à l’opposé des valeurs mêmes du Craftsmanship qui prône, au contraire, l’humilité, seule à même de permettre la remise en question nécessaire à l’apprentissage, l’évolution continue, le perfectionnement. Avant toute chose, un craftsman, est une personne capable de remettre en question son travail dans le but de progresser et de fournir toujours le meilleur à son client. Ça ne l’empêche pas d’être pragmatique, ni de faire des choix.

Pour résumer: le Craftsmanship ne doit pas nous détourner du client qui doit rester au centre de nos préoccupations. Le perfectionnement des techniques de développement, la remise en question de nos pratiques et l’humilité doivent nous aider à être plus efficace dans la livraison de logiciels de qualité, sans nous détourner du reste.

Les dangers qui guettent Scrum

John Clifford revient, dans un article publié sur le site de la Scrum Alliance, sur une tendance observée assez régulièrement. Nous pourrions appeler cette tendance « on fait du Scrum mais… ». Par exemple :

• On fait du Scrum mais l’équipe ne s’auto-gère pas et le Scrum master assigne les tâches
• On fait du Scrum mais pas de sprint review. L’équipe décide au jugé quand un élément est done

Pour Clifford, Scrum est constitué de 3 rôles, 4 meetings et 4 artefacts. C’est simple. Que dire alors d’une compagnie qui voudrait « faire du Scrum » sans suivre ce carcan minimum ? D’autant qu’il donne aussi des exemples détaillant pourquoi on ne peut pas faire de Scrum à la carte:

• Pourquoi une revue de sprint ? Du code qui fonctionne et qui le prouve est la seule mesure d’avancement qui soit (et pas une TODO liste ou un diagramme de Gantt)
• Pourquoi une rétrospective ? Sans regard en arrière sur nos propres processus, comment pourrons nous les améliorer et devenir meilleurs ?

Pour ajouter à sa thèse, dans l’absolu, il sera sans doute mieux de faire un artifact « de type scrum » plutôt que de ne rien faire. Par exemple, tenir une rétrospective après une échéance projet sera toujours mieux que rien. Tenir une réunion journalière d’un quart d’heure avec l’équipe permettra toujours d’améliorer la collaboration entre ses membres. Mais il ne faudra pas croire que l’on fait du Scrum et blâmer le process si le succès n’est pas à l’arrivée: Scrum est un tout.

Parmi les problèmes de Scrum également rencontrés sur le terrain, on pourra faire le parallèle avec ce post d’Uncle Bob, What Killed Waterfall Could Kill Agile. Il nous rappelle que la mise en place de Scrum implique aussi d’avoir un vrai Scrum Master. Et un Scrum Master n’est pas un chef de projet ! Ce ne sont pas tant les certifications Scrum qui en prennent pour leur grade que l’élitisme de ceux qui les passent pour ajouter cette Certification à leur panel de compétences et espèrent ainsi pouvoir manager des équipes Scrum… Or, c’est l’équipe qui se manage en Scrum ! De la même façon, cet article d’InfoQ paru hier semble mettre tout le monde d’accord sur le fait qu’on ne peut pas être à la fois Scrum Master et Product Owner. Ca semble logique.

Bref, vous l’aurez compris, Scrum n’est pas si compliqué. Et si le projet a la moindre valeur, sans doute, sa réussite vaut-elle le coup de s’impliquer dans Scrum.

Actualité éditeurs / SSII

JAX-RS 2.0

JAX-RS, l’API Java pour les Web Services RESTful a eu une activité riche cette semaine :

JSR-339
Le vote du démarrage de la spécification 2.0 de cette API sous la JSR 339, qui est planifiée pour être intégré avec JEE 7. La date de sortie planifiée est Q2 2012.
La JSR contient quelques pistes pour comprendre la portée de cette seconde version, notamment :

• API Cliente
• Meilleur support des liens entre les ressources (HATEOAS)
• Architecture MVC, avec support de quelques moteurs de template.
• Intégration de bean validation
• Intégration de @Inject (JSR 330)

Plus de détails dans la page de description de la JSR.

Jersey 1.5
La version 1.5 de l’implémentation de référence de JAX-RS 1.x est sortie. Cette version contient essentiellement des correctifs et est destinée à être associée à la future livraison de GlassFish 3.1 (ChangeLog)

Byebye Paul
Enfin, Paul Sandoz, la figure de proue de Jersey, quitte Oracle et son rôle de co-spec lead.

Evènements de notre communauté en France et à l’étranger

Code retreat à Grenoble

C’est souvent sous la contrainte que l’on devient créatif: l’improvisation dans le jazz, isolé sur une île de déserte. On trouve toujours une nouvelle voie! C’est ce qu’il s’est passé au code retreat de Grenoble organisé par CARA (Club Agile Rhône Alpes) et le JUG. La journée était animée par Johan Martinsson, Rémy Sanlaville et Miguel Moquillon.

Nos contraintes:

• Après 45 minutes de programmation en binôme, effacez ce que vous avez codé et changez de partenaires.
• Les règles à respecter lors du codage sont celles du simple design :
• Tous les tests passent.
• Pas de duplication de code.
• Le code exprime toutes les idées que veut exprimer l’auteur (bon nommage).
• Minimaliser les classes et méthodes.

L’exercice à traiter était le jeu de la vie, dans un langage librement choisi. Principalement réalisé en Java, il y avait aussi Pharo: une implémentation de Smalltalk, et Ruby.

L’intérêt du jeu de la vie est qu’il peut être abordé de plusieurs façon et avec plusieurs implémentations et choix de structures de données possibles. Pour les plus téméraires on peut même commencer à introduire des formes animées dans le jeu.

Croyez moi qu’en 45 minutes vous n’avez pas le temps d’arriver jusque là. Alors bien sûr cela crée une frustration qu’il faut apprendre à gérer en focalisant son énergie ailleurs.

En effet, tout au long de la journée, l’intérêt de chaque session (aux nombres de 7), est d’oublier ce que l’on a fait précédemment et de coder le problème d’une manière différente avec un nouveau binôme. Un autre avantage est que parfois, passant par la même implémentation, vous trouvez une façon d’aller plus vite ou une amélioration.

A souligner que le time boxing, de la plus haute importance dans ce genre de session, a été très bien géré par l’équipe d’animation.

Une rétrospective de 15 minutes à la fin de chaque session permettait de discuter autour de solutions qui avaient émergé, de la démarche de test, de nouveaux raccourcis IDE et d’ébauches de futures solutions.

A la fin de la journée, une rétrospective générale a permis de dégager un consensus autour de certains points :

• Une frustration de ne pas pouvoir aller plus loin dans l’implémentation! Mais là n’était pas le but de l’exercice.
• Une reconnaissance que le non attachement à son code (obligation d’effacer le code) aide à rester ouvert, à se remettre en question

et donc à progresser.

• Qu’il faut écrire des tests unitaires simples et rapides.
• Qu’il faut écrire les tests unitaires de façon incrémentale (baby steps). Cela permet de ne pas se perdre dans de longues périodes de rouge.
• Que l’on apprend toujours quelque chose sur soi-même ou de nouveau quand on programme en binôme.
• Que la pratique du TDD se transmet et s’apprend très bien en binôme.

L’idée semble bonne, mais j’ai quelques appréhensions :

• Les convives vont réaliser et consommer le repas, gommant ainsi la distinction client – fournisseur
• Un repas est un produit assez différent d’un logiciel informatique
• Le temps va être très court
• La méthode traditionnelle de préparation d’un repas est on ne peut plus waterfall (idée – recettes – courses – cuisine – repas), de plus elle est parfaitement adaptée.

Après réflexion, nous affinons le concept et décidons de faire tout depuis zéro, avec le minimum de préparation initiale. Exit donc le menu prédéfini : nous verrons bien quel repas émergera, nous nous concentrerons sur nos attentes et nos envies. La vision Waterfall doit être la plus minime possible donc nous ne partirons pas d’un menu initial ni de recettes (nous partons du principe que nous sommes compétents en cuisine, ce qui est le cas).

Les participants devront à la fois être les clients et les réalisateurs, à la fois maîtrise d’œuvre et d’ouvrage ? Soit, nous endosserons les rôles alternativement, nous passerons de la cuisine à la salle à manger, cela nous donnera un point de vue des deux cotés. Nous pourrons pratiquer des itérations courtes, entre lesquelles nous dégusterons ce que nous avons déjà pu préparer (cela nous servira de démo), puis nous ferons une rétrospective de l’itération et une discussion et priorisation du backlog pour la suite du repas. Nous assimilerons les plats à réaliser aux fonctionnalités d’une application.

Myriam sera la Product Owner, et je serais le Scrum Master / Coach.

Ma foi, cela semble se tenir, alors allons y !

La mise en place

Nous nous fixons en amont sur le programme suivant :

• Nous serons quatre participants :
• Myriam : commerciale dans l’industrie,
• Sylvie : agent territoriale dans le sud de la France,
• Jean : docteur en science cognitive et knowledge manager,
• moi-même : Scrum master.
• Myriam réalisera les courses de base avant la soirée, sans fixer de menu
• Chaque participant ramènera un ou deux ingrédients de son choix (cela symbolisera les compétences individuelles amenées au projet et les envies personnelles)
• Nous effectuerons ensemble un sprint 0 d’une heure et demie, dans lequel nous exposerons nos attentes quant au repas, nous définirons globalement sa structure, constituerons un premier backlog priorisé, et estimerons la quantité de travail à réaliser. et éventuellement ferons les courses complémentaires à l’épicerie de quartier
• Nous allons faire des itérations d’une demi-heure de cuisine, découpées en 3* 10 minutes pour laisser la place à un standup meeting rapide,
• Nous nous attablerons entre chaque itération pour profiter du repas en rendossant notre rôle de convive, puis nous prioriserons le backlog, et ferons une rétrospective rapide
• Notre produit (le repas) devra être opérationnel à la fin de chaque itération (ambiance, nourriture, boissons, etc.)

Nous commençons donc l’expérience à 18h30, par un brainstorm de ce que l’on attend et de ce qu’on peut faire en fonction des ingrédients à notre disposition : les idées fusent et nous constituons un premier backlog.

Nous priorisons ensuite les idées selon ce que nous avons le plus envie de manger (la valeur métier), et nous faisons un premier chiffrage. pour cela, n’ayant pas de cartes de poker, nous avons utilisé des pièces de monnaie de centimes d’euro : 1, 2, 5, 10, 20, 50.

Il nous faut également une définition of DONE, nous choisissons la suivante :

• La vaisselle doit être faite
• L’espace de travail doit être nettoyé
• Les plats (ou préparations) doivent être couverts et gardés
• L’effort de présentation du plat doit être fait
• Les plats chauds doivent être conservés chaud

Avant chaque itération, nous réalisons le découpage en unité de travail sur les post it, et nous utilisons un mur blanc comme scrum board de fortune :

Le résultat

Je ne reviendrai pas en détail sur toutes les péripéties de la soirée, mais je vais vous présenter le résultat de chaque itération :

Première itération (20h45)

Réalisations

• Table mise en position basse et décorée,
• Une tapenade évoluée en apéritif, accompagnée de tomate cocktail
• Des mises en bouches préparées mais non cuites

Bilan

Le repas est à l’état « apéro », cela nous fait du bien de commencer à manger, la table est belle et c’est sympa de manger assis sur le tapis moelleux.

Nous constatons que la tapenade est excellente, pourtant elle a été réalisée à 4 mains (entre la découpe des ingrédients, le mélange et l’assaisonnement)

En rétrospective nous remontons qu’il faut veiller à l’embouteillage autour de l’évier, où se trouve la poubelle. nous prenons comme action de créer une autre poubelle hors du passage. de même nous n’avions pas de musique : il est décidé que jean aura la responsabilité d’assurer l’ambiance sonore.

Deuxième itération (21h45)

Réalisations

• La table est rehaussée et mieux décorée,
• La tapenade est désormais accompagnée de poivrons confits à l’ail
• Les bouchées chaudes sont servies
• Nous avons maintenant de la musique

Bilan

Chacun a préparé 4 bouchées selon ses envies, et tout est très bon. les poivrons tièdes rehaussent parfaitement la tapenade. finalement, nous avons bien avancé dans la préparation de la suite, tout est quasiment prêt pour la troisième itération, il ne reste presque plus qu’à cuire et attendre.

Troisième itération (22h30)

Réalisations

• La table est nettoyée et les assiettes sont lavées,
• Le plat principal est servi : poulet caramélisé accompagné de poire saisies dans l’huile des poivrons et de pain libanais
• Le fromage est servi ensuite : camembert rôti aux échalotes accompagné d’endives
• Puis vient le dessert : mignardises

Bilan

itération assez peu chargée, surtout attendre la fin de cuisson. ambiance légère et agréable, aucune difficulté constatée.

Conclusion

Tous les convives ont été très surpris de la qualité finale du repas : tous les plats étaient excellents. Nous avons pu réadapter nos idées en cours de repas, ainsi le trou normand envisagé lors du brainstorm s’est finalement transformé en dessert. Nous avons abandonné certaines idées trop coûteuses ou impossibles à réaliser dans le temps imparti.

Tous les ingrédients apportés par les convives ont été utilisés, de même qu’une grande partie du fond d’ingrédients disponible.

La cuisine a terminé dans un état acceptable et ne nécessitera pas de gros ménage.

Myriam a pu obtenir la recette de la tapenade de Sylvie.

Il y a eu une très bonne coordination et tout le monde s’est naturellement impliqué dans le repas. Les problèmes ont resurgi très tôt et ont pu être traités : les problèmes d’intendance d’une part (organisation de la cuisine, gestion des déchets), mais aussi les problèmes d’organisation. Par exemple, lorsqu’un participant a voulu reprendre naturellement la direction des opérations, nous avons pu désamorcer très facilement, et poursuivre l’expérience dans le cadre que l’on s’était fixé.

Le planning initial a été respecté, tout a été prêt à temps et le timing du repas était très bon, nous avons vraiment pu passer à table à la fin de chaque itération.

Ainsi, tout le monde a été assez impressionné par le résultat final obtenu – sachant que nous n’avions rien préparé ni discuté en avance – et par la cohérence du produit final.

Une chose est certaine, plusieurs apports annoncés par Scrum ont bien été constatés :

• Qualité du produit fini
• Simplicité des solutions mises en œuvre
• Coopération et collaboration favorisées
• Partage des connaissances

Certes, dans le contexte d’un repas, une telle méthodologie ne vaut que pour l’exercice. La composante auto-réalisatrice est sûrement également à prendre en compte dans le succès de l’expérience, de même que la cohésion forcément forte dans une équipe d’amis et le peu de contraintes liées au contexte. Cependant le résultat final est indéniable : l’expérience fut très concluante.

Le mot de la fin revient aux convives de la soirée, que je remercie au passage pour leur participation :

Sylvie :  » Quand je raconterai comment les Parisiens s’y prennent pour faire la cuisine !!  »

Jean :  » J’avais peur qu’il faille se dépêcher pour manger, j’aime prendre mon temps et heureusement la méthode nous a fait gagner du temps ENTRE les plats  »

Myriam :  » Un super repas chez moi, mais où les invités font le repas et la vaisselle, je dis oui!  »

Les rétrospectives pourront ainsi aider les équipes à améliorer leur productivité mais aussi les compétences de ses membres ou encore la qualité de ce que l’équipe produit. Leur but va donc bien au delà d’une analyse post-mortem d’une itération de développement de laquelle découlerait une amélioration des processus de développement.

Dans cet article, nous allons vous donner quelques clés pour vous aider à comprendre les enjeux et à mieux piloter vos rétrospectives.

L’origine des rétrospectives : le Kaizen ou la pratique Lean de l’amélioration continue

La rétrospective telle que nous la connaissons dans les méthodologies de développement agile tire son inspiration dans le milieu industriel et plus particulièrement automobile avec l’outil nommé Kaizen venant du Japon et faisant partie de l’outillage de la méthodologie Lean. Le Kaizen, littéralement « changement bon » est une méthodologie d’amélioration continue dont Toyota fut l’un des précurseurs.

Le Kaizen repose sur différents principes :

• tenter d’améliorer chaque règle de travail (working agreements),
• développer les compétences et l’implication de toute l’équipe,
• se focaliser sur la cause racine des problèmes,
• améliorer les processus afin de gagner en productivité.

Cette démarche de développement continu introduit le changement de manière graduelle et ne repose donc pas sur des réformes complètes et brutales du système du type «on efface tout et on recommence». Dans cette démarche, chaque travailleur est impliqué et est force de proposition pour améliorer sa manière de travailler.

Les méthodes agiles ont repris ce principe pour l’intégrer au sein du cycle de développement. Dans la méthodologie agile Scrum par exemple, une itération de développement, est constituée de différentes cérémonies :

• une session d’estimation en début d’itération,
• un stand up meeting chaque jour,
• une démonstration des fonctionnalités développées,
• une rétrospective.

La rétrospective est donc une partie intégrante du cycle de développement, et du travail de l’équipe.

Pourquoi mettre en place une démarche d’amélioration continue ?

Nous vivons dans un monde où les besoins de nos clients, les technologies ou encore la concurrence évoluent en permanence. Dans ce contexte, il est donc nécessaire de faire évoluer nos méthodes de travail afin de rester en phase avec les attentes du marché.

De plus, le fonctionnement d’une équipe est rarement parfait, il peut exister des tensions, des malaises, des regrets et d’autres sources de démotivation que les rétrospectives peuvent aider à découvrir et à traiter. La motivation d’une équipe est effectivement quelque chose qui s’entretient en supprimant les causes de démotivation, et non en essayant de motiver coûte que coûte en faisant fi des problèmes.

Différents axes de progression sont possibles lorsque l’on cherche à améliorer le fonctionnement d’une équipe de développement comme par exemple :

• la productivité de l’équipe,
• les compétences et les connaissances de chacun,
• la cohésion de l’équipe et la collaboration de ses membres,
• la communication interne ou externe,
• la qualité de ce qui est produit,
• l’intérêt et la motivation des collaborateurs,
• les règles de travail (working agreements),
• etc.

Cette liste est loin d’être exhaustive et bien d’autres axes de progression peuvent être abordés au cours des rétrospectives.

Les rétrospectives permettent d’explorer différents axes de progression et permettent aux équipes de s’accomplir au mieux dans chacun d’eux. Avant de continuer, nous allons nous intéresser à la manière dont l’un de ces axes pourrait être abordé et ce qui pourrait en découler.

L’amélioration de la productivité de l’équipe

Avec l’évolution actuelle des méthodes de développement, qui portées par des mouvements tels que le Craftsmanship tendent à nous orienter vers une culture du travail bien fait, la recherche de la productivité pourrait être perçue comme allant à contre courant. Bien évidemment il n’en est rien si on part du principe que cette recherche de productivité ne va pas à l’encontre de la qualité et si elle s’inscrit dans la durée. En effet, une mauvaise productivité peut être le signe de nombreux problèmes que les rétrospectives peuvent aider à mettre en exergue et à résoudre.

Pour commencer, qu’appelle-t-on « mauvaise productivité » et qu’est ce qu’une « bonne productivité » ? Ces notions sont particulièrement subjectives et il est difficile d’établir une règle permettant de les définir. Nous recommandons donc de s’attacher à étudier l’évolution de la vélocité de l’équipe de développement plutôt que sa valeur absolue. Cette notion de vélocité est utilisée dans des méthodes de développement agile comme Scrum. Elle représente la somme de travail effectuée sur des tâches terminées (selon la Definition of Done de l’équipe).
Une évolution à la hausse de cette vélocité peut indiquer une prise de maturité de l’équipe par rapport au projet, un projet sain etc.
En revanche, une évolution à la baisse pourra soulever des problèmes de qualité (probablement dûs à une dette technique élevée), des conflits au sein de l’équipe, des problèmes d’organisation, etc.

L’étude de cette évolution devra se faire sur plusieurs itérations afin de permettre à l’équipe d’en tirer des conclusions pertinentes. En effet, une vélocité en dents de scie pourrait par exemple mettre en avant des développements rapides mais de piètre qualité, suivis d’itérations où l’équipe corrige les anomalies qui en découlent.

Une fois les problèmes détectés et les causes analysées, l’équipe cherchera des idées afin d’y remédier et mettra en place des actions permettant d’améliorer la productivité. Nous verrons dans la suite de cet article les méthodes permettant de conduire cette réflexion et d’établir les actions à entreprendre.

Pourquoi ne pas se contenter d’appliquer les « bonnes pratiques » ?

Dans le but de rester performant et concurrentiel, pourquoi ne pas se contenter d’un peu de veille et d’appliquer les différentes pratiques reconnues comme efficaces et développées par les experts des méthodologies de développement ?

Premièrement, il existe un nombre très important de bonnes pratiques et il est impossible de toutes les appliquer. De plus, les méthodologies n’étant pas toujours compatibles entre elles, nous nous retrouverions souvent à devoir faire un choix cornéliens entre telle ou telle méthodologie. Enfin, ces méthodologies elles même évoluent en permanence et nous incitent par la même occasion à faire de même, nous plongeant dans une spirale sans fin d’adoption de nouvelles méthodes de travail à appliquer « by the book ».
Une approche plus pragmatique est donc conseillée. Elle consiste à essayer et adapter tout ou une partie de ces méthodes, en réponse à un besoin ou à un problème. Ce dernier point est particulièrement important, les réponses apportées par une méthodologie doivent effectivement découler d’un problème levé par l’équipe de développement. Il n’est donc pas nécessaire d’apporter une réponse (nouvelle méthodologie) s’il n’y a pas de problème.

Deuxièmement, les équipes de développement sont différentes les unes des autres. Les personnes qui les constituent, le contexte du projet, les technologies employées, la culture de l’entreprise etc. sont autant de paramètres à prendre en compte dans le choix d’une méthodologie plutôt qu’une autre. Il est donc impératif que l’adoption d’une méthodologie soit unanime et non imposée. Prenons l’exemple du pair programming, cette méthodologie qui consiste à développer en binôme est assez peu répandue malgré ses vertus. Son adoption est souvent difficile pour plusieurs raisons : incompréhension de la direction, acceptation nécessaire du regard critique de son binôme sur notre manière de développer, adoption d’un rythme différent, etc. Sans un engagement complet de l’équipe, il ne sera pas possible de mettre en œuvre ce genre de méthodologie. Si les membres de l’équipe n’y adhèrent pas, il sera difficile de la mettre en place.

Devant l’opulence des méthodologies et les différences entre les équipes de développement, il est nécessaire de continuellement adapter nos méthodes de travail et d’en expérimenter de nouvelles. C’est précisément le but des rétrospectives, que nous allons étudier dans la suite de ce document.

Le principe « inspecter et adapter »

L’amélioration continue fait appel à la rétrospective comme outil d’analyse et de prise de décision. Elle repose globalement sur les phases suivantes :

• identification des problèmes,
• détermination des causes d’origine ( root cause analysis ),
• définition des actions à entreprendre pour remédier à la cause racine.

Cette méthodologie nécessite une importante dose de courage afin d’aborder les problèmes et leurs causes racines. Il peut en effet être éprouvant d’effectuer cet exercice – qui est malgré tout nécessaire – car si les problèmes de fond ne sont pas abordés, l’équipe est condamnée à ne plus progresser.
Cette constatation rejoint le paradoxe de Stockdale qui peut être défini de la manière suivante :
« Nous devons croire en nos capacités à réussir » et en même temps « être capable de se confronter à la plus brutale des réalités, quelle qu’elle soit ».

La démarche d’amélioration continue nécessite donc que les problèmes ne soient pas « cachés sous le tapis » mais bien au contraire, exposés au grand jour afin de trouver leur origine et les actions à entreprendre afin de les régler.

Les working agreements

Un peu plus tôt dans cet article, nous avons parlé des règles de travail ou working agreements et nous allons maintenant les définir.

Les working agreements sont des valeurs et accords érigés par l’équipe de développement. Ils appartiennent à l’équipe et ont pour rôle de responsabiliser chaque membre. Certains accords définissent des interactions et processus entre les différents acteurs du projet dans le but d’optimiser l’efficacité de l’équipe. Ces working agreements se développent et s’ajustent au fil du temps. Afin que tout le monde les ait en tête, on peut les afficher sur un tableau à la vue de tous.

Voici quelques exemples de valeurs : qualité, simplicité, travail d’équipe, courage. Ou encore quelques exemples de règles: heure et lieu du stand-up meeting, définition d’une* user story “done”, disponibilité du product owner, etc. Il peut être utile, voir nécessaire de définir des workings agrements dans le cadre d’une rétrospective lorsque l’équipe manque de discipline.

Structure d’une rétrospective

La rétrospective fait partie intégrante du cycle de développement. Elle se déroule à la fin de chaque sprint ( ou itération). Au démarrage de la rétrospective, l’animateur définit l’agenda, les enjeux et les objectifs de la rétrospective, et peut être amené à rappeler les working agreements. Le début de la réunion peut aussi être propice pour faire une petite synthèse du dernier sprint et remercier l’équipe pour ses efforts.

Basées sur le principe Inspect and Adapt présenté précedemment, les rétrospectives sont structurées en cinq étapes amenant l’équipe à identifier les problèmes et dysfonctionnements et à trouver des solutions afin d’améliorer le processus de développement. La rétrospective est une réunion timeboxée, la gestion du temps est très importante.
Ci-dessous, vous pouvez observer les cinq étapes d’une rétrospective, ainsi qu’un pourcentage de répartition de chacune sur la durée totale de la réunion:

• définir la réunion (5%) : définir l’agenda, les enjeux et les objectifs de la rétrospective, et rappeler les working agreements si nécessaire,
• collecter les données (30-50%) : créer une vision globale et partagée de tous,
• trouver des idées (20-30%) : identifier les forces et les faiblesses, analyser les causes et trouver des solutions,
• décider des actions à mener (15-20%) : sélectionner quelques actions à mener aux prochains sprints,
• conclure la rétrospective (10%) : dé-briefer sur la réunion, noter les décisions et remercier les participants.

Par ailleurs, il peut être utile de garder du temps (5-10%) en réserve pour se prémunir des débordements.

L’organisation spatiale de la salle de réunion est aussi une donnée à ne pas négliger. En effet, une barrière physique peut rapidement devenir une barrière mentale. Éviter les salles de type « théâtre” et privilégier un espace circulaire ou semi-circulaire pour que tout le monde puisse se voir et communiquer facilement.

Les activités

A chaque étape d’une rétrospective sont associées des activités. Armé de papiers, de crayons, et de post-its, l’équipe travaille et réfléchit dans un cadre ludique et studieux. Selon la taille de l’équipe, et afin de favoriser la participation de tous, des sous-groupes peuvent être formés temporairement pendant la réalisation d’une activité. D’autre part, les activités sont sensées permettre d’apporter de nouvelles perspectives et un cadre pour aider les participants à réfléchir ensemble. Il peut y avoir plusieurs activités par étape.

Les activités sont étudiées pour répondre aux principes ARCS :

• Attention : Garder la concentration des participants,
• Relevant : Pertinent par rapport aux objectifs,
• Competence : Tous les participants peuvent accomplir les tâches,
• Satisfaction : Ne pas avoir le sentiment d’avoir perdu son temps.

Un prochain article présentera de manière plus détaillée chacune des étapes d’une rétrospective, et nous verrons aussi des exemples d’activités.

Les rôles du retrospective leader

L’animateur de la rétrospective (ou retrospective leader) n’est pas nécessairement le Scrum Master. Ce rôle peut tourner entre les différents membres de l’équipe.

Préparer la rétrospective

La première fonction du leader est de préparer la rétrospective. Pour deux heures de réunion, il faut parfois compter la même durée pour la préparation. Il définit alors les activités de la rétrospective en fonction de divers paramètres comme la taille de l’équipe, la complexité du projet, et choisit les activités. Pour se prémunir des débordements durant la réunion, une astuce est de sélectionner en seconde option des activités plus courtes.

Animer le groupe de travail

La seconde fonction du leader est d’animer la réunion. Tout d’abord, il contrôle le temps passé sur chaque activité. Cette tâche peut aussi être déléguée à un autre participant. Par ailleurs, il est le garant des Working Agreements et s’attache à les faire respecter par tous.
Avant de commencer une activité, l’animateur présente son déroulement et rappelle les objectifs de celle-ci (exemple: collecter un ensemble de données réparties sur une période afin d’obtenir une vision partagée par tous). Pendant l’activité, il répond aux questions et observe attentivement le niveau de participation. Il peut aussi être amené à recadrer l’activité en cas de débordement.

Le facilitateur

En tant qu’animateur d’un groupe de travail, le leader a aussi un rôle de facilitateur. Le facilitateur est une personne neutre qui ne prend pas parti, et n’expose pas son point de vue durant la réunion. Il met en place des méthodes pour aider le groupe à travailler efficacement. Pour parvenir à cela, il encourage la participation de tous, favorise la compréhension mutuelle et cultive la notion de responsabilité partagée.

L’art de gérer le « facteur humain »

Les individus d’une équipe en tant qu’êtres humains ont des émotions et sentiments. Les rétrospectives exposent un certain nombre de problèmes d’origines variées. Elles sont parfois sources de tensions et de conflits au sein de l’équipe. Chaque individu étant unique, celui-ci réagira différemment à une situation donnée. La manière de gérer les rapports humains et la communication avec les autres sont des enjeux importants pour que la réunion apporte une réelle valeur à l’équipe et au projet. On comprend alors la nécessité pour l’animateur de faire preuve d’empathie, d’avoir un sens de l’observation, et une certaine maîtrise de soi.
Son rôle consiste alors à désamorcer les tensions et attaques directes, qui n’apportent rien aux problèmes de fond. Il peut aussi amener les individus à exprimer leurs émotions de manière subtile, afin de libérer en eux des ressentiments inexprimés. Par exemple, au lieu d’employer la question directe à un membre: « Qu’as-tu ressenti durant ce dernier sprint ? », utiliser plutôt celle-ci: « Quels sont les moments importants qui t’ont le plus marqué négativement et positivement ? ». Bien sur l’animateur n’est pas responsable des émotions de chacun. Il ne peut pas les contrôler, mais il doit faire en sorte que la réunion reste productive.
Par ailleurs, il peut s’appuyer avec parcimonie sur des méthodes et techniques psychologiques. Sans rentrer dans le détail de cette science, voici deux exemples pour illustrer notre propos.

Le langage Je/Il

Version Il: « Julien n’a pas arrêté de casser le build ! »
Version Je: « J’avais peur que nous rations notre objectif, car nous avons eu beaucoup de build cassés. »
Encourager l’emploie du pronom « Je » plutôt que « Il ». En effet, le « Je » centre le débat sur l’observation et l’expérience de l’intervenant, plutôt que de blâmer une personne. Lorsque quelqu’un critique ou attaque personnellement une autre personne, il faut intervenir et recadrer la discussion sur le contenu, afin de découvrir les causes réelles d’un problème.

Le triangle de Karpman

Le triangle de Karpman représente trois rôles: La victime, le persécuteur, et le sauveteur.
C’est un modèle qui tend à exprimer, que si une personne utilise un de ces rôles (par exemple la victime), elle entraîne l’autre à jouer un rôle complémentaire (le Sauveur ou le Persécuteur). Il peut aider à comprendre les mécanismes ayant généré un conflit. Ainsi, L’animateur avisé pourra éviter de rentrer dans le rôle du sauveteur, chose qui arrive bien souvent quand un membre s’en prend à un autre.

Conclusion

Dans ce premier article, nous avons introduit ce que sont les rétrospectives et leur utilité. Nous avons vu que les rétrospectives s’inscrivent dans une démarche d’amélioration continue. Elles permettent aux équipes et aux membres qui les composent de progresser et de mieux collaborer.
Nous avons aussi vu que les rétrospectives s’articulent autour du principe Inspect and Adapt qui nous force à réaliser une analyse en profondeur des problèmes avant de leur apporter des solutions.

Ces rétrospectives sont animées par un Leader ayant pour rôle de faire en sorte que le temps investi dans la rétrospective soit rentabilisé au mieux (ceci commence par le respect du temps imparti). Le retrospective leader est aussi responsable du choix des activités et du bon déroulement de la séance de travail.

Dans le prochain article, nous détaillerons les différentes phases des rétrospectives et nous vous proposerons quelques activités inspirées du livre d’Esther Derby et de Diana Larsen, Agile Retrospectives: Making Good Teams Great.

Ce livre est le fruit d’un travail collaboratif. Auteur de la préface, Jeff Sutherland, père fondateur de Scrum, et partenaire de Xebia sur les problématiques agiles, a suivi de près la réalisation de ce livre et en recommande la lecture pour tous ceux qui souhaitent améliorer la qualité des logiciels qu’ils développent, la satisfaction de leurs clients et le plaisir de leurs équipes ».

Cet ouvrage, à la frontière de l’informatique et du management, a pour objectif d’introduire les principes de la méthode de gestion de projets Scrum, sans technique et de manière très abordable.

Écrit comme un roman, il raconte l’histoire de Mart Versteeg, directeur technique d’une société éditrice de logiciels, qui doit surmonter de nombreuses difficultés avec un projet déjà terriblement en retard. Il fait la rencontre d’un coach spécialisé en méthode Scrum, qui va l’aider à changer radicalement son organisation, et du coup à résoudre un certain nombre de problèmes auxquels il se heurtait…

Si vous êtes intéressés, vous pouvez dès à présent le commander sur internet, il est disponible chez tous les libraires classiques et vous sera envoyé à sa sortie en début d’année prochaine..

• Formation Scrum Master certifiante animée par Jeff Sutherland, le père fondateur de la méthode, les 13 et 14 décembre.
• Formation Scrum Product Owner animée par Arlen Bankston les 18 et 19 novembre.

Si l’une de ces formations vous intéresse ou que vous souhaitez de plus amples informations, n’hésitez pas à nous contacter au 01.53.89.99.99 ou en consultant notre site xebia-training.fr.

Actualité éditeurs / SSII

• IBM rejoint le projet OpenJDK

Agilité

• Comment vendre Scrum à votre manager

Le coin de la technique

• Percolator, l’indexation incrémentale du Web selon Google
• Maven 3
• Netbeans 6.10 sera finalement Netbeans 7
• Gaelyk, le cloud facile

Actualité éditeurs / SSII

IBM rejoint le projet OpenJDK

IBM a fait savoir hier soir par communiqué de presse qu’il rejoignait le projet OpenJDK à la suite d’un accord avec Oracle portant sur la mutualisation de leur efforts pour améliorer la plate-forme Java.

Cette annonce est pour le moins inattendue après les troubles qu’a connus la communauté Java cet été lors du conflit opposant Oracle à Google. Beaucoup voyaient alors cet évènement comme le signe d’un manque d’ouverture de la part d’Oracle pouvant nuire à l’avenir de Java. A l’inverse cette alliance entre Oracle et IBM devrait rassurer les entreprises quant à la pérennité de la plate-forme Java.

Les premières réactions sont arrivés rapidement. Mark Reinhold (leader du projet OpenJDK) s’est montré très enthousiaste à l’idée de cette collaboration. La veille, il avait d’ailleurs apporté quelques précisions quant à la mise en oeuvre du plan B, largement plébiscité par la communauté.

Un autre observateur met en avant le fait que depuis la création du projet OpenJDK il y a quelques années, la majorité du code à été commité par des ingénieurs de Sun/Oracle. L’arrivée sur le projet d’ingénieurs, avec en bagage leur expérience sur la JVM d’IBM, devrait donc constituer un apport de ressources très important pour OpenJDK.

Au-delà de la mutualisation des ressources, cet accord aura des conséquences politiques bénéfiques. En effet, beaucoup craignaient pendant un temps que le développement du JDK 7 sans JSR associée nuise à la concurrence puisque les JVM alternatives n’auraient alors plus de spécification sur laquelle se reposer. L’annonce d’IBM tend à résoudre ce problème puisque l’on passerait alors de multiples JVM concurrentes basées sur une même spécification à une JVM unique développée en collaboration par les acteurs à l’origine de HotSpot (Sun), JRockit (Oracle/BEA) et J9 (IBM). Une telle collaboration ne serait pas sans rappeler celle qu’a établie l’industrie derrière Linux.

Un point reste toutefois à déterminer : quelle sera la la gouvernance d’OpenJDK ? Dans le cas de Linux, la gouvernance est entre les mains de la Linux Foundation avec à sa tête Linus Torvald. Une organisation similaire est-elle possible autour du JCP en tant que « Java Foundation » ? Les réformes à venir du JCP devraient répondre à cette question.

Agilité

Comment vendre Scrum à votre manager

Dans cet article sur InfoQ, Mark Levison aborde l’épineux sujet de la conduite du changement vers une méthodologie agile.

Il est en effet complexe de convaincre un manager de la nécessité de migrer vers une méthodologie telle que Scrum car ce dernier est généralement contraint par des objectifs de delivery (délivrer de la valeur dans les temps par exemple). Mark nous donne quelques éléments permettant de gérer au mieux cette transition :

• Soyez à l’écoute de votre management et concentrez vous sur ce qui a le plus de valeur aux yeux de votre manager.
• Adoptez progressivement les méthodes agiles en justifiant les changements comme une amélioration du process actuel et non comme une migration vers une méthodologie agile.
• Présentez régulièrement les bénéfices des changements mis en oeuvre et montrez le retour sur investissement des changements adoptés.

Vendre une migration vers une méthodologie comme Scrum peut se révéler complexe. En revanche, écouter et comprendre les problèmatiques rencontrées par votre management vous permettra de mettre en avant les solutions qui y répondent le mieux, et ainsi de démontrer à votre manager l’intérêt du changement.

L’introduction progressive d’une méthodologie agile peut s’apparenter à un développement itératif dont les éléments du backlog seraient constitués des éléments de la méthodologie, priorisés en fonction de la valeur apportée à votre management. En montrant régulièrement les progrès effectués et le retour sur investissement des changements, il est probable que votre management vous accordera sa confiance et une marge de manoeuvre plus importante afin d’améliorer les process en vigueur.

Le coin de la technique

Percolator, l’indexation incrémentale du Web selon Google

Google a diffusé la semaine dernière la très attendue publication académique portant sur sa nouvelle architecture d’indexation incrémentale du Web.

Jusqu’alors, Google parcourait l’ensemble des pages Web du monde, les stockait dans sa base de données distribuée BigTable, puis procédait à leur indexation à l’aide de tâche MapReduce sur un très large cluster de machines. Parmi les tâches composant cette indexation, ils procèdent à une inversion des liens, c’est-à-dire que les mots trouvés dans les liens sont attachés en tant que mots clés des pages vers lesquels ils pointent. L’ajout ou la mise à jour d’une page a donc un impact potentiel sur de nombreuses autres, c’est pourquoi une ré-indexation complète était effectué jusqu’alors. Outre le surcoût de cette solution, Google lui reprochait son manque de réactivité incompatible avec l’orientation « temps réel » que prend le Web depuis quelques années.

Cette nouvelle solution d’indexation incrémentale est nommée Percolator par Google et consiste en un ensemble de tâches transactionnelles déclenchées par événement. Ainsi lorsque le crawler ajoute ou modifie une page il déclenche un évènement qui déclenche une cascade de tâches Percolator.

Percolator fonctionne au-dessus de BigTable en se fondant sur sa logique : des colonnes BigTable sont utilisées pour le stockages des différents états de l’algorithme distribué : acknowledge, notification et lock.
Afin d’assurer une forte scalabilité, Percolator gère les conflits de mise à jour (collision de deux transactions) par un rééssai ultérieur. Cette logique le destine donc avant tout aux traitements batch asynchrones pour lesquels MapReduce n’est pas adapté.

Fort des explications et retours d’expérience de Google, on peut maintenant s’attendre à voir une implémentation Open Source de cette intéressante solution de batch incrémental distribué du coté de la communauté Apache Hadoop, mais cela prendra probablement de nombreux mois.

Maven 3

Maven 3 est sorti ce samedi 9 octobre presque 5 ans après la version 2. Je m’en sers dans la plupart des projets que je rencontre depuis un peu plus de 6 mois sans problèmes majeurs. En effet l’accent de cette release a été mis sur la compatibilité avec les versions précédentes et dès les premières versions alpha, elle était au rendez vous. Derrière le rideau tout ou presque a changé, cette version est une grosse refonte technique, mais pour l’utilisateur de Maven il n’y a que peu de différences.

Les nouveautés :

• Construction des modules en parallèle: Il s’agit d’une option à activer avec le switch -T
• Stabilité et prévisibilité : La vitesse moyenne des builds est légèrement améliorée, il y a notamment moins d’appels aux repositories, amélioration du classloading (pour les plugins et les extensions)
• Validation et notification d’erreur : Les erreurs dans les descripteurs de projet ou dans les builds sont beaucoup plus clairement annoncés avec le plus souvent un ersatz de solution.

A venir :

• Maven shell: un shell (ligne de commande) qui cache la résolution de dépendances ainsi que le chargement de plugins de commande en commande.
• Maven polyglotte : permet d’exprimer les descripteurs de projets (pom.xml) dans d’autres langages que l’XML (Groovy, Ruby, Scala, Clojure…).
• M2Eclipse : plugin d’intégration de Maven dans Eclipse qui devrait voir une release 1.0.

L’ensemble de ces développements est rendu possible grâce à l’architecture de Maven 3.

Pour plus de détails vous pouvez consulter la note de version et la note de compatibilité. Enfin pour savoir si les plugins que vous utilisez sont compatibles il y a la matrice de compatibilité.

Netbeans 6.10 sera finalement Netbeans 7

The Aquarium, le blog officiel sur le serveur J2EE Glassfish, nous apprend la nouvelle: l’ex-futur Netbeans 6.10, sera finalement renommé en Netbeans 7. La raison officielle semble être le calage sur le numéro de version de Java, Netbeans sera alors (quasiment) prêt à supporter les nouveautés syntaxiques de Java 7 pour la sortie du JDK 7 lors de sa sortie. Par ailleurs, on ne sera pas trop surpris d’apprendre que le support de JavaFX script ne sera plus à l’ordre du jour (mais dès la version 7.1, on devrait avoir un support étendu des API Java de JavaFX). La liste complète des changements se trouve sur le wiki de Netbeans.
Cette nouvelle version est prévue pour mars de l’année prochaine. En attendant, vous pouvez toujours tester les versions intermédiaires, la milestone 2 devant sortir cette semaine. Profitons en pour noter les évolutions permanentes de la version 6.9, et notamment une correction récente qui permet maintenant d’utiliser Lombok avec les projets de type Maven. Votre serviteur l’attendait avec impatience !

Gaelyk, le cloud facile

Gaelyk, le framework « léger » permettant de développer en Groovy sur le Google AppEngine, vient de voir se succéder assez rapidement plusieurs versions pour arriver jusqu’à la 0.5.5. Dzone nous détaille succintement les améliorations. Aucune n’apporte de vraie révolution, mais Gaelyk semble s’affirmer de plus en plus comme LE framework à utiliser par les développeurs Java s’ils veulent bénéficier facilement et à moindre coût d’un serveur leur permettant de mettre en ligne des petites applications. D’autant que le framework dispose d’un bien bel atout: le plugin maven-gaelyk a rapidement été mis à jour. Celui-ci permet d’utiliser notre outil de build favori pour créer un squelette d’application, puis le déployer et l’exécuter en local facilement.
Mais attention, Gaelyk ne se limite pas aux petites applications et Helloworld: Deluan Quintão nous indique que l’on peut facilement configurer notre Spring habituel pour retrouver les automatismes (certains diront la lourdeur ) des applications d’entreprise. Il ne serait pas étonnant de voir de plus en plus de développeurs Java utiliser Gaelyk pour prototyper certains concepts ou réaliser des démos en un rien de temps.

Agilité

• L’agilité à la sauce Pixar
• Evitez le multi-tâches dans les équipes de développement

Le coin de la technique

• Développez vos applications Android sans écrire une ligne de code
• Mettez à jour votre JVM

Evènements de notre communauté en France et à l’étranger

• Le programme du Devoxx 2010 se dévoile

Agilité

L’agilité à la sauce Pixar

C’est une question d’actualité avec la sortie de Toy Story 3 : mais comment Pixar fait-il pour cartonner à chaque nouveau film ? InfoQ lève une partie du voile : la cohérence construit la confiance. Derrière cette maxime ‘à l’américaine’ se cache un processus créatif original : Pixar construit des équipes pluri-disciplinaires, qui travaillent ensemble (éventuellement durant plusieurs films) et qui créent des liens de confiance inaliénables. Chaque jour, l’équipe se réunit pour discuter du travail effectué la veille : critiques, remises en cause, les équipes travaillent dans un processus d’amélioration constante. Chaque membre de l’équipe est encouragé à donner son avis, même ses membres les plus juniors.
Ce mode de fonctionnement laisse la place à l’erreur. Comme chacun est impliqué, chacun peut se tromper. Les erreurs sont mêmes une des clés du processus créatif. L’essentiel est de se tromper rapidement, pour pouvoir corriger le tir.

Changez maintenant de point de vue, et regardez cet article sous l’angle du développement logiciel. N’y retrouve t’on pas un fort goût d’agilité ?

Evitez le multi-tâches dans les équipes de développement

Toujours sur InfoQ, Roger Brown nous met en garde contre les méfaits du traitement simultané de projets (tâches, user stories …) par une personne.
Le changement de contexte lorsque l’on passe d’une tâche à l’autre peut prendre plus ou moins de temps en fonction de la complexité de la tâche, du temps et de la nature de l’interruption. Le traitement d’un appel téléphonique, par exemple, pourra engendrer un délai d’un quart d’heure pour se remettre dans le contexte de la tâche précédente. D’autres types d’interruptions (travail sur une autre tâche de développement par exemple) peuvent nous faire perdre beaucoup plus de temps.
L’auteur nous explique que le travail en parallèle sur plusieurs projets implique généralement un surcoût induit par les changements de contexte pouvant représenter de 20% à plus de 50% du temps de travail lorsque nous travaillons simultanément sur plus de deux projets. Il est donc préférable de terminer une tâche (User Story par exemple) avant d’en commencer une autre, plutôt que de fragmenter son travail.
Les méthodes agiles comme Scrum ou le Kanban préconisent un nombre limité de User Stories ou de tâches en cours, et de ne pas en commencer une autre avant d’avoir atteint le statut « Done ».
Le cerveau humain ayant tendance à vouloir traiter plusieurs tâches en parallèle, Roger Brown préconise quelques techniques telles que le pair-programming afin d’aider les développeurs à rester concentrés sur leur tâche et à gagner ainsi en efficacité.
On peut aussi citer le pomodoro qui est une discipline consistant à se ménager un laps de temps de 25 minutes sans interruption, permettant de se focaliser sur une tâche et ainsi de gagner en efficacité.
L’auteur conclut en ajoutant que non seulement le traitement séquentiel des projets (tâches, user stories …) permet de gagner du temps, mais il permet aussi de créer des synergies entre les différents membres de l’équipe qui peuvent ainsi travailler de concert sur le projet.

Le coin de la technique

Développez vos applications Android sans écrire une ligne de code

Google Labs vient d’annoncer l’arrivée d’App Inventor, un éditeur d’applications pour Android destiné aux non-développeurs. L’objectif est de permettre à tout androphile de dessiner sa propre application depuis le logiciel, puis de la transférer sur son smartphone.

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app’s behavior.

Pour le moment, il n’est pas possible de s’inscrire. Vous pouvez seulement montrer votre intérêt en remplissant un formulaire dans lequel vous exprimerez votre enthousiasme pour l’utilisation d’AppInventor dans un cadre universitaire. Si vous n’avez rien à voir avec quelconque formation, vous pouvez toujours laisser les réponses vides.

En épluchant le site, on constate la forte volonté d’installer cet éditeur dans le monde universitaire, voire scolaire. En effet, il est fait mention à plusieurs reprises des possibilités de développements de jeux, d’applications communautaires ou d’outils d’interaction entre étudiants. Malgré tout, Google n’oublie les autres… le particuliers lambda, ou le collègue que nous sommes en précisant:

The App Inventor team has created blocks for just about everything you can do with an Android phone, as well as blocks for doing « programming-like » stuff.

Nous nous posons tout de même quelques questions à ce sujet:

• Google préfèrerait-il que nous apprenions à utiliser son logiciel plutôt qu’écrire du code propre personnalisé?
• Ne se cache-t-il pas un envie de maîtriser le code généré? (en y ajoutant des statistiques par exemple…)
• N’y a-t-il pas un risque de voir proliférer sur le market des applications réalisées en 5 minutes, pleines de pubs et pauvres sur les plans fonctionnel et graphique? (comme HelloPurr, cf. vidéo de démo)

Le futur nous le dira…

Du côté de la technique, les outils utilisés sont OpenBlocks et Kawa Language Framework. Le premier est le fruit de la thèse de Ricarose Roque (MIT) : une librairie Java permettant de programmer des systèmes à l’aide de blocs visuels. Le second est utilisé par le compilateur pour traduire en bytecode les blocs graphiques.

En attendant d’avantage d’informations et pourquoi pas un article plus complet sur l’outil, vous trouverez déjà quelques tutoriaux sur le site.

source : site de l’éditeur

Mettez à jour votre JVM

Après une dernière release qui corrigeait un problème de sécurité, Oracle nous invite à télécharger la release 21 qui, outre la correction de bugs (mais pas de correction liée à la sécurité), apporte des améliorations sur la JVM HotSpot et VisualVM.

Sur la Java HostSpot VM, les améliorations portent sur la compression des pointeurs d’objets, escape analysis (qui améliore la gestion des piles), la gestion du cache sur le byte code, sur le garbage collector CMS (Concurrent Mark-Sweep) et G1. Pour rappel, G1 est le nouveau garbage collector en préparation pour la JDK 7 mais déjà utilisable dans la version 6 depuis la release 17. Pour l’activer il faut passer les options -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC.

La version 1.2.2 de VisualVM, sortie il y a quelques mois, est à présent incluse dans la distribution de Java SE. Elle apporte beaucoup d’améliorations sur l’analyse de la mémoire et sur le profilage.

Enfin pour les développeurs de RIA java, un listener a été ajouté pour suivre l’évolution du chargement de l’application. Plus de détails ici.

Evènements de notre communauté en France et à l’étranger

Le programme du Devoxx 2010 se dévoile

J’espère que vous avez créé une règle sur votre outil de mailing préféré qui décline toute demande de réunion sur la période du 15 au 19 novembre 2010 car c’est … Devoxx!
À moins d’être parti 8 ans en mission dans l’océan arctique sur un brise glace, vous ne pouvez pas ne pas connaître Devoxx. C’est LA conférence européenne spécialisée sur LA technologie (i.e. Java) qui se déroule tous les ans à Anvers en Belgique.

Tout le gratin des meilleurs speakers et spécialistes sera présent dont certains français: Antonio Goncalves, Guillaume Laforge, Emmanuel Bernard pour ne citer qu’eux, mais aussi des incontournables comme Heinz Kabutz, John Smart ou bien Michael Cote.
Mais ce n’est pas tout! En effet, un BoF (Bird of Feather) organisé par les JDuchess se prépare.

Le programme commence à prendre forme. Vous pouvez commencer à saliver sur des conférences plus intéressantes les unes que les autres avec quelques titres accrocheurs:

• JAX-RS, Java EE 6, and the future,
• Reflection Madness,
• Improve the performance of your Spring app,
• HTML 5 Fact and Fiction,
• Comparing JVM Web Frameworks,
• Groovy update, ecosystem, and skyrocketing to the cloud with App Engine and Gaelyk,
• Restfulie: quit pretending, use the web for real,
• Women in IT an unconference,
• etc.

Dans le programme de cette année, c’est surtout la présence de plus d’une dizaine de sessions dédiées aux technologies NoSQL et Cloud que l’on retiendra. On se souvient en effet que l’édition 2009 de cette conférence n’avait proposé qu’une trop courte session d’introduction à NoSQL suivie d’un BOF. Cette augmentation sensible de la part accordée à ces technologies témoigne de leur popularité croissante en 2010. Une fois de plus Devoxx s’affirme comme le baromètre de notre écosystème !

Agile 2010 est la principale conférence internationale sur les méthodes agiles dans le développement logiciel. Elle se tiendra du 9 au 13 août 2010 à Orlando en Floride.
La conférence Agile 2010 réunit de nombreuses disciplines dans les domaines des Systèmes d’Information et du développement logiciel. Elle crée ainsi des ponts entre des communautés qui ont rarement l’occasion d’échanger autour de leurs idées.

Lors de l’édition 2010, 3 Xebians auront le plaisir d’être sur scène pour vous faire partager leurs expériences et leur vision :

• Guido Schoonheim (CTO du groupe Xebia) présentera une session intitulée « Mind the Gap! Principles of hyperproductive fully distributed Scrum ».
• Maurits Rijk (Consultant senior chez Xebia) présentera une session intitulée « A graphical approach to improve the cost/benefit ratio of user stories ».
• Wilco Koorn (Scrum Master et Team Member chez XebiaLabs) présentera une session intitulée « Unleash the Agile power: bridge the Gap between Development and Operations ».

Mind the Gap! Principles of hyperproductive fully distributed Scrum

• Presenter: Guido Schoonheim (CTO of Xebia Group)
• Level: Practicing
• Presentation: The author and Jeff Sutherland previously showed (at Agile2008,2009) Scrum teams using XP practices achieved distributed velocity equal to local velocity with multiple distributed teams. This was shown under extreme timezones and at large scale development. The authors have formalized the principles & practices that are the foundation for hyperproductive fully distributed Scrum. This framework has been published as free e-book and is the subject of this presentation. New experiences and figures on recent projects will be shared to illustrate the pitfalls and success points.

A graphical approach to improve the cost/benefit ratio of user stories

• Presenter: Maurits Rijk (Senior Consultant at Xebia)
• Level: Practicing
• Short summary: User stories are a great way to capture requirements and are successfully used in many projects. Every user story comes with a business value and a effort needed to implement the story, usually in software. Since there are almost always more requirements than budget (or any other limiting factor like time, available resources, etc) decisions have to be made on which stories to pick up in which order. Usually the stories are prioritized by the product owner and put on a textual product backlog. We will show how a graphical overview will stimulate the right side of our brains.

Unleash the Agile power: bridge the Gap between Development and Operations.

• Presenter: Wilco Koorn (Scrum Master and Team Member XebiaLabs)
• Level: expert
• Short summary: Enterprises traditionally distinct Development focusing on the creation of software and Operations focusing on the infrastructure. A natural gap between the two is caused by their key interest: change versus stability. Introducing Agile in Development confronts Operations with more work due to increased productivity and release frequencies. The power of Agile is not unleashed. A case study at KLM/Air France shows how this impediment was overcome and huge savings were achieved by implementing a self-service change control process for Development still under full control of Operations.

Equipées d’un écran à visée Laser, elles permettent au Scrum Master de digitaliser l’intégralité des Story Boards et d’alimenter le Burndown Chart de manière automatique.
En quelques secondes, ces lunettes transfèrent l’intégralité du contenu manuscrit des notes directement dans la feuille Excel destinée à tenir le détail du travail effectué.
Dans la droite lignée du principe agile consistant à supprimer le gaspillage, Les Daily Scrum Glasses suppriment les longues et fastidieuses étapes de mise à jour quotidienne du Burndown Chart.

Des tests en situation réelle (cf Schémas 1, 2 et 3 ci-dessous) ont démontré une capacité de transfert de 300 « Notes » du Story Board vers le Product Burndown Chart en moins de 5 secondes. Les gains de productivité d’un Scrum Master équipé des Daily Scrum Glasses sont de 30%.

Schéma 1: Scrum Master Xebia équipé de Daily Scrum Glasses

Schéma 2 : Projet Agile conséquent benchmarké

Schéma 3 : Product Burndown Chart généré par les « Daily Scrum Glasses »

Vendues à la FNAC et chez Surcouf, le prix public conseillé est de 29,00 Euros/HT.

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

Actualité éditeurs / SSII

• Subversion devient un projet top-level Apache

Agilité

• Sortie du livre « SCRUM : Le guide pratique de la méthode agile la plus populaire »

RIA

• HTML5 + CSS3 = 52framework

Le coin de la technique

• Les nulls, c’est nul !
• G1 pas à la hauteur des espérances ?

Actualité éditeurs / SSII

Subversion devient un projet top-level Apache

Après seulement 3 mois d’incubation (mais sur le point de fêter ses 10 ans, Collabnet ayant sorti la première version en 2000), Subversion est maintenant projet top-level Apache. Pour ce faire, le projet a du se plier aux règles strictes édictées par la fondation Apache, qui touchent à la fois au code source du logiciel, à la provenance des différents codes, à leur licence, au site internet du projet, au processus de release des nouvelles versions… C’est un gros travail mais il permet ensuite aux projets de bénéficier de toute l’infrastructure ainsi que de l’aura de la fondation Apache.
Subversion s’assure donc pour la suite une stabilité et une plus grande visibilité, élargit sa communauté et s’octroit plus de crédibilité vis à vis des entreprises. En effet, être projet top-level Apache est gage de pérennité.
Le projet en aura besoin, étant fortement concurrencé par les outils de gestion de version distribués comme Git ou Mercurial. Martin Fowler notait ainsi récemment plusieurs points négatifs de SVN :

• l’absence de copie locale du repository d’où des problèmes de performance et l’impossibilité de travailler offline sur ce repository.
• le fait que les branches aient une visibilité globale est un frein à l’innovation: les développeurs sont moins enclins à créer une branche pour expérimenter diverses innovations.

Néanmoins, SVN reste pour lui le meilleur des outils non distribué, et est largement recommandable. D’autant que c’est un outil plus simple à appréhender et son ancienneté fait que les bonnes pratiques sont largement répandues. D’autre part, ajoutons que les développeurs semblent ne pas se reposer sur leurs récents lauriers, et annoncent la disponibilité dans la version 1.7 de la fonctionnalité de offline commit. Comme d’habitude, nous bénéficions encore de la concurrence pour avoir à notre disposition les meilleurs outils. Chouette !

Agilité

Sortie du livre « SCRUM : Le guide pratique de la méthode agile la plus populaire »

Claude Aubry, auteur du bien connu blog Scrum, Agilité et Rock’n roll nous délivre dans ce livre un condensé de son expérience sur la mise en place de Scrum. Très pragmatique, ce livre traite point par point les différentes composantes de Scrum en les expliquant et en détaillant pour chacune les pratiques qui fonctionnent et celles à ne pas tenter. Après avoir dévoré les 5 premiers chapitres nous ne pouvons que vous engager à lire cet ouvrage qui fera office de référence pour vous accompagner sur vos projets Scrum.
C’est comme d’avoir un peu de Claude Aubry avec soi sur son projet, mais sans l’accent

RIA

HTML5 + CSS3 = 52framework

Même si c’est en très bonne voie, les navigateurs Web du marché ne sont pas entièrement compatibles HTML5 et CSS3. Néanmoins, plusieurs librairies JavaScript permettent de rendre votre navigateur 100% compatible avec ces 2 technologies et 52framework en fait partie.

Au menu, la librairie nous propose d’utiliser les différentes nouvelles balises HTML5 telles que aside, nav, section ou bien encore article. Les nouveaux input type='email' et input type='url' sont aussi de la partie. La balise script contenant du JavaScript n’a plus besoin de l’attribut type='text/javascript'. Côté CSS3, il est possible d’utiliser les coins arrondis, les text-shadow et les box-shadow.
La démo se trouve ici, le plus intéressant étant son code source où l’on retrouve les nouveaux éléments cités ci-dessus.

Pour le téléchargement, rendez-vous est pris sur le Google Code du projet section Downloads.

Le coin de la technique

Les nulls, c’est nul !

C’est en tout cas ce que beaucoup d’entre nous ressentent en tombant sur certaines NullPointerExceptions. Et suivent les premières questions : Où sont les tests unitaires ? Quel paramètre n’a pas été testé ? Mais, ressenti de plus en plus grandissant avec les derniers langages alternatifs pour la JVM, pourquoi laisser passer des valeurs nulls en paramètre ?

Pour ne prendre qu’un seul exemple, Scala permet d’éviter ce genre de désagrément grâce à la classe Option (Avoid using nulls in Scala). Dans le cas d’une valeur définie, il suffit d’utiliser Some(something) qui est l’option avec valeur. Et pour le null, il faudra se tourner vers None qui est l’option sans valeur. Le code est ainsi réduit et ne contient plus de test if(obj !=null) (englobé dans l’option None) :

// possible parameters
var anObject = Some(5)
var nullObject = None
// our code that do not care about nulls
val doubleFunc = (option:Option[Int]) => print(option.map(_*2))
doubleFunc(anObject)
doubleFunc(nullObject)
// prints
Some(10) // values has been doubled
None // does nothing

Mais pour Java ? Une petite piqure de rappel ne faisant pas de mal, cet article nous présente une solution possible avec en citation Martin Fowler et le pattern Special Case.

L’idée est la même que pour l’option Scala. On commence par définir une classe abstraite ou une interface avec une méthode spécifique qui sera appelée par notre code. Et de là seront créés 2 objets : un objet réel et un objet null. Ce dernier implémentera la méthode demandée mais ne fera rien alors que l’objet réel exécutera son code métier. Ainsi, plus de test de nullité, notre code lancera directement la méthode sur l’objet et ne se souciera plus de savoir si l’objet est null ou non.

Ce pattern anti NPE est une solution possible mais elle n’est pas la seule. Si vous avez suivi l’actualité, vous êtes malheureusement au courant que les operateurs null-safe et elvis ne seront pas implémentés par l’ambitieux Project Coin. Le sucre syntaxique ne viendra donc pas directement dans nos appels de fonctions mais par les annotations de JSR-305 dont @NonNull. Bien sûr, cette spécification a pour cible FindBugs, Intellij IDEA, Checkstyle ou bien encore PMD. On aurait préféré une intégration au Project Coin mais c’est déjà mieux que rien…

G1 pas à la hauteur des espérances ?

G1 (Garbage First) est un nouvel algorithme pour votre Garbage Collector. Il est destiné à remplacer l’implémentation par défaut lors de l’arrivée de la prochaine JVM. Celui-ci apporte un certain nombre d’avancées significatives dont des performances annoncées (quasi) compatibles avec le temps réel. Pour cela, G1 relève le défi de la maitrise des temps de pause des collections stop the world grâce à une gestion innovante de la mémoire (reposant sur beaucoup plus de ‘petites’ zones).

Nous n’allons pas détailler son fonctionnement ici. Si le sujet vous intéresse, nous vous encourageons à consulter l’un de nos articles sur le sujet. Il date un peu, mais son contenu reste tout à fait d’actualité : GC générationnels traditionnels (jdk6) VS GC Garbage First (jdk7).

Si les fonctionnalités de ce nouvel algorithme sont alléchantes, on retrouve ici et là quelques retours frileux suite à son usage. L’auteur de ce billet annonce des performances moins bonnes qu’avec le garbage collector par défaut lors de l’utilisation de LinkedHashMap. Faut-il s’en inquiéter pour autant ? Non ! Vu la criticité de ce genre de fonctionnalité, il est tout à fait normal que quelques ajustements soient faits lors des premiers retours d’utilisation terrain. C’est d’ailleurs le but recherché suite à l’intégration à Java 6 update 14 (via les options -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC), même s’il est vrai qu’il n’est plus flagué ‘expérimental’ depuis peu sur les derniers build du jdk 7.

En revanche, en plus de la mise en doute des performances de G1 relayée sur le internet, nous pensons qu’un élément bloque effectivement son adoption en production : le monitoring. Celui-ci est aujourd’hui insuffisant, ni jstat ni VisualGC ne remontent d’informations comme le montrent les captures d’écran ci-dessous.

jstat et VisualGC ne sont pas encore prêts pour G1

$ jstat -gccause 30572 5s
Warning: Unresolved Symbol: sun.gc.generation.0.space.1.capacity substituted NaN
Warning: Unresolved Symbol: sun.gc.generation.0.space.1.used substituted NaN
...
Warning: Unresolved Symbol: sun.gc.collector.0.invocations substituted NaN
Warning: Unresolved Symbol: sun.gc.collector.0.time substituted NaN
...
S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
? ? ? ? 79.96 ? ? ? ? ? unknown GCCause No GC
? ? ? ? 79.96 ? ? ? ? ? unknown GCCause No GC


Je souhaite relater ici les propos qui se sont tenus lors de cet échange avec Ken.

Quant à mes impressions personnelles, je ne les partagerai pas avec vous car, en tant que Président du SUG, je souhaite rester neutre face aux différents courants de pensée, organismes certificateurs ou non, canal historique ou dissidents …

Le premier contact avec Ken est surprenant. Le co-fondateur de Scrum avec Jeff Sutherland, la figure légendaire de l’agilité est fatiguée, un peu diminuée physiquement également. Son accident de vélo a laissé des traces.

Ken m’a glissé à l’oreille : « c’est parce que je fais du vélo que j’ai failli mourir mais c’est également parce que je fais du vélo (et donc que je suis en forme physique) que j’ai pu m’en sortir. »

Derrière son visage marqué par les décalages horaires permanents, se cache un personnage qui n’a rien perdu de sa verve, de son dynamisme, de son humour, de ses convictions.

Ken est un passionné de développement logiciel, cela se voit.

Nous lui avions demandé de nous présenter Scrum.org dont il est le fondateur.

Première définition : Scrum.org a pour objectif de « préserver l’intégrité et la consistance de Scrum » (sic !).

Allons plus loin.

Scrum.org propose des tests en ligne (assessments) et des cours destinés aux praticiens Scrum.
Parmi les tests en ligne, notons l’arrivée de :

• Scrum Developer (SD), test destiné aux développeurs.
• Scrum Open, test en ligne destiné à évaluer le premier niveau de connaissances Scrum d’un utilisateur.
• Scrum Level II, le test pour les expérimentés.

Attention !: Pour réviser et réussir ces tests, il faudra avoir lu le Scrum Guide dont l’auteur est … Ken Schwaber.

A noter que Scrum n’est plus agnostique et que des cours Scrum Developer purement .net ou purement Java sont au programme.

La prochaine rencontre se fera avec Scott Ambler, le 15 mars grâce à IBM. Je donnerai des informations précises dans le cadre des activités du SUG.

Cette soirée se déroulera sur le modèle Birds of Feather (BoF) à partir de 19h00 dans nos locaux (156 Boulevard Haussmann à Paris). Elle sera l’occasion d’échanger directement avec Jeff Sutherland et de profiter de son expérience unique en tant que père de la méthode ayant plus de 10 ans d’expérience sur Scrum.

Le même soir que le deuxième anniversaire du Paris JUG ? Oui, Jeff Sutherland passe rarement à Paris, nous aurions aimé que les événements ne se chevauchent pas mais nous n’avons pas trouvé d’autre solution. Donc nous sponsorisons la soirée anniversaire du JUG et nous organisons cet aparté avec Jeff Sutherland .

Le nombre de place étant limitées, merci de vous inscrire via le formulaire ci-après (premiers arrivés, premiers servis) :

Cette formation répondra, entre autres, aux questions suivantes :

• Comment planifier et faire des estimations avec Scrum ?
• Comment un chef de projet traditionnel devient-il un chef de projet agile ?
• Comment faire travailler l’analyste fonctionnel avec les équipes agiles ?
• Comment fonctionnent les reportings et les métriques avec Scrum ?
• Comment travailler avec des équipes distribuées en Scrum ?
• Comment savoir si un projet est compatible avec Scrum ?
• Quels sont les outils principaux de Scrum ?
• Comment s’assurer d’un résultat cohérent ?
• Comment aménager la salle d’une équipe agile ?

Arlen Bankston (Formateur ScrumMaster certifié et Lean Six Sigma Master Black Belt). La formation a lieu en anglais.
Arlen Bankston est un leader reconnu dans la mise en œuvre des méthodologies de management tel que Lean, Six Sigma, BPM mais aussi dans les processus de développement logiciel SCRUM et XP.
Arlen a mené avec succès des projets agiles d’envergure pour des entreprises telles que Capital One, T.Rowe Price, NBC Universal, Saudi Telecom, United States Army et Freddie Mac pour ne citer qu’elles.
Arlen est aussi le Vice Président de LitheSpeed, un cabinet international spécialisé dans la mise en place des techniques Lean et Six Sigma et des méthodologies Scrum et XP.

La prochaine session aura lieu les 8 et 9 mars 2010.

Télécharger le programme >>

Renseignements et inscriptions par mail : info@xebia.fr ou en appelant le 06 09 69 05 49.

A cette occasion, le French Scrum User Group organise avec le concours de Microsoft, une rencontre avec Ken Schwaber, le co-créateur de Scrum le Mardi 26 Janvier 2010 à partir de 19h00.

Inscriptions et détails ici.

Actualité éditeurs / SSII

• Sun publie JavaFX composer en « early access »
• IntelliJ Open Source : décryptage avec le « The 451 Group »

Agilité

• Le problème avec les user stories

Le coin de la technique

• Akka améliore encore la programmation parallèle en Scala
• Le bug de l’an 2000 2010 refait surface
• Secure Coding Guidelines for the Java Programming Language, Version 3.0

Evènements de notre communauté en France et à l’étranger

• Drools chez les Ch’ti (Jug)

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

Sun publie JavaFX composer en « early access »

Sun réalise deux RAD pour JavaFX, le premier cible les développeurs web et l’édition de contenu, le deuxième outil cible de son côté les développeurs Java. C’est ce deuxième outil que Sun publie sous le nom prometteur de JavaFX Composer. Ne vous attendez pas à un produit fini. Pour David Folk, il ne s’agit même pas d’une béta. Il faut voir cet outil comme une démonstration technique. Le but affiché est de permettre le développement d’application de type formulaire avec JavaFX. L’outil, maintenant disponible dans l’update center de Netbeans 6.8, fournit un éditeur graphique permettant de construire une interface graphique assez proche du gui builder de Netbeans.

Attention, s’il est possible de voir le source généré, l’édition en est pour le moment impossible. Les composants peuvent être liés à une source de données JDBC, HTTP(XML/JSON) et fichier.

L’outil fournit un bon aperçu de ce qui peut être fait avec JavaFX. Les limitations, bien qu’encore nombreuses, n’empêchent pas de jouer avec ladite technologie. Il est donc maintenant possible d’utiliser JavaFX pour faire des démos, ce qui donne un peu plus corps à la technologie. Sun continue les investissements dans son Flash killer, mais il a encore et toujours plusieurs trains de retard.

• Article sur infoQ
• Site de Netbeans

IntelliJ Open Source : décryptage avec le « The 451 Group »

Le cabinet spécialiste des modèles économiques Open Source a interviewé Ann Oreshnikova, directeur Marketing de Jetbrains, pour comprendre le nouveau modèle de l’environnement de développement Java le plus sexy au monde.

Jetbrains, initialement connu pour son environnement de développement IntelliJ Idea, a ces dernières années étoffé son portfolio de produits pour couvrir l’ensemble du cycle de développement. Les javaistes connaissent le serveur d’intégration continue TeamCity, le bug tracking system YouTrack mais il existe aussi des outils PHP, Dot Net et Ruby.

Actuellement, Jetbrains compte 49 000 clients payants dont seulement 25 000 clients entreprise et 24 000 individuels. On peut autant s’étonner du faible nombre de clients entreprises que du fort ratio de clients individuels. Les professionnels sont convaincus de la plus value qu’apporte l’IDE mais les entreprises ne sont pas prêtes à payer pour un IDE alors qu’Eclipse et Netbeans sont gratuits.

Pour augmenter ses parts de marché, Jetbrains a décidé de séduire ses clients avec une stratégie assez commune dans le monde logiciel : une version gratuite aux fonctionnalités restreintes. Il restait à décider si le code source était diffusé et, le cas échéant, sous quel contrat de license ? Business Friendly à la BSD/Apache ? Business Unfriendly à la GPL ? Les deux modèles sont éprouvés pour les environnements de développement. Eclipse a choisi le modèle business friendly et Netbeans le modèle business unfriendly.

Jetbrains, malgré le risque de voir d’autres acteurs monétiser son socle, a choisi de marcher dans les traces d’Eclipse en retenant la license Open Source business friendly d’Apache.

L’objectif de dynamiser la communauté autour d’Idea a été atteint, du moins à court terme, la version Open Source ayant été téléchargée des dizaines de milliers de fois.

La qualité et l’avant-gardisme d’Idea n’ont pas suffi à en assurer le succès commercial, souhaitons leur que le modèle dual Open Source / Commercial réussira.

Agilité

Le problème avec les user stories

Dans la méthode agile Scrum, les user stories spécifient de manière simple et concise les besoins du client à implémenter au cours des sprints. Elles permettent de faire l’interface entre celui-ci et l’équipe de réalisation.
Comme le souligne dans son article James Golick, les user stories sont écrites avec des mots. Or, les mots peuvent porter à confusion et à différentes interprétations entre les différents acteurs. Lors d’un sprint demo, en voyant à l’écran l’implémentation de la story, il peut arriver que le client s’aperçoive que son besoin n’est pas complètement satisfait.Ces écarts sont alors corrigés dans les sprints suivants.

James Golick propose d’améliorer cela en réalisant d’abord des maquettes de l’interface. En visualisant directement l’interface et en naviguant dessus, le client est plus à même de se rendre vraiment compte si le développement correspond à son besoin. Cela implique la présence d’un designer sur le projet. Il ne précise pas comment serait intégrée la réalisation des interfaces dans le sprint, mais uniquement que la maquette soit réalisée avant la story.

Le maquettage ne remplace évidemment pas la story, mais serait un complément pour s’assurer que le besoin du client est bien aligné avec la vision qu’en a l’équipe. Et, cela peut aussi amener le client à ajuster ses stories grâce aux maquettes. Cette approche de maquettage n’est pas nouvelle et pourrait revenir sur le devant de la scène. On pense notamment à la solution Flash Catalyst d’Adobe, qui fait beaucoup parler d’elle.

Le coin de la technique

Akka améliore encore la programmation parallèle en Scala

Akka, qui vous permet d’écrire simplement et rapidement des applications concurrentes et scalables, est sorti début de semaine dernière en version 0.6 (annonce sur le Google Groups relayée par Scala-Lang). Pour rappel, Akka s’appuie sur le modèle d’acteurs Scala et est disponible à la fois en API Scala et Java.

De nombreuses nouveautés sont à noter dans cette nouvelle version, que ce soit l’ajout de nouveaux add-ons ou des corrections de bugs. On retiendra notamment :

• nouveaux modules de persistance : Redis, Cassandra et MongoDB ;
• meilleure performance avec les acteurs Akka 2 à 3 fois plus rapide que les acteurs Scala ;
• empreinte mémoire encore plus faible faisant que l’on peut faire tourner plus de 6 millions d’acteurs sur 4Gb de ram ;
• Comet et rest bindings ;
• nouveaux sérialiseur : SBinary, JSON… ;
• intégration de frameworks divers et variés : Lift, Spring ou bien encore Guice.

Si vous souhaitez approfondir le sujet, rien de mieux que l’article sur JavaLobby par l’auteur du framework, Jonas Boner.

Le bug de l’an 2000 2010 refait surface

Le Nouvel An passé, chacun a eu l’occasion de faire sa liste de bonnes résolutions. Vous-même, peut-être avez-vous ajouté au milieu des immanquables « j’arrête de fumer » ou « cette année, je me mets au sport », votre intention de vous mettre à tester vos applications. Mort aux : « je ne comprends pas ça marche sur mon poste ».

Tout cela pour dire que depuis début 2010, une multitude de bugs informatiques ont fait leur apparition. Vous avez probablement entendu les plus médiatiques d’entre eux : les 20 millions de cartes bancaires bloquées en Allemagne ou l’impossibilité d’effectuer des mises à jour sur l’un des produits Symantec depuis ce début 2010. C’est l’occasion de faire un tour rapide des problèmes rencontrés, et de leur principales causes :

Année stockée sur un seul chiffre

Premier problème, probablement le plus flagrant, certains programmes développés après l’an 2000 ont décidé de stocker leurs dates sur un seul caractère. Sont impactés principalement les projets dont la durée de vie n’était pas prévue pour passer ce cap. Les solutions temporaires ont tendance à devenir définitives

En effectuant une recherche sur Google Code, en recherchant un simple pattern de type ’200%d’, il est aisé de trouver plusieurs projets contenant ce bug.

Par exemple, SpamAssassin avait une règle permettant de marquer tous les emails provenant du futur comme spam, dans ce cas, la correction était simple :

// ancienne expression régulière pour détecter le futur
/20[1-9][0-9]/
// correction, rendez=vous dans 10 ans 
/20[2-9][0-9]/

Ouf, on a corrigé le bug de l’an 2000 à temps !

Deuxième catégorie de bugs, certains programmes ayant été fixés pour éviter le bug de l’an 2000 ont généré le bug de l’an 2010. Tout le monde connait ce bug, la majorité des dates étaient stockées sur 2 caractères. À l’époque, pressé par le temps, une correction rapide consistait à rajouter une règle pour identifier les années post 2000 des années 1900. Failed !

// bug en 2010
int annee = (date < 10 ? 2000 : 1900 ) + date ;

Chiffres codés en BCD

Plusieurs protocoles utilisés dans les banques et les télécommunications, dont le protocole utilisé pour les SMS, codent les années sur un seul octet en BCD.
En utilisant cet encodage, il est aisé de confondre les dates comprises entre 2000 et 2009, car leurs représentations sont identiques à leur encodage en binaire simple.
Ainsi, si 2009 s’écrit de la même façon en binaire simple qu’en BCD, 2010 s’écrit de deux manières différentes.
Il s’agit probablement de la cause du bug remonté en ce début d’année sur Windows Mobile.

Secure Coding Guidelines for the Java Programming Language, Version 3.0

Sean Mullan est ingénieur chez Sun, spécialisé dans tout ce qui touche à la sécurité sur la plateforme Java. Il nous apprend que Sun met à notre disposition la version 3 du « Secure Coding Guidelines for the Java Programming Language ». Il nous semble qu’il est bon de rappeler l’existence de ce recueil de bonnes pratiques destiné à tout développeur soucieux de la qualité de son code.

L’article rappelle quelques règles bien connues comme par exemple le fait qu’il vaut mieux éviter de construire soi-même ses requêtes SQL à la main ou alors qu’il faut prendre ses précautions lors de l’utilisation de code externe (JSR 223 ou XML par exemple). Mais il plonge aussi beaucoup plus profondément dans les entrailles de Java en explorant les problèmes liés aux objets (visibilité, héritage…), à la sérialisation et dé-sérialisation des données ainsi que les problèmes de contrôle d’accès.

Un exemple intéressant parmi d’autres est la manière dont on peut ouvrir un code aux attaques lors de l’utilisation de l’héritage: il suffit en effet que la classe parent déclare de nouvelles méthodes non prises en compte par la classe fille pour que celle-ci devienne ouverte aux attaques !

Moralité, assurer la sécurité de ses applications n’est pas une mince affaire et nous n’avons pas fini de parler sécurité !

Evènements de notre communauté en France et à l’étranger

Drools chez les Ch’ti (Jug)

Le 21 janvier à Lille, le Ch’ti JUG aura l’honneur de recevoir Mark Proctor et Geoffrey De Smet de JBoss. Mark est le project leader du projet Drools. Il vient d’être nommé directeur de RuleML. Geoffrey est le créateur de Drools Planner ou Drools Solver. La session se focalisera bien entendu sur Drools.

Pour les personnes qui sont totalement étrangères à ces problématiques, voici deux articles que nous avons rédigé récemment et qui vous aideront à vous plonger dans cette session :

• Le pattern Specification pour la gestion de vos règles métier
• Drools et les moteurs de règles

En attendant avec impatience le compte rendu de ce JUG, belle initiative !