Revue de Presse Xebia

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.