Il y a quelques semaines je présentai un sujet intitulé « Ludification du travail » à une trentaine d’étudiants de l’Epita dans le cadre de leur semaine annuelle de conférences technologiques. J’avais le plaisir d’inaugurer cette présentation sur un sujet qui me tient à coeur et qui fait couler de plus en plus d’encre numérique dans la blogosphère agile. Vous trouverez ci-dessous mon support de présentation que j’ai chargé sur SlideShare. 

J’ai fait un rapide ROTI à l’issue de la présentation et obtenu une majorité de 4 et 5, j’ai également récolté quelques 1: on ne peut pas intéresser tout le monde et le caractère obligatoire de cette conférence ne permettait pas d’utiliser la loi des 2 pieds. 

Enfin, si le support n’est pas assez explicite, sachez que j’ai déroulé cette présentation aux Xebians lors de notre XKE du mois de décembre et que la session a été filmée. Vous devriez donc avoir les explications incessamment sous peu. 

Depuis quelques temps j’attendais l’arrivée de cette journée avec impatience. Intrigué par le nom et le pitch, je me demandais ce que j’allais y trouver, c’est-à-dire ce que les autres allaient apporter. Même si je ne doutais pas de l’intérêt de faire le déplacement, je suis toujours un peu prudent sur le simple fait que rassembler une brochette d’experts agiles dans un endroit pendant une journée va forcément ressortir sur du positif.

Agile Innovation était une journée entièrement dédiée aux échanges open-space et qui faisait suite à la conférence Agile Grenoble la veille, avec un programme plus classique. L’ambition des organisateurs étaient d’offrir un espace d’échange permettant aux praticiens aguerris d’aller au delà d’un programme de présentation qui, comme il se veut accessible à tous, peu sembler parfois un peu simple pour les agilistes expérimentés.
Alexandre Boutin était notre maître de cérémonie pour la journée. Armé de sa cloche de montagne, dont nous allions entendre le son rythmer cette journée, il nous a rassemblé après un petit déjeuner pour l’ouverture de cet open-space. Les règles d’un open space sont simples et l’objectif de cette ouverture est d’établir l’agenda de la journée.

La construction de l’agenda s’est faite sur le même principe que les open-space de la conférence ALE2011: chacun présente une proposition de sujet au groupe et la colle directement sur un créneau disponible, premier arrivé, premier servi. Je trouve cette technique assez efficace car il n’y a pas, comme j’ai pu le voir à des conférences comme CITCON par exemple, de votes pour faire émerger les sujets les plus populaires puis une construction collaborative de l’agenda. Cela évite de perdre un temps précieux pour arriver à un consensus qui généralement ne satisfait pas vraiment, autant partir tout de suite avec l’idée qu’il faudra faire des choix douloureux et ne pas s’embêter à une planification collaborative. La seule contrainte que je vois pour que cela fonctionne est d’avoir suffisamment de créneaux disponibles, dans le temps et l’espace, pour atteindre un écart suffisamment grand entre le nombre de propositions planifiées et le nombre de propositions abandonnées. A ce titre, Alexandre nous a fait une belle démonstration d’agilité en réduisant à la volée la durée des créneaux de 20 mn et en augmentant le nombre d’espaces de discussion pour maximiser les propositions. Bien joué.
3 sujets m’intéressaient fortement pour le premier créneau: Transformation Agile, advanced Story Mapping, et coaching agile. Je n’avais aucune envie d’en rater un et j’ai donc décidé de ne pas choisir! A force de pratiquer les open space, j’ai fortement développé mon application de la loi des 2 pieds ce qui permet d’une part de suivre plusieurs sessions en parallèle, mais aussi de ne pas regretter une session si elle se révélait être sans intérêt pour moi (dans ce cas je repars dans la première le coeur léger). Ca marche particulièrement bien si les facilitateurs des sessions font un bon travail de synthèse au fil de l’eau: lorsqu’on arrive dans l’espace de discussion on peut saisir rapidement ce qui s’est dit tout en écoutant la discussion en cours. Ensuite, il suffit à la fin du créneau de retourner voir la synthèse finale de chaque discussion pour lire les éléments manqués. Avec un peu d’exercice ça marche bien.

La session transformation Agile était animée par Petra Skappa et Greg Hutchings. Ils ont présenté différentes approches imagées de transformation (dont on sentait que certaines n’étaient pas conseillées): La goutte d’eau agile dans l’océan, les pousses agiles, le responsable agile et ses ambassadeurs distribués, le focus tournant (bottom up, top down, inside out, lateral).

La session stroy map était animée par Mac Adams. Il a présenté différentes approches de la technique et les participants ont partagé leur technique et les bénéfices.

La session Coaching Agile facilitée par Jean-François Jagodzinski, attrapée en toute fin, a généré beaucoup d’information. Elle était particulièrement intéressante dans la mesure où l’objectif était de prendre le point du vue des coachés et pas celui du coach. C’était un peu l’arroseur arrosé, là où le coach agit souvent comme un miroir de l’équipe, ce sont ici les coachés qui renvoyaient au coach leur image. C’était très instructif dans l’optique d’améliorer son action de coach agile. La discussion a même largement débordé sur le créneau suivant. Je m’en suis extrait avec difficulté pour rejoindre la session d’Alexandre Boutin sur les jeux sans matériel, une session qui a eu beaucoup de succès. J’ai particulièrement aimé le jeu des triangles (ou des systèmes complexes) plein d’enseignements sur l’auto-organisation.

Sur le troisième créneau j’animais une session sur le sujet « Agile Distribué ». Mon objectif était de rassembler les retours d’expériences et les opinions des praticiens ayant évolués dans des contextes distribués. Deux principales organisations se dégagent: des équipes pluri-disciplinaires co-localisées par site mais qui travaillent sur un même backlog, et une équipe pluridisciplinaire distribuée sur plusieurs sites. Au fil des discussions, la session a pris une tournure plutôt étonnante, là où nous voyons souvent le deuxième modèle comme une contrainte qui nous est imposée et qu’il faut éviter, quelques participants ont proposé que le modèle distribué est peut-être une cible en soi car elle porte des contraintes vertueuses: elle force la discipline individuelle, elle met en évidence des dysfonctionnements qui passent inaperçus en mode co-localisé, et elle apporte une richesse culturelle bien supérieure qui favorise la qualité du produit.

L’après-midi démarrait pour moi par une session sur la contractualisation agile. L’occasion de mentionner le contrat agile que Xebia a sorti en license Creative Commons et d’en expliquer les principes. Jean-François Jagodzinski a également beaucoup partagé ses expériences et l’état de ses réflexions. J’ai aimé sa métaphore du bio: quand on achète un poulet bio, on achète aussi le processus de fabrication du poulet, pas seulement le poulet. C’est un peu pareil pour le contrat Agile, l’idée est d’acheter un processus de fabrication et pas seulement le produit final.

J’ai continué l’après-midi avec un session facilitée par Jacques Couvreur, dont le but était de rassembler tous les ingrédients pour faire LA conférence agile en 2012, celle que les gens s’arracheront. Son critère de succès: les inscriptions sont complètes en 5 minutes même si le site de réservation ouvre à 6h du matin.

Enfin pour conclure avec les sessions de la journée, j’ai participé à une discussion sur Extreme Programming et BI, facilitée par Cedric Bourgeois. Avec les quelques participants présents, nous en sommes arrivés à la conclusion qu’en l’état le BI ne se prête pas bien à des pratiques comme le TDD, c’était prévisible. C’est avant tout une question d’intégration. Il reste néanmoins possible de faire des tests d’intégration automatisés et de les exécuter le plus souvent possible, plutôt que d’attendre la fin du cycle de fabrication de rapports BI.

La journée s’est terminée par un tour de salle où chacun a pu exprimer ce qu’il retenait de le journée. Les retours ont été dithyrambiques, Alexandre en a fait une synthèse sur son blog.

Xebia est ainsi fière, de mettre à votre disposition son contrat agile open source,  sur le site contrat-agile.org !

Ce contrat résultant d’une réflexion collégiale et de l’agrégation des différentes expériences de cabinets de conseil agiles, et d’un cabinet d’avocat spécialisé, propose aux donneurs d’ordres et aux prestataires, un cadre contractuel adéquat dans la mise en place de leurs projets informatiques.   

Soucieux de ne pas contredire la réalité du terrain et fort de notre propre expérience, nous nous sommes attachés à intégrer fidèlement les problématiques des directions achats, dans le respect total des valeurs agiles.

Visibilité budgétaire, engagement forfaitaire, évolution du périmètre fonctionnel, engagement et disponibilité de le MOA, priorisation par la valeur métier, sont autant de points d’achoppement, pour ne citer qu’eux, qu’il nous a fallu traiter pour aboutir à un contrat équilibré et pragmatique en tenant compte des contraintes de chacune des parties.

Attachée au partage de connaissances, Xebia a souhaité le rendre accessible à l’ensemble des acteurs de la communauté agile, sous Licence Creative Commons,  et vous invite donc à nous faire part de toutes vos suggestions à cette adresse : contact@contrat-agile.org.

Nous espérons par notre action, contribuer à la progression de la communauté dans ce domaine si exploratoire et complexe qu’est celui de la contractualisation agile.

Pour la troisième année consécutive Xebia sera présente à l’EPITA, jeudi 10 novembre, dans le cadre de la semaine annuelle de conférences technologiques, organisée chaque année dans les locaux de l’école.

Cette manifestation est toujours une occasion incontournable pour les étudiants de découvrir nos métiers et de rencontrer des professionnels de l’informatique. C’est Gilles Mantel, Chief Evangelist chez Xebia et fort de 10 ans d’expérience dans la gestion de projets agiles, qui ira cette année à la rencontre des étudiants. Il abordera un sujet très tendance, celui de la ludification du travail.

Partant du constat que les Serious Games prennent une place de plus en plus importante dans notre quotidien professionnel, notamment dans les organisations agiles, Gilles illustrera au moyen de cas concrets les apports de ce nouveau mode de travail. Il traitera aussi des éventuelles limites à y apporter.

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!

J’ai commencé la journée par la session Obeya Kanban de Laurent Morisseau. L’obeya c’est le lieu de travail d’une équipe dans le jargon Lean, et donc c’est un terme japonais. Si vous vous intéressez un peu au sujet vous savez qu’on aime bien parler japonnais dans le Lean, non pas parce que ça fait plus intelligent mais parce que ça vient de Toyota (cela dit ça fait aussi plus intelligent lors de vos dîners en société).

Laurent nous présente dans sa session le contenu et la disposition des informations visuelles autour d’une équipe qui fonctionne en Kanban. Laurent nous détaille progressivement les différents éléments de ces supports visuels et, ce faisant, revient sur certains points de l’approche Kanban pour les expliquer. On s’aperçoit au final que toute l’approche se matérialise d’une manière ou d’une autre sur les murs de son Obeya, dans l’une des zones suivantes: la cible, le planning, la tendance, le planning micro, les indicateurs de performances, le suivi des problèmes. Laurent ne se restreint pas qu’à Kanban puisqu’il nous donne également des parallèles avec SCRUM et ce que pourraient être ces différents éléments visuels: la cible est la vision, la tendance est le suivi de la vélocité, le planning est le burndown produit, le micro planning est le tableau d’itération, etc. Au final, derrière le simple titre, la présentation était riche d’informations et couvrait un spectre beaucoup plus large. La partie sur la gestion de la performance était notamment assez musclée. Elle me parle dans la mesure où j’ai un bagage d’ingénieur qualité, mais je suis plus sceptique quant à la généralisation d’une approche de la performance aussi systématique. Malgré ce bémol, la présentation était pleine de conseils utiles. Je retiens particulièrement la conclusion suivante: le management visuel doit être simple et créer un flux d’apprentissage pour l’équipe. Laurent nous indique deux critères de validation d’un bon management visuel: tout peut être dessiné à main levé et les problèmes doivent être visibles.

Sur le deuxième créneau j’animais ma session désormais bien rodée sur le ROI de l’automatisation des tests. J’ai profité de l’occasion pour en faire un remaniement cosmétique important et la rendre plus visuelle.  Je remercie au passage la personne qui m’a prêté son PC car j’ai rencontré des soucis de compatibilité entre mon Mac et le projecteur de l’amphithéâtre.

Pour la dernière présentation de la matinée j’ai choisi la session de Fabrice Aimetti sur la gestion de portefeuille agile. Là-aussi, derrière ce titre assez court se cachait une avalanche d’information et de références. Outre la gestion de portefeuille, Fabrice a parlé de formalisation des user stories, de présence du Product Owner, de planification agile, d’atelier d’innovation, de story map. Ce que j’aime c’est que Fabrice prend un soin tout particulier à citer et afficher ostensiblement ses références. On y trouve d’ailleurs la présence de notre collègue Hollandais Serge Beaumont pour sa définition d’une user story « prête ». J’ai surtout retenu de la présentation de Fabrice une succession de petites expressions croustillantes picorées ça et là ou de sa propre création:

• une vision sans action est une utopie, une action sans vision est un cauchemar
• le cahier des charges est surtout un cahier décharge
• un manager est quelqu’un qui utilise les hommes pour accomplir un travail, un leader est quelqu’un qui utilise le travail pour accomplir les hommes
• Faites développer à des équipes agiles des produits qui méritent de l’être
• Un atelier est une réunion dans laquelle le livrable est fait en séance

J’ai commencé l’après-midi avec l’atelier Problem Solving de Regis Medina. Le principe était de travailler sur la bonne définition d’un problème et pas tellement de chercher à le résoudre en séance. Régis nous a distillé une démarche pour aboutir à un plan d’action. Nous avons appliqué cette démarche par groupe de 3 sur nos propres situations, chacun proposant un problème aux autres pour collaborer sur sa définition. Regis nous a fait successivement travailler sur:

• l’identification du problème
• la formalisation de ses impacts
• la recherche de la situation standard qui n’a pas été suivi
• et les actions à prendre pour observer concrètement les causes du problème.

Il est intéressant de constater que l’on part souvent sur de faux problèmes ou des problèmes mal formulés car découlant de notre interprétation personnelle d’une situation. La formalisation d’un problème est objective et doit se traduire en un écart chiffré entre une situation donnée et le point de vue d’un client. Cet écart est l’expression même du problème. Je retiens aussi la mise en application très concrète de la technique des 5 pourquoi: on va voir 5 fois ce qui se passe (on utilise ses pieds), ce n’est pas un questionnement rhétorique!

Dernière présentation de la journée avec la roue de Demming des projets agiles vue par Thierry Montulé. Et là attention, il fallait attacher sa ceinture, remonter sa tablette, éteindre son téléphone, et surtout brancher son cerveau.

La présentation est partie dans les strates atmosphériques des principes agiles. Lorsque Thierry vous lache sur le ton de la discussion des phrases comme « le respect est une posture d’humilité assertive », vous avez intérêt à ne pas prendre de notes ou twitter ces morceaux choisis au risque de se laisser décrocher rapidement. Au détours de cette présentation à la fois dense et simplement structurée, Thierry présente les valeurs du pragmatisme avec la métaphore d’une voiture: la communication est le volant, le respect est l’embrayage, le feedback est le tableau de bord, la cooperation est l’accélérateur. Il transforme ensuite le triangle de fer des projets classiques en une pyramide mettant en perspective la méthode, les hommes, la structure, et le client. Thierry termine enfin avec sa roue de Demming qui superpose les valeurs du pragmatisme avec celles des processus empiriques, le système PDCA et ses axes d’amélioration. Simple et pourtant inexplicable sans la présentation qui va avec.

Pour laisser mon cerveau se remettre, j’ai terminé ma journée avec des ateliers ludiques organisés par l’équipe d’Agile Nantes. J’ai notamment aimé l’utilisation des origamis pour comparer différentes méthodes des collaboration. Ce qui est intéressant c’est que ce support est déclinable en grand nombre et qu’on peut recommencer le même exercice avec différents pliages pour éviter l’effet d’apprentissage et se concentrer sur les techniques de collaboration. Je pense que cela conviendrait tout à fait pour servir de support à un coach retreat.

Une riche journée donc, et toujours le plaisir d’échanger avec des meneurs du mouvement agile: salutations à Oana, Fabrice, et Laurent. Le plaisir également de croiser Eric un ancien collègue d’une précédente vie professionelle où l’on essayait d’inventer l’offshore à la française. Eric, rejoins le mouvement agile

J’ai le plaisir d’avoir été sélectionné pour animer ma session traitant du retour sur investissement de l’automatisation des tests. Sous la houlette de Laurent Morisseau et d’une équipe d’organisateurs investis, cette étape s’annonce déjà comme une belle réussite, en espérant ne pas leur porter malchance avec cette prédiction enthousiaste. Le programme concocté pour l’occasion présente un bon équilibre entre sessions pour débutants et sujets avancés, présentations magistrales et ateliers. Le programme fait aussi la part belle aux principes de Kanban pour l’informatique.

De mon côté j’ai pour l’instant porté mon choix sur les sessions suivantes :

• Dessine moi une Obeya Kanban par Laurent Morisseau.
• Agile Portfolio par Fabrice Aimetti.
• Atelier résolution de problème par Regis Medina.
• Le projet agile – la roue de Demming des SI par Thierry Montule.

Les inscriptions sont toujours ouvertes et la participation aux frais reste très abordable.

Comme l’explique Daniel Pink dans son excellent livre La vérité sur ce qui nous motive, ce qui fait que nous sommes impliqués dans notre entreprise, dans notre travail, ne dépend pas principalement de récompenses financières.

D’après lui, les trois véritables facteurs qui ont un réel impact sur la motivation sont :

• L’autonomie
  

  Notre « paramétrage par défaut », c’est l’autonomie et l’indépendance. Malheureusement, les circonstances -entre autres des notions périmées de management- concourent souvent à changer ce paramétrage et à faire baisser notre motivation intrinsèque. Pour favoriser la motivation intrinsèque et les bonnes performances qu’elle permet de réaliser, la première condition est l’autonomie. Les entreprises qui permettent à leurs salariés d’être autonomes, parfois de façon radicale, sont plus performantes que leurs concurrents.

• La maîtrise
  

  La maîtrise obéit à trois règles particulières :

  • C’est un état d’esprit : elle requiert la capacité d’envisager ses propres possibilités comme étant non pas finies mais infiniment améliorables.
  • La maîtrise suppose des efforts, des difficultés et une pratique délibérée.
  • La maîtrise est impossible à atteindre entièrement, si bien qu’elle comporte à la fois un coté frustrant et un côté attirant.

   

• La finalité
  

  Il est dans la nature humaine de rechercher la finalité, c’est-à-dire de trouver un sens à ce que l’on fait, un but qui dépasse notre propre condition. Or les entreprises ont longtemps considéré la finalité comme accessoire, comme un élément souhaitable tant qu’il n’interfère pas avec les choses importantes. Cette situation est en train de changer, en partie grâce au vieillissement des baby-boomers qui se retrouvent confrontés à leur condition de mortel. Dans les organisations, ce nouveau « motif de finalité » s’exprime de trois manières : sous forme d’objectifs de finalité dans lesquels le profit est un moyen, sous forme d’un discours qui met l’accent sur autre chose que l’intérêt personnel, et sous forme de mesures pour permettre aux salariés de trouver par eux-mêmes du sens à ce qu’ils font.

Inspiré par la lecture de ce livre, je vous propose d’adapter l’activité classique de rétrospective, XP Radar, au thème de la motivation.

Déroulement de l’activité

L’activité va permettre à chaque membre de l’équipe de déterminer son positionnement sur chacun des trois points, vus ci-dessus, et ainsi de trouver des axes d’actions pour améliorer la motivation de l’équipe.

Chaque membre de l’équipe répond à chacune de ces questions en attribuant de 0 à 10 points par question (10 étant une réponse optimale) :

Autonomie

Maîtrise

Finalité

Cette liste n’est en aucun cas exhaustive et devra être adaptée au contexte.

Résultat

A partir des moyennes de chaque membre, on peut ainsi tracer un radar pour chaque personne, puis un radar global pour l’équipe. Voilà ce que l’on peut obtenir :

Ce radar permet ainsi de facilement identifier les axes sur lesquels l’équipe va essayer d’intervenir pour accroitre la motivation et par conséquence sa productivité. Il est aussi intéressant de regarder individuellement les résultats afin de trouver des raisons de blocages plus individuelles.
Le plus important, comme dans toute rétrospective, est de déterminer un ensemble d’actions suite à l’analyse des résultats. En fonction des axes faibles identifiés, l’équipe sera amenée à définir une ou plusieurs idées d’amélioration. On pourrait ainsi définir :

• Organiser des formations interne à l’équipe autour d’un sujet.
• Passer une journée avec les utilisateurs pour mieux comprendre leur métier.
• Travailler le sens des user-story avec le Product Owner.
• Laisser plus de liberté à chaque membre dans le choix de ses tâches.
• Ne plus cloisonner les tâches en fonction des compétences spécifiques à chacun.
• Faire remonter au management les besoins d’autonomie de l’équipe.
• etc.

A noter, cette exercice sera plus efficace s’il est réalisé en compagnie de personnes du management afin de partager les différents points de vue, de discuter et de les sensibiliser directement.

Aller plus loin

Que l’on ne se méprenne pas, l’argent est, bien entendu, une condition nécessaire à la réalisation de notre travail. Nous ne travaillons pas par pure générosité, et insuffisamment rémunéré (en comparaison des salaires à l’intérieur et à l’extérieur de l’entreprise), nous sommes en général très vite démotivés.

Cependant, d’après les études, pour tous les travaux nécessitant de la réflexion, de la créativité, la carotte financière peut être négative plus que stimulante. En effet, elle aura tendance à tuer la créativité car elle pollue l’esprit de celui auquel elle est destinée. De plus, elle aura aussi pour effet de limiter cette créativité car elle arrive généralement avec un cadre correspondant aux critères de satisfaction du généreux donateur de la carotte.

Afin de creuser le sujet de la motivation, je vous conseille la lecture du livre de Daniel Pink, ou sinon le visionnage de la très bonne conférence donnée à TED.

André Comte-Sponville a également donné une conférence passionnante à l’université du SI intitulé : Sens du Travail, bonheur et motivation. Je vous encourage vivement à la regarder.

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

Agilité

• Compte rendu de la soirée Kanban Devops du French SUG
• Le compte twitter de la semaine

Le coin de la technique

• Eclipse Indigo: Indigeste ou Indispensable ?
• SVN 1.7: première version majeure chez Apache
• jQuery Mobile Beta 1 Released!
• Grails fait un bond en avant

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

• Roadshow #agile #offshore #xebia

Agilité

Compte rendu de la soirée Kanban Devops du French SUG

Le French Scrum User Group organisait vendredi dernier une soirée sous le double thème de Kanban et DevOps. Voici un bref retour des présentations.

Laurent Morisseau a commencé la soirée par une introduction progressive à Kanban. Partant de la description des piliers du Lean, le système de production de Toyota, il a déroulé un cycle de 5 étapes, mettant tour à tour en lumière un principe fondamental de l’approche appliquée à l’IT. Laurent a également abordé l’application de Kanban dans un domaine plus large que l’équipe de développement logiciel: Scrumban qui intègre la partie amont de la réalisation d’un logiciel, côté Product Owner, et DevOps qui intègre la partie aval côté opération / production. Laurent a terminé sa présentation en donnant des pistes pour une application encore plus large de Kanban: le principe de Lean Startup pour remonter au delà du produit logiciel et attaquer le business model, et le Lean IT pour adresser des intervenants encore plus en aval: équipes support, centres de service clients.

Dominica de Grandis nous a ensuite détaillé un retour d’expérience sur la mise en œuvre de Kanban depuis les équipes de dev jusqu’au équipe de prod au sein de Corbis. L’initiative a commencé en 2006 et Dominica nous présente l’évolution des travaux pendant 2 ans jusqu’en 2008. Il faut noter que la société s’est faite coacher par David Anderson, figure de proue du mouvement Kanban appliqué à l’informatique. Dominica nous raconte que l’optimisation continue du flux de tâches a conduit progressivement à l’émergence des valeurs portées aujourd’hui par la communauté DevOps. Ce que nous retenons de la présentation, au delà de slides un tantinet vintage, c’est :

• Les standups façon Kanban sont plus rapides car tout le travail est visible sur le tableau, donc personne n’a besoin de dire sur quoi il travaille, on se focalise simplement sur les obstacles
• Un créneau de 15 minutes était réservé après les standups pour tenir des discussions techniques, cela a conduit a sensiblement diminuer les interruptions de travail entre équipe pendant la journée, car chacun savait qu’il pouvait aborder des points techniques avec n’importe qui le jour suivant
• L’institution des « Operational Reviews » mensuels pendant lesquelles les performances financières sont présentées à l’ensemble des équipes, puis chaque équipe évoque à tour de rôle ses difficultés. Dominica nous explique qu’elle a obtenu un budget supplémentaire de la direction grâce à des graphiques très simples montrant les limites de capacité de son équipe
• Transparency = trust, vulnerability = empathy

Nous avons ensuite assisté à une présentation ping-pong entre Fabrice Aimetti et Antoine Vernois pour opposer, sans vraiment le faire au final, les approches SCRUM et Kanban. Tout y passe: approche globale, technique de gestion des nouvelles demandes, stratégie multi-produits, indicateurs clés, cible privilégiée. Cette présentation a déjà été jouée au ScrumDay 2011 et vous pouvez la voir en video sur Youtube.

Vous pouvez retrouver une rétrospective de cette soirée sur les blogs de Fabrice, Antoine, et Laurent.

Le compte Twitter de la semaine

Si vous voulez vous payer une bonne tranche de rire, suivez @AgileBorat sur Twitter. Et oui, Borat s’est reconverti dans le coaching Agile et il raconte son expérience sur Twitter, toujours dans un anglais approximatif. Inutile de vous conseiller en lisant ses tweets: n’essayez pas à la maison. Dans le même style @DevOps_Borat vous fera aussi sourire.

Décidément, Xebia ne recule devant rien pour vous donner les bonnes sources d’information.

Le coin de la technique

Eclipse Indigo: Indigeste ou Indispensable ?

Comme tout les ans, la fin juin est l’occasion de voir l’IDE Eclipse se refaire une beauté. Cette année, c’est sous le petit nom de Indigo que Eclipse 3.7 débarque. De plus en plus de lignes de code, de plus en plus de projet… Alex Blewitt nous donne sur son blog un aperçu de l’évolution du projet au cours des années. Le moins que l’on puisse dire c’est que du chemin a été parcouru depuis la V1 il y a pres de 10 ans ! Mais alors, cette année, à quoi peut t’on s’attendre ? Les nouveaux projet principaux sont les suivant:

• L’intégration de Maven, sous la forme du plugin M2E
• Eclipse Scout, qui est un framework basé sur la plateforme Eclipse pour écrire des application type client lourd (Swing, SWT) distribuées. Le serveur est basé sur Equinox tournant dans un serveur JEE. Un retour d’expérience est disponible chez Developpez.com.
• Jubula est un outil pour tester les IHM lourdes (SWT, Swing) comme légères (HTML).
• WindowBuilder dont nous vous avions déjà parlé
• Graphiti est une plateforme pour développer des outils de modélisations de modèles basés sur Java ou EMF
• Egit et Jgit sont respectivement les plugins fournissant l’interface d’Eclipse autour de Git et les accès bas niveau à Git. Bref, ce couple était attendu en version stable.

Concrètement, nous avons été déçus par M2E: cette release était l’occasion d’avoir enfin un support digne de ce nom de Maven dans Eclipse. Il faudra attendre.

• Tout d’abord, le package « Eclipse IDE for Java EE Developpers » ne contient pas M2E, contrairement à certains autres. Et nous ne sommes pas les seuls à qui il manque !
• Ensuite, si on veut l’installer, il faut faire attention: la version proposée sur le marketplace (par ailleurs un superbe outil pour bookmarker ses plugins favoris) est la V0.12.1 et non la nouvelle V1.0. Cette dernière est accessible par l’URL d’update suivante: http://download.eclipse.org/technology/m2e/releases.
• Enfin, cette nouvelle version « apporte » maintenant un concept de connecteurs. Les plugins de génération de code comme CXF ou JAXB doivent posséder leur connecteur spécifique dans Eclipse pour que la configuration des projets, et notamment les phase de génération de code source et le paramétrage des répertoires de source (target/generated-sources/jaxb par exemple) soient correctement effectués. On peut comprendre que pour une collaboration optimum entre Eclipse et Maven il y ait besoin de tels connecteurs, histoire que des modifications de fichiers ne soient pas faites dans le dos d’Eclipse. Mais toujours est-il que si l’on ne dispose pas de ces connecteurs, cela pose bien des problèmes. Et il est alors plus simple de continuer à gérer son workspace avec un bon mieux « mvn generate-sources eclipse:eclipse ».
• Pour couronner le tout, il semble que la version précédente continue à évoluer (en 0.13.0).

Bref, il semble que la confusion entourant M2E ne soit pas proche de son terme et le forum dédié risque d’être fréquenté encore un moment.

Sinon, pour plus d’information sur toute la fondation Eclipse et son fonctionnement, le dernier épisode des Cast Codeurs voit Emmanuel Bernard interroger Etienne Juliot, directeur commercial de Obeo et dans le secret de la fondation Eclipse. On y apprend notamment que l’année prochaine verra la sortie d’Eclipse 4.2: la plateforme est quasi-prête, mais toute la partie IDE Java est encore en développement. Vivement l’année prochaine ?

SVN 1.7: première version majeure chez Apache

Subversion est sorti en version 1.7. C’est la première release stable depuis son passage chez Apache.
Ce qui sautera immédiatement aux yeux du plus grand nombre (ou pas, si vous n’affichez pas les fichiers cachés !) est la disparition de ces innombrables répertoires « .svn » qui peuplaient les arborescence des projets. Qui n’a jamais écrit de script pour les supprimer facilement ?! Et bien ça ne sera plus la peine, tout sera maintenant stocké à la racine. Diverses optimisations sont aussi de la partie. Nous vous renvoyons à l’article sur le blog de Thomas Recloux ou aux release-notes officielles

jQuery Mobile Beta 1 Released!

Voici une nouvelle un peu tardive puisque l’annonce date déjà du 20/06 dernier, mais il ne fallait pas passer à côté. Avec cette première bêta, l’équipe JQuery souhaite lancer un nouveau calendrier avec une nouvelle release tous les mois. La version finale 1.0 étant attendue pour la fin de l’été. Parmi les nouveautés de cette version on retiendra surtout:

• Le support des navigateurs BlackBerry et Opera mini. La liste des plateformes supportées continue donc à s’allonger, mais on peut désormais considérer que la librairie adresse toutes les plateformes majeurs du marché (consultez la matrice des navigateurs supportés).
• Le support du masquage de la barre de navigation sous Android et iOS, qui nous permet de créer des interfaces plus immersive et de faire oublier encore un peu plus que l’application n’est pas développée en code natif.
• L’amélioration des transitions de page à page: le scroll est plus performant et plus fluide, mais de nouvelles améliorations sont encore à prévoir.
• La refonte de l’API de navigation afin de découpler les traitements et permettre aux développeurs de modifier le comportement sans mal.
• Le support de tous les formats d’URL possible (du chemin absolu au chemin relatif en passant par les différents protocoles).

Cette version contient bien d’autres améliorations et refactorings, dont vous pouvez consulter le détail dans l’annonce officielle. Avec ce passage, en version bêta, JQuery Mobile confirme l’essai et continue sur sa lancée pour proposer des IHM toujours plus fluide et dynamique dans les navigateurs mobile. Vivement la sortie de la version finale qui saura sans nul doute exploiter au maximum les performances des moteurs JavaScript.

Grails fait un bond en avant

Les amélioration apportées par Grails en version 1.4 ont été tellement appréciées que Graeme Rocher a proposé d’abandonner le numéro de version 1.4 et de passer directement à la version 2.0.

Parmi les nouveautés :

• Migration de bases de données et reverse engineering de schéma existant
• Gestion des Datasources multiples
• Scaffolding HTML5 compliant
• Mises à jour de la stack avec Groovy 1.8, Spring 3.1, Hibernate 3.6 et Servlet 3.0
• Nouvelle API de test intégrant le support de Spock
• Améliorations de performance

… et bien d’autres choses. Voir l’annonce sur grails.org.

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

Roadshow #agile #offshore #xebia

Jeudi dernier se tenait à l’hôtel Scribe l’étape parisienne du roadshow Agile Offshore organisé par Xebia. Le programme concocté pour l’occasion s’appuyait sur deux présentations magistrales et un retour d’expérience. Nous vous livrons ci-après un court extrait pour ceux qui n’ont pu participer.

Notre président Luc Legardeur a lancé l’événement avec une introduction retraçant rapidement l’histoire et les motivations de l’offshore dans les prestations IT. Luc précise que Xebia possède 8 ans d’expérience dans la mise en œuvre de l’agilité en contexte offshore. Cette expérience, acquise parfois dans la douleur, donne à Xebia la maturité et la crédibilité nécessaire pour prendre en charge ce type de prestation.

Anurag Shrivastava, président de Xebia India, a pris la suite de Luc pour nous brosser un tableau sans fard des perspectives de sous-traitance en mode offshore. Dans ce discours, qui tranche avec les messages consensuels, Anurag souligne le fait que l’offshore est porteur de beaucoup d’espoirs, souvent irréalistes: productivité importante, coûts faibles, ressources infinis, développements résilients (« follow the sun »). Anurag nous indique les facteurs clés de succès pour obtenir un retour sur investissement réel:

• construire une relation dans la durée en misant sur des équipes captives: la montée en compétence sur le métier du donneur d’ordre ne doit pas être galvaudée
• s’investir dans la connaissance de la culture distante
• éviter les contrats rigides et laisser de la place pour que l’équipe distante s’exprime
• donner des perspectives à l’équipe distante: ne pas sous-estimer l’aspiration des développeurs à tendre vers des technos récentes
• mettre en place l’agilité pour responsabiliser les équipes et partager les engagements.

Patrick Anfossi, directeur informatique au sein de la branche Environnement de Plastic Omnium, a ensuite partagé son retour d’expérience d’une part sur la transformation agile de son organisation, amorcée il y a 3 ans avec Xebia France, et d’autre part sur la mise en oeuvre d’un mode de réalisation agile distribué avec Xebia India et Xebia France. Les points marquants de la présentation de Patrick étaient les suivants:

• Avant la mise en place de l’agilité, Patrick explique que l’approche de Plastic Omnium était de faire faire. L’activité des intervenants de la DSI était donc principalement orientée gestion de contrat: rédaction de cahier des charges, définition de plans qualité, suivi contractuel
• Lors de la mise en place de l’agilité, l’approche n’a pas été de choisir un processus plutôt qu’un autre mais de réfléchir aux valeurs que la DSI souhaitait promouvoir, ces valeurs étant dérivées du manifeste des méthodes agiles
• La DSI est passée d’un mode hypercontractualisé à de l’assistance technique
• La difficulté à laquelle fait face la DSI aujourd’hui pour maintenir l’agilité dans la durée est d’aligner le métier sur cette organisation. le rôle de Product Owner par exemple est difficile à tenir car ses prérogatives sont réparties sur plusieurs individus et ils manquent de cérémonies pour entretenir une vision à moyen terme du produit. La notion de valeur est également diffuse, contrairement à un éditeur de logiciel où un bénéfice financier direct peut être estimé quasiment pour chaque fonction
• Patrick termine en expliquant l’organisation agile distribuée adoptée sur un de ses projets. Il a choisi de travailler avec l’Inde pour les possibilités de montée et descente en charge rapidement. Il souligne d’ailleurs que les profils de Xebia India sont de haut niveau à des TJM introuvables en Europe

Pour conclure cet après-midi, Laurent Sarazin a rejoué sa présentation du Scrum Day 2011 dans laquelle il présente son modèle Scrumshore, disponible en license Creative Commons. Un modèle qui se base sur de solides sources d’inspiration mais conserve une forme très pédagogique et facile d’abord. A utiliser sans modération en environnement distribué !

Agilité

• La communauté agile européenne se fédère

Le coin de la technique

• Un livre libre sur l’Architecture logicielle
• Lumière sur le futur Grails 1.4 : Tests unitaires

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

• L’avenir de Java se joue maintenant

Agilité

La communauté agile européenne se fédère

Il était temps que l’Europe s’émancipe un peu de l’énorme influence de son voisin américain en matière d’agilité. C’est sous l’impulsion de Jurgen Appelo, dont le blog est l’une des toutes premières sources de lecture de la communauté agile mondiale, que s’est créé un groupe Agile Lean Europe en février dernier. D’abord simple rassemblement d’agilistes sur LinkedIn, le groupe s’est depuis diversifié dans ses activités et dans ses échanges à une vitesse impressionnante. Les membres ne comptent pas leurs efforts pour fédérer les forces vives de l’agilité aux quatre coins de l’Europe.

Le premier rassemblement physique de ce réseau virtuel a eu lieu mi-mai lors de la conférence XP2011 en Espagne, avec une poignée de représentants de divers pays Européens, et cette rencontre a accéléré plus encore la débauche d’énergie pour créer une véritable culture européenne de l’agilité. Parmi les initiatives les plus marquantes on peut noter les deux suivantes:

• Les « bathtub conferences »: conférences virtuelles planifiées en soirée où chacun peut participer sans contrainte professionnelle ou résidentielle (et donc depuis sa baignoire si l’envie lui prend). La deuxième se tiendra le 30 juin de 21h à 23h (inscription ici), et vous pouvez retrouver les videocast de la première sur YouTube. On y parle notamment des tests automatisés chez eBay (comme quoi l’influence de notre voisin américain est encore bien présente ).

• ALE2011: la première « unconference » qui se veut pleinement européenne, prévue à Berlin en Septembre, les pré-inscriptions sont ouvertes. Attention, il y a un quota de 10 représentants par pays (on aime bien les quotas en Europe).

En conclusion, et si vous ne l’avez pas déjà fait, rejoignez le groupe ALE sur LinkedIn. See you there!

Le coin de la technique

Un livre libre sur l’Architecture logicielle

C’est par un lien donné par Emmanuel Lecharny sur le Google Group des Castcodeurs que nous l’avons découvert: un livre intitulé « The Architecture of Open Source Applications » vient de sortir. Comme nous l’apprend la FAQ, tout est parti de Greg Wilson, enseignant en Architecture logicielle au Canada, qui était frustré face aux livres existant sur le sujet. Il a donc été le chef d’orchestre pour rassembler divers écrits de personnes directement impliquées dans les projets Open Source qui on décrit leurs architectures respectives mais aussi quelques anecdotes sur l’historique des projets.
Parmi les projets, on retrouve des projets Java, mais pas seulement. Notons par exemple Eclipse, Hadoop, Selenium Webdriver mais aussi LLVM ou le système de packaging de Python. C’est donc un beau cadeau que ce livre et nous aurons tous beaucoup à retirer de ce tour dans les entrailles de tous ces projets.
Le livre est sous licence Creative Commons Attribution (CC BY 3.0) consultable en ligne, mais aussi téléchargeable en PDF ou disponible sous forme papier.

Lumière sur le futur Grails 1.4 : Tests unitaires

Sur le blog de SpringSource, Peter Ledbrook inaugure une série de billets sur les améliorations apportées par Grails 1.4. Le projet en est actuellement au stade de la première Milestone, et il semble que SpringSource tente d’intéresser un maximum de développeurs à la prochaine version de Grails. Le premier volet concerne les améliorations apportées aux tests unitaires. Parmi celles-ci on peut noter :

• Fin de l’utilisation de l’héritage pour les classes de tests.
• Implémentation en mémoire de GORM, pour un meilleur mocking du domaine.
• Facilitation des tests de contrôleurs renvoyant du JSON ou du XML.

Pour le détail, voir le billet chez SpringSource.

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

L’avenir de Java se joue maintenant

Cela ne vous a sans doute pas échappé: cette semaine fut particulièrement riche en évènements liés à l’avenir du langage Java et aux instances qui gouvernent son évolution. Voici un tour d’horizon des moments les plus marquants.

Coup de tampon sur Java SE 7

Tout commence par le vote public du JCP (Java Community Process) au sujet de la JSR 336. Les enjeux étaient de taille, vu qu’il s’agit ni plus ni moins de la JSR Umbrella qui chapeaute la version 7 de Java SE.

Commençons par les bonnes nouvelles: la JSR a été approuvée! L’évènement a d’ailleurs été abondamment commenté, par exemple par nos confrères de Développez.com, de H Online ainsi que par Nicolas Martignole, et les résultats sont disponibles ici.

Java SE 7 est donc sur les rails, et c’est plutôt rassurant quand on pense que les spécifications finales et l’implémentation de référence sont attendues pour le 28 juillet prochain. Mais lorsqu’on se penche sur les détails du vote, le tableau est hélas nettement moins rose.

Certes VMWare, la Fondation Eclipse, Intel, SAP, HP, Ericsson et bien entendu Oracle lui-même ont voté pour sans réserves. Mais de nombreux membres — IBM, Red Hat, Goldman Sachs, Fujitsu ainsi que les JUGs brésilien (SouJava) et londonien (London Java Community) — ont émis de sérieuses réserves et ont tous souligné que leur approbation était due exclusivement aux « mérites techniques » de la JSR.

Quant aux grincheux, nous retrouvons Werner Keil qui s’est abstenu, et surtout Google qui — sans surprise — a voté contre.

Mais que reprochent-ils à cette JSR et, par-delà, à la firme de Larry Ellison?

Il s’agit tout d’abord du vieux problème des licences du TCK, dont la revue de presse s’est fait l’écho ici et là. Sun, puis ensuite Oracle, auraient placé des restrictions d’usage (Field of Use restrictions) restreignant les plateformes sur lesquelles le langage Java peut tourner et être certifié — nous y reviendrons.

La principale victime de cet état de faits est aujourd’hui Google et l’utilisation qu’il fait du projet Apache Harmony dans son système d’exploitation Android. En plein procès contre Oracle à ce sujet, Google a tenu à manifester son mécontentement par un vote négatif assorti d’un commentaire acerbe: « les licences du TCK ne doivent pas être utilisées pour restreindre ou créer une discrimination à l’encontre d’implémentations compatibles des spécifications Java en incluant des restrictions d’usage sur les implémentations testées. De telles licences ne sont pas conformes aux exigences du JSPA, et violent les attentes de la communauté Java quant à la libre implémentations des spécifications du JCP ». Pour rappel, le Java Specification Participation Agreement (JSPA) est le contrat même d’engagement des membres du JCP.

Un autre point vertement reproché à Oracle, notamment par les JUGs brésilien et londonien, concerne le manque de transparence du JCP lui-même. Oracle ferait preuve de mauvaise volonté à rendre publiques les archives de certains Expert Groups, en particulier celles du Project Coin. Cette attitude a manifestement compliqué la tâche des votants, à tel point que Werner Keil n’hésite pas à parler de « développements en cachette » — un comble pour un langage Open Source.

Y a-t-il un pilote dans l’avion?

Certains — Stephen Colebourne pour ne pas le nommer — n’hésitent pas à voir dans ce vote moins un satisfecit pour Java 7 qu’un arrêt de mort pour les ennemis d’Oracle, Apache Harmony en tête.

Dans son blog, Colebourne estime en effet que « le vote favorable ne fut possible que parce qu’Oracle a pris la décision de tuer Apache Harmony ». Il ne ménage d’ailleurs pas les membres actuels du JCP qu’il traite de « zombies » à la solde d’Oracle.

Or, malgré les protestations lors du vote, Oracle ne semble pas changer de cap. Quelle est sa stratégie actuelle?

Depuis le rachat de Sun, il semble que deux axes se dégagent dans la stratégie d’Oracle vis-à-vis de Java:

1. Empêcher les forks incontrôlés de Java pour des plateformes spécifiques (cf. Apache Harmony);
2. Conserver la sphère du développement mobile comme une source potentielle de revenus (cf. Google).

Toujours d’après Colebourne, c’est en effet à la lumière du procès Google vs. Oracle que l’on comprendrait mieux pourquoi Sun puis Oracle ont mis tant de soin à verrouiller la licence du TCK et se sont acharnés contre Apache Harmony. Le bouillant spec lead de la JSR «  Three Ten  » rappelle d’ailleurs qu’initialement Sun avait donné tous les gages nécessaires à la Fondation Apache; ce n’est que plus tard, sentant le danger imminent et notamment le risque de perdre la bataille sur le terrain du développement mobile, que Sun aurait retourné sa veste avec cette trouvaille juridique de génie que nous connaissons bien maintenant: la licence du TCK. Toujours selon Colbourne, cette stratégie est enfin sortie de l’ombre lors du comité exécutif du JCP du 6 octobre 2010: Oracle a alors exprimé publiquement ses craintes qu’Apache Harmony ne crée une menace de « fork » — menace que Google et son système Android, toujours d’après Oracle, auraient su habilement exploiter.

OpenJDK: libre certes, mais incontournable?

Chat échaudé craint l’eau froide: le différend avec Google est loin d’être terminé, mais Oracle semble d’ores et déjà en tirer les conséquences et veut désormais éviter de nouvelles menaces du type Google/Harmony en misant toutes ses cartes sur OpenJDK, projet auquel Oracle a habilement réussi à rallier IBM puis Apple.

Et c’est là qu’intervient le deuxième fait marquant de la semaine, signalé entre autres par nos confrères d’H Online: le 9 juin dernier, Henrik Ståhl, directeur des produits chez Oracle, a annoncé sur son blog que la nouvelle version de Java utilisera OpenJDK pour son implémentation de référence et non plus le JDK « maison » Sun/Oracle.

C’est à nouveau une affaire de licences: le JDK de Sun/Oracle est distribué sous la licence Binary Code (BCL). Cette licence est incompatible avec des implémentations Open Source (comme OpenJDK) en raison de composants comme le plugin Java, qui ne font pas partie du standard Java.

Oracle choisit donc de conférer à OpenJDK ses lettres de noblesse, en faisant de ce projet l’implémentation de référence de Java 7.

Concrètement, comment cela se passe?

D’après Ståhl, l’implémentation de référence sera disponible sous une double licence: BCL pour les implémenteurs commerciaux et GPL v2 avec exception de classpath pour les implémenteurs Open Source.

Autre changement notable: OpenJDK possède son propre TCK et la licence qui l’accompagne, baptisée OCTLA (OpenJDK Community TCK Licence Agreement), sera mise à jour afin de couvrir Java 7; le TCK sera alors théoriquement utilisable gratuitement par tout implémenteur Open Source.

Est-ce donc la fin du conflit autour du TCK?

Pas vraiment: les internautes, répondant à Ståhl, font observer que la licence OCTLA ne s’applique qu’à des implémentations « substantiellement dérivées » d’OpenJDK, et qui plus est, en cas de distribution par une tierce partie, impose qu’elles le soient sous licence GPL. La porte reste donc toujours close pour Apache Harmony… Ståhl enfonce d’ailleurs le clou: « rien de tout cela ne changera le refus d’Oracle d’accorder à [...] Apache Harmony un accès au TCK à des fins de certification; en effet l’OCTLA ne donne accès libre au système de tests qu’aux implémentations dérivées [...] d’OpenJDK ».

Pour les détracteurs d’Oracle, il s’agit d’une manoeuvre dont le but est de se dédouaner auprès de la communauté Open Source: oui, Oracle fait bien de l’Open Source! Ne l’a-t-il pas d’ailleurs rendu JRockit gratuit? Et désormais, voilà que vous pouvez créer librement votre propre implémentation de Java 7! Vraiment? Tant qu’on reste dans le giron OpenJDK, sûrement; mais au-delà, il n’y a probablement pas de salut. Ce que Colebourne résume par une savoureuse boutade: « Apache OpenJDK anyone? »

Les statuts de la Communauté OpenJDK font peau neuve

Troisième fait marquant de la semaine, mais qui découle du précédent: le 14 juin dernier s’est ouvert le vote pour la ratification des statuts de la Communauté OpenJDK. Ce vote prendra fin le 28 juin prochain.

Les statuts gouvernent le fonctionnement de la communauté OpenJDK: groupes, adhésion, procédures de contribution, gouvernance, etc.

L’électorat est constitué des contributeurs ayant « créé au moins 5 changements uniques et non-triviaux dans les dépôts Mercurial d’OpenJDK dans les deux années précédant le vote de ratification ». Or on s’aperçoit très vite que l’immense majorité des votants est affiliée à Oracle; même si quelques « dissidents » sont bien présents (Doug Lea notamment), certains ne manqueront sûrement pas de mettre en doute la légitimité d’un tel vote.

JCP++

Ce n’est pas à proprement parler une actualité, puisque cela date du 17 mai dernier, mais la nouvelle prend tout de même une autre dimension: le JCP va bientôt faire peau neuve.

Baptisé « JCP.next », ce JCP renouvelé sera défini par deux JSRs: 348 et 349 (cette dernière n’étant pas encore publiée).

La JSR 348 introduira des changements dans le fonctionnement du JCP lui-même. A la clé, quatre axes d’améliorations: transparence, participation, réactivité et gouvernance. Et la transparence, lorsqu’on se souvient du vote de la JSR 336, tombe à pic: entre autres, toutes les opérations des Expert Groups devront être menées dans des forums publics; les processus de recrutement de leurs membres seront également publics.

Mais il y a mieux: la JSR 349 quant à elle s’attaquera au JSPA. Or, on l’a vu, c’est là que le bât blessera très fort. Nos confrères d’IT World et de H Online notent à juste titre que le JSPA est au coeur du contentieux entre Apache et Sun/Oracle, la première accusant les seconds de ne pas la respecter.

Amender le JSPA, c’est donc jouer avec le feu; on ne peut qu’attendre avec impatience de voir comment Oracle s’y prendra.

Mais a-t-il seulement le choix?

Depuis quelques mois déjà le JCP est délaissé par des acteurs de première importance: la Fondation Apache d’abord, puis Doug Lea. Pour beaucoup, Stephen Colebourne et Doug Lea en tête, le JCP fait aujourd’hui figure d’institution sclérosée; ils veulent pour preuve des graphiques comme celui-ci, montrant le déclin dans le nombre de JSRs depuis quelques années. Pour d’autres, comme Nicolas Matignole, il est au mieux un moyen de faire face à l’adversité. Il n’est guère que le JUG londonien pour en vanter encore les mérites.

Après l’échec de sa stratégie concernant OpenOffice, Oracle semble cette fois-ci décidé à tirer les leçons de ses erreurs du passé: en adoptant Java SE 7, en mettant en avant OpendJDK, en réformant enfin le JCP, Oracle est peut-être enfin en train de donner des gages sérieux de pérennité au langage Java. Espérons seulement que la future JSR 349 nous donnera raison.

• Date : 23 Juin 14h00.
• Lieu : Hôtel Scribe, 1 rue Scribe, Paris 9ème.
• Consulter le programme et s’inscrire.

Distance entre client et prestataire, différences culturelles, barrière de la langue, manque de visibilité et de contrôle, turn over élevé, compromis sur la qualité sont autant de freins à l’adoption du modèle Offshore pour les DSI françaises.

Ce séminaire tentera d’expliquer comment le modèle d’ingénierie agile distribué, fruit d’une longue expérience, proposé par Xebia et reconnu par la communauté agile internationale peut supprimer ces obstacles et résoudre l’équation coût / qualité / adéquation aux besoins métiers.

Après une présentation de ce modèle par Anurag Shrivastava et Luc Legardeur, respectivement Directeur Général de Xebia India et Président de Xebia France, deux entreprises témoignent : Plastic Omnium et la Société Générale CIB.

Programme

• Café d’accueil.
• Introduction par Luc Legardeur.
• Craintes, espérances et réalités du modèle Offshore par Anurag Shivastava (en anglais).
• Témoignage de Plastic Omnium par Patrick Anfossi (Responsable des Systèmes d’Information).
• Pause
• Le modèle ScrumShore de la Société Générale CIB par Laurent Sarrazin (Head of IT Offshoring Solutions).
• Questions & Réponses

Dans l’attente d’avoir le plaisir d’éventuellement vous y rencontrer.

Un développeur aguerri applique quotidiennement beaucoup de ces principes, souvent par automatisme et expérience, mais éprouve généralement une grande difficulté à les énoncer clairement, à les recenser de manière exhaustive et a fortiori à les partager avec ses pairs. Or c’est sur le partage, la transmission et l’application de ces bonnes pratiques que repose la progression d’une équipe et l’amélioration continue de la qualité du logiciel développé.
Forts de ce constat, les consultants Xebia se sont posés comme défi d’extraire, trier et consolider ces bonnes pratiques, à partir de leurs expériences de terrain, dans le but de pouvoir les restituer sous forme synthétique puis de les partager entre eux et avec la communauté.

Le fruit de 6 mois de ce travail de consolidation, que Xebia est fière de vous dévoiler aujourd’hui, se présente sous la forme d’un ensemble de « flash cards », baptisées Xebia Essentials.

Concrètement, chacune de ces flash cards isole une bonne pratique ou un principe, énoncé de manière synthétique et facilement mémorisable sur son recto, détaillée au verso, et identifiée par un code couleur qui détermine le domaine auquel elle s’applique (code, architecture & design, test, process, état d’esprit …). Cerise sur le gâteau, chaque carte affiche un code-barres 2D qui permet, à partir d’un simple scan avec son téléphone mobile de retrouver une page web détaillée qui apporte des compléments sur le contenu de la carte elle-même (voir la vidéo).

Nous croyons que cette présentation sous forme de cartes, par son caractère pratique et ludique, est un formidable moyen de partager des pratiques de développement essentielles et de les mettre en application sur les projets.

Ces flash cards, initialement destinées à nos consultants et aux équipes projet chez nos clients, seront finalement mise à disposition de la communauté prochainement, à travers notre site.

Cette année, 5 Xebians vous feront partager leurs expériences et leurs pratiques :

• Jean-laurent De morlhon : Software Craftsmanship: en pratique.
• Gilles Mantel : Automatisation des tests : le mythe du ROI.
• Katia Aresti et Xavier Renaudin (Valtech) : 10 ans après… Ma première expérience agile.
• Nicolas Jozwiak : Au secours, pourquoi ma vélocité n’augmente-t-elle pas ?.
• Nathaniel Richand : Pratiques avancées de tests.

Retrouvez le programme complet et Inscrivez vous !

Ceci est une fiction. Toute ressemblance avec des personnes existant ou ayant existé serait totalement fortuite.

Palais de justice de Paris, lundi 21 mars.

Une fois n’est pas coutume, des développeurs sont assis sur le banc des accusés! Ils sont inculpés de faire perdre des millions d’euros à nos chères compagnies du CAC40 en écrivant du code voué à crouler sous son propre poids.

Mr Tedd, praticien du Test Driven Development, est aujourd’hui jugé ainsi que quelques uns de ses collègues : Mr Whatever, Mr Guru, Mrs Clickaway et Mr Testafter.

Prévoyant et confiant, il sera défendu par son avocat : Maître Darrow. Ils ont convenu ensemble de la stratégie à adopter: il faudra pointer du doigt les mauvaises habitudes souvent utilisées et mettre en avant les bonnes pratiques qu’il a appliqué tout au long des projets qui lui ont été confiés.

L’audience est ouverte

Le Président, Mr Beck, ouvre la séance en rappelant les chefs d’accusations aux jurés:

• Le code applicatif contient trop de bugs
• Le code applicatif n’est pas testé
• Le code applicatif est pour la plupart du temps incompréhensible et reste trop volumineux pour le nombre de fonctionnalités
• La modification et l’amélioration du code applicatif existant est trop risqué à entreprendre

La parole est à la défense. Maître Darrow, soucieux de capter l’attention de son audience, rappelle le contexte:

Nous sommes en 2011. Dans les missions dans lesquelles mon client, Mr Tedd, intervient, écrire du code représente 80% de son temps. Ce code capture des règles métiers plus ou moins complexes et qui évoluent dans le temps. Visuellement son travail se traduit souvent par ce qu’on appelle un front end sur lequel un utilisateur tel que vous et moi pouvons interagir. Un bon exemple serait un site de réservation de billets de train au niveau Européen. Vous voyez donc, Messieurs et Mesdames les jurés que l’enjeu est de taille, l’erreur coûte chère et qu’elle n’est donc pas acceptable.

Aujourd’hui, je vais vous démontrer que mon client, Mr Tedd, adopte les pratiques adéquates pour rendre son code fiable, évolutif et pérenne.

Laissez-moi d’abord vous présenter quelques types classiques de développeurs. Si je n’enlève rien aux connaissances techniques et aux talents d’ingénieurs de ces personnes, je leur reprocherais cependant une attitude trop laxiste quant à la fiabilité et la pérennité du code qu’ils soumettent mais aussi une négligence au regard des méthodes qui permettraient d’améliorer considérablement la qualité globale des projets auxquels ils participent.

Permettez-moi de commencer par le cas de Mr Whatever.

Mr Whatever

Tous les regards se tournent vers ce grand gaillard assis au bout du banc des accusés.

Mr Whatever, si vous me permettez de vous citer, vous m’avez dit :

« Moi je fais juste confiance à mon code. Il compile c’est donc qu’il fonctionne. »

Je pense que Mr Whatever n’est jamais resté assez longtemps dans les entreprises pour lesquelles il travaillait pour savoir que son code en production posait plus de problèmes qu’il n’en résolvait. Je rappelle pour les profanes dans l’assistance, que la production est la plateforme exposée au grand public donc aux vrais utilisateurs. C’est dans cet environnement que la charge sur le système se révèle soutenue et que, potentiellement, tous les chemins possibles dans le code écrit sont réalisés en concurrence !

Le problème de Mr Whatever est qu’il ne sait réellement si son code fonctionne que lors de la phase de tests intensifs. Pour lui, tester c’est la tâche de ce que l’on appelle l’équipe de QA, tiré de l’anglais Quality Assurance, et qui s’assure de la qualité du logiciel fournit. Si son code ne fonctionne pas, ils le lui indiqueront et il corrigera. On voit bien que sa responsabilité de fournir du code qui fonctionne lui échappe.

L’avocat se tourne vers l’audience et continue :

Nous ne nous attarderons pas plus sur le cas de Mr Whatever, il appartient à une génération un peu dépassée par les événements.

Cette dernière phrase entraine de légers gloussements dans l’assistance.

Mr Guru

Maître Darrow, après avoir jeté un rapide coup d’œil aux papiers étalés sur son bureau, se tourne vers la personne assise aux côtés de Mr Whatever.

Passons au cas de Mr Guru. Cas intéressant puisqu’il représente l’archétype de l’informaticien auquel on accorde toute sa confiance !

Ses connaissances et son expérience en font un expert dans l’écriture du code. Cependant, il ne teste jamais ce qu’il écrit. Il n’introspecte pas. Perte de temps pour lui ! Il a écrit assez de plateformes pour savoir comment écrire la vôtre. Très bien. Nous aurons alors un code de qualité. Cette affirmation est correcte si votre équipe n’est formée que de Mr Guru ! Situation atypique s’il en est, et bon courage pour les batailles d’ego. Mais bon … passons.

L’avocat lève le bras pointant l’index vers le plafond et lance :

Si notre postulat de départ est que les entreprises ne travaillent qu’avec des profils tels que celui de Mr Guru, voici les problèmes que cela entrainerait :

Maître Darrow marque un silence pour permettre aux jurés de bien se concentrer sur ce qui va suivre.

Le premier problème serait une pénurie rapide de Mr Guru sur le marché. Toutes les entreprises ne pourraient pas en recruter et seraient dans l’incapacité de produire des applications de qualité. Un peu fantasque je vous l’accorde, mais totalement valide avec le postulat de départ.

Le deuxième problème impacterait le budget de l’entreprise. Un Mr Guru cela coûte cher ! Combien seriez-vous prêt à dépenser pour une armée de Mr Guru ?

Le dernier souci, et non des moindres, serait de s’assurer qu’on ne recrute que des Mr Guru. S’il y a un responsable des ressources humaines dans la salle, il m’accordera que la tâche se révélera ardue. Par ailleurs, je note aussi qu’il arrive à Mr Guru d’être fatigué ou d’être ennuyé, Guru ou pas, il reste humain. De ce fait, il est toujours possible qu’un expert introduise des erreurs dans votre code de production sans le vouloir.

De plus une question se pose. Faut-il bannir les développeurs juniors de votre équipe de développement ? Avons-nous peur qu’ils insèrent des erreurs dans le code ? Un bon manager vous dira que cela serait une faute. Une équipe doit être hétérogène en caractère. Pourquoi se couper du dynamisme des développeurs juniors, de la facilité avec laquelle ils manient les dernières technologies et de leur passion encore verte pour la programmation ?

Après une longue pause, l’avocat fixe chaque membre du jury tour à tour, et conclut :

Nous voyons bien qu’en réalité une équipe est constituée de profils différents et hétérogènes en compétence. Il nous faut donc une pratique commune de développement qui nous assure que Mr Guru et son collègue, plus junior, écrivent leur code d’une manière uniforme et testée sans porter atteinte à leur créativité.

Dans la salle, quelques personnes opinèrent du chef. Sûrement des développeurs!

Mrs Clickaway

L’avocat se rapproche de quelques pas du jury tout en désignant de la main la jeune femme assise au milieu du banc des accusés.

Maintenant le cas touchant de Mrs Clickaway. Mrs Clickaway est bien intentionnée. Elle veut savoir si son code fonctionne. Pour cela elle adopte un cycle rapide d’écriture de code, et de déploiement de son application dans son environnement local. Pour tester, elle clique et re-clique jusqu’à ce qui lui semble avoir parcouru tous les recoins des fonctionnalités qu’elle a implémentées. Pourtant, Mrs Clickaway utilise très mal son temps de développement. Pour les plus techniciens d’entre vous, je dirais qu’elle oscille entre stacktrace, long démarrage de serveur et debuging en tous genres !

En effet, alors qu’elle aurait l’opportunité d’écrire son code tout en l’introspectant, grâce aux trés bonnes librairies logicielles mises à disposition aujourd’hui, elle choisit de tester en mode boite noire. Pour les profanes dans la salle, le mode boîte noire est une série de tests qui se fait à un haut niveau de l’application sans se préoccuper réellement de la structure et du fonctionnement interne.

Je reproche donc à Mrs Clickaway de ne pas se concentrer sur son coeur de métier qui est la production d’un code propre et fiable. Pour être franc, je pense que Mrs Clickaway n’est jamais sûre de ce qu’elle écrit et qu’elle veut se donner bonne conscience avant de livrer son code à l’exploitation.

Je vous le dis, ne pas choisir l’introspection, c’est ne pas choisir de réfléchir sur ce que l’on produit et c’est ne pas choisir l’amélioration de son propre code. Mesdames et Messieurs les jurés, vous m’accorderez que c’est un peu surprenant et relève d’un comportement irresponsable pour un développeur.

Sur le banc des accusés Mrs Clickaway semble anéantie et confuse par cette série d’accusations.

Mr Testafter

Passons maintenant à mon cas favori. Mr Testafter.

Mr Testafter est sur la voie de la rédemption, seulement il a pris à gauche alors qu’il fallait prendre à droite ! Que je vous explique. Mr Testafter a bien compris qu’il fallait tester son code. Cependant, il écrit les tests après avoir écrit ce fameux code de production. Normal vous me direz. Eh bien non ! Cela pose plusieurs problèmes:

Comme tous les développeurs, Mr Testafter passe beaucoup de temps à écrire son code. Quand il en a enfin fini, c’est un soupir de soulagement avec une pause café bien méritée. Enfin jusqu’à ce qu’il réalise qu’il n’a écrit aucun test ! Pour ne rien arranger, il a déjà indiqué fièrement à son manager que son travail était fini. Qu’à cela ne tienne, il va ajouter rapidement les tests, parce qu’après tout, il n’a pas que ça à faire.

C’est à ce moment qu’il doit faire un effort non négligeable: se remémorer les spécifications, imaginer des cas d’utilisations pour finalement… relire son code afin de savoir quoi tester !

L’avocat lance un regard vers Mr Testafter sur le banc des accusés. Ce dernier fixe le plafond.

Idéalement, s’il veut que ses tests soient utiles, c’est-à-dire compréhensibles par un autre développeur, clairs, découpés en spécifications et couvrant toutes les fonctionnalités, il doit reprendre sa réflexion à zéro.

Cependant, Mr Testafter à ce moment précis est pressé. Il n’adoptera pas une démarche d’écriture « fonctionnalité par fonctionnalité ». Plus grave, il ne pensera pas aux effets de bord, car puisque son code est déjà écrit, il est censé fonctionner ! Summum du contre-sens, pour les praticiens du TDD dans la salle, Mr Testafter ne passe pas par la phase d’un test qui échoue. En réalité, Mr Testafter ne voit aucun test échouer ! Bizarre pour quelqu’un qui veut savoir si son code fonctionne.

Une fois les tests ajoutés, laissez-moi vous décrire le résultat, cela se vérifie presque à chaque fois. Il y a toujours plus de code généré qu’il n’en faut et le code contient de la duplication. Mr Testafter n’est pas dans une optique de code minimal pourtant si importante dans les énormes bases de code d’aujourd’hui. Les tests sont désordonnés, ne sont pas organisés en terme de fonctionnalités et contiennent eux aussi de la duplication.

Invariablement aussi, une fois les tests ajoutés, le code restera tel qu’il a été écrit à l’origine. Pas d’optimisation, de minimalisation ou de recherche d’expressivité du code. Le plus grave cependant est d’obtenir ce que l’on appelle un effet gruyère sur la classe testée: des bouts de code resteront non testés. Pour ceux qui me suivraient encore dans l’assistance, je ne vous conseille pas de refactorer du gruyère !

Sur cette dernière phrase, l’audience se partage entre face crédules et sourires.

Mr Tedd – Vers un code agile

Il est l’heure maintenant pour Mr Darrow de défendre son client. Il tient à expliquer aux jurées les principes fondamentaux sur lesquelles repose la méthode que son client Mr Tedd utilise. Il enchaine alors :

A travers les différents profils que je vous ai présenté, nous avons pu voir les insuffisances de certaines techniques de développement.

Laissez-moi donc maintenant vous résumer la manière d’écrire du code applicatif la plus à même à répondre à la problématique de tolérance au changement du monde du logiciel. C’est celle que pratique mon client. C’est le Test Driven Development. Cette méthodologie se résume avec la phrase suivante :

Tout code de production a été écrit pour faire passer un test qui au départ échouait.

Ce postulat pour certains peut sembler abstrait, cependant il se met en pratique tous les jours avec succès. Laissez-moi maintenant énumérer les corollaires directs de ce postulat.

Dans la salle on aurait pu entendre une mouche voler. L’avocat commence à énoncer :

Tout code de production est donc testé. Il n’y a pas plus de code que de fonctionnalités voulues et votre base de code est donc minimale. Toute fonctionnalité étant couverte par un test, vous savez instantanément lorsqu’un test échoue qu’une fonctionnalité n’est plus respectée et vous pouvez prendre aussitôt les mesures appropriées.

Ce code, proprement testé, vous pouvez le simplifier, l’améliorer et le nettoyer sans risque. C’est ce que l’on appelle le refactoring. Votre code devient par conséquent malléable, flexible et donc agile. C’est le moyen d’éviter que votre code ne s’effondre sous son propre poids !

L’avocat continue :

Mesdames et Messieurs les jurés, je vous le demande : Pour ceux qui connaissent le monde du logiciel, quel est le mot le plus important dans l’agilité?

Au vu des visages dubitatifs du public, et de cette femme âgée assise au premier rang qui avait commencé à tricoter, Maître Darrow comprit qu’il aurait à apporter lui-même la réponse.

Le Feedback ! Voilà le concept le plus important à mettre en place. Le Test Driven Development vous permet de mettre en place la plus petite boucle de feedback du monde agile. Instantanément vous savez si votre code répond à vos exigences.

Alors que Mr Darrow est au beau milieu de la défense de son client, le président Mr Beck, avec un geste d’impatience de la main, déclare :

Merci Mr Darrow. Cependant, avant que vous poursuiviez, l’avocat de la partie civile souhaite interroger maintenant votre client Mr Tedd. Et exceptionnellement, je ly’autorise.

Mr Darrow ne peut qu’abdiquer et Mr Tedd se dirige alors vers la barre pour être interrogé. C’est alors qu’un petit homme au front suintant, très agité, s’avance au centre. C’est Mr Pascal, l’avocat de la partie civile. Le contre interrogatoire peut commencer.

La suite du procès dans un prochain article.

La semaine prochaine se tiendra la conférence Mix-IT (prononcez « mixité ») à Lyon. 25 speakers animeront la journée dans 5 salles en parallèle. Le but est de fournir des sujets variés et complémentaires, autour de 5 thèmes :

• Techy : Java et son écosystème
• Agility : L’agilité pour débutants et passionnés
• Trendy : Tendances novatrices et avant-gardistes
• Mixy : Le meilleur de l’agilité et des technologies Java
• Gamy : Jeux agiles et coding dojos

Cet évènement est organisé par le Lyon JUG et le Club Agile Rhône-Alpes.

En vrac, on y parlera de : Play!, Product Owner, Clojure, Coaching agile, Apache Mahout, BDD, Grails, DevOps, Spock, HTML5, Code retreat et bien d’autres sujets.

Vous pouvez découvrir le programme complet à cette adresse.

Xebia participe à cet évènement en animant 2 slots :

• Grails from scratch to Prod, par Aurélien Maury (@aurelienmaury)
• Intelligence collective avec Apache Mahout, par Michaël Figuière (@mfiguiere)

Les places sont comptées (200 spectateurs) donc dépêchez-vous de vous inscrire !

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 .

Durée du projet

Si vous choisissez un projet trop court, les sceptiques vont clamer haut et fort que Scrum ne fonctionne que pour les petits projets. À l’inverse, si vous optez pour un projet trop long, vous risquez de ne pas pouvoir montrer votre succès avant son terme. On compte 9 à 12 mois en moyenne pour un « projet traditionnel » ; où budget et deadline sont souvent dépassés. Il serait dommage de lancer un projet Scrum en annonçant le même timing qu’un projet classique et donc entouré des mêmes doutes. L’idéal est de choisir un projet de moitié plus court qu’un projet classique ; 3 ou 4 mois suffisent généralement à prouver que l’application de Scrum est concluante et le serait pour une plus longue durée.

Taille du projet

Choisissez un projet qu’il est possible de commencer avec une seule équipe dont tous les membres sont colocalisés. Si la taille du projet vous sembler nécessiter plusieurs équipes, débutez tout de même avec une seule et limitez vous dans le nombre d’équipes, même si votre organisation a l’habitude de réaliser des projets de très grande envergure. Les soucis de coordination ne doivent pas être un frein pour ce premier projet agile.

Criticité du projet

Quand on expérimente, on a tendance à le faire sur quelque chose qui n’a pas d’importance et qui comporte peu de risques. Si les choses tournent mal, on aura perdu peu et avec de la chance personne n’aura rien remarqué. Ne cédez pas à cette tentation ! Allez à l’encontre de cela et choisissez un projet important. Si votre projet n’a pas de valeur, personne ne lui accordera d’attention au sein de votre entreprise. Et, comme la transition d’une équipe classique vers une équipe Scrum est exigeante, les protagonistes ne feront pas les efforts nécessaires si le projet n’apporte rien. Jim Highsmith, pionnier de l’agile et inventeur de « l’adaptative software Development process » nous met en garde sur ce sujet :

« Ne commencez pas avec un projet pilote qui est marginal. Commencez avec un projet qui est critique pour votre société, sinon il sera trop difficile de faire tous les efforts que l’implémentation de la méthode requiert. »

Le soutien du métier pour le projet

L’adoption de Scrum requiert un investissement total du métier. Avoir quelqu’un qui a le temps et l’envie de travailler avec l’équipe est absolument critique. Un sponsor côté métier peut aider à franchir les barrières organisationnelles et humaines inhérentes à toutes les entreprises. En cas de succès, il sera également le mieux placé pour promouvoir l’agilité en interne et pour évangéliser ses collègues, qui à leur tour seront enclins à tester l’agilité dans leurs équipes.

L’équipe

J’aborde ce point en dernier, mais c’est sans doute celui qui me tient le plus à cœur. Le choix de l’équipe est le facteur de réussite. Et c’est valable pour tous les projets informatiques, agiles ou non. À l’instar d’un film, un scenario magnifique au casting désastreux ne donnera pas grand chose ; un scénario léger porté par des acteurs fabuleux lui donnera une âme. Dans notre cas, le métier va esquisser un scénario puis va l’affiner et l’adapter au fur et à mesure. Les membres de l’équipe, comme des acteurs, vont chercher à bien comprendre le scénario avant de le jouer. Ils vont être capables d’apporter leurs idées pour faire évoluer le projet dans le bon sens. Ils seront les artisans de leur propre succès.

Vous aurez donc compris l’importance du casting de l’équipe pour votre projet pilote. À ce sujet, je vous invite à lire le livre de Guillaume Bodet « Scrum en action » qui explique très bien comment repérer des profils agiles dans une équipe de projet classique.

D’après l’article de Mike Cohn : Four Attribute of the Ideal Pilot Project

Le mouvement est réellement présent depuis 2008 bien qu’il réactualise des concepts développés dans le livre Pragmatic programmer: from journeyman to master (Andy Hunt & David Thomas – 1999).

Il prône, entre autre, le fait qu’il ne suffit pas que le logiciel fonctionne, il faut également qu’il soit correctement écrit. L’accent est notamment mis sur la fiabilité et la facilité de maintenance. Est-il nécessaire de rappeler que le coût d’écriture d’un logiciel pour sa version initiale n’est qu’un petit pourcentage de son coût total ? Il est néanmoins facile de prendre ce concept à la lettre et de raffiner chaque fonction à la perfection. Le danger de la sur-conception/développement est bien présent. C’est là que l’expérience entre en jeu, comment faire un logiciel qui fonctionne, bien écrit et qui n’est pas un chef d’oeuvre à la Sagrada Família (non achevée à ce jour) : en utilisant des développeurs expérimentés, capables de prendre les bonnes décisions, bien entrainés via différentes techniques et aptes à résoudre un maximum de problématiques.

Un autre concept qui revient dans les idées de ce mouvement est la « communauté de professionnels ». Idée qui cherche, d’une part à renforcer la reconnaissance de notre profession en tant que producteurs de logiciel de qualité, et d’autre part à encourager les regroupements de développeurs s’échangeant techniques et idées. Il est bon pour votre connaissance et vos talents de professionnels de venir échanger vos techniques lors de manifestations orientées mise en pratique comme par exemple les Coding Dojo (où l’on s’exerce à l’aide de Kata) ou bien des Code Retreat, décrites en détails dans le blog des Duchess France.

L’ensemble des grands concepts sont retranscrits dans un manifeste qui a le mérite de donner un contour général aux idées prônées par le mouvement, mais dont on peut reprocher les concepts très larges, un peu fourre-tout et à la forme semblable au manifeste agile. Il y a d’ailleurs débat autour de la forme et du contenu de ce manifeste, mais sachons gratter la surface pour voir ce qu’il y a dessous…

L’accent est fortement mis sur des pratiques concrètes (techniques de développement, de tests, de design, etc) qui ne sont pas des absolus, libre à chacun d’adapter et d’explorer de nouvelles voies et de transmettre leur expérience. Le mouvement Software Craftsmanship n’est surtout pas une méthode, ce n’est pas un énième Scrum ou Kanban. Il cherche justement à faire redescendre les pieds sur terre à ceux qui appliquent l’agilité en dépit du bon sens.

La rupture qu’apporte ce mouvement consiste à remettre les pratiques de développements au cœur de la production de logiciel. Pratiques techniques qui ont remisées à l’arrière plan lors de l’application des méthodes agiles aux plus grands nombres de projets. En effet Scrum, Kanban ou Lean ne disent rien sur ces pratiques techniques, car à la fin, si vous ne savez pas produire du code de qualité, quelle que soit la longueur de vos itérations de plusieurs mois à quelques jours, vous allez livrer un logiciel qui ne fonctionne qu’en apparence ou pas correctement.

Ce mouvement promeut une culture d’amélioration et de transmission du savoir, par la pratique, adossée à un ensemble de techniques et de retours d’expériences, dans le but de fournir un logiciel de qualité.

Sens commun

Vous n’avez toujours pas compris ?
Vous n’êtes pas le seul.
La blogosphère s’est enflammée la semaine dernière sur la définition du mouvement avec des acteurs majeurs de notre industrie comme Robert C. Martin, Michael Feathers ou encore Martin Fowler qui ont pris part au débat.

Certains ont commencé à dire que les « craftsmen », dont une traduction pourrait être « artisans », pourraient avoir la tentation de se comporter en diva et de ne se concentrer que sur leur « art » qui est celui du logiciel et qu’ils perdent de vue la finalité de notre métier : produire un logiciel pour un client. D’autres ont continué en faisant dire tout et son contraire à chaque métaphore utilisée dans les billets des uns et des autres. Un échange de points de vue fort intéressant à lire à tête reposée, qui se termine par le post de Robert C. Martin Bringing Balance to the force, dans lequel il affirme que le mouvement ne surjoue pas le rôle des pratiques techniques mais cherche à contre-balancer l’équilibre mis en défaut par l’avalanche de projets Scrum se concentrant uniquement sur la méthode. Un débat polémique comme il y en a tant dans notre industrie.

Du sens commun ? Ça va sans dire, ça va mieux en le disant…

Au final, en lisant ces échanges, on peut faire ressortir du mouvement les attributs suivants :

• Qualité (conception simple, tests, TDD)
• Humilité (je me remets en question et je m’améliore en continu)
• Partage (je partage mes acquis avec mes pairs, je m’enrichis chemin faisant)
• Pragmatisme (je n’applique pas bêtement, je comprends ce que je fais et je m’adapte si nécessaire)
• Professionnalisme (je traite mon client comme un partenaire, je sais dire non quand nécessaire)
• Concret (pas de certifications fumeuses, mais un retour aux techniques fondamentales : OO, SOLID, DDD)

Craftsmanship @ Xebia

Au-delà du débat de ce qu’est (et de ce que n’est pas) le Software Craftsmanship et de son discours difficilement contestable de la recherche de l’excellence dans l’application de notre métier, quelles sont les pratiques de ses craftsmen ? Sont-elles applicables au-delà de la théorie ?

C’est la réponse à ces questions, qui nous a amené à organiser chez Xebia un atelier, pour l’instant interne, dans lequel nous nous retrouvons toutes les deux semaines pour échanger pratiques et techniques. Le fil conducteur est le développement d’une application complète que nous n’allons pas tarder à mettre en production. Il s’agit aussi, bien sûr, d’avoir une base de code suffisante pour s’exercer. Les sujets abordés à ce jour sont :

• Design Simple
• Conception Objet
• Technique de testing
• Clean Code
• Refactoring
• SOLID

Lors de ces sessions, nous nous entrainons à savoir bien faire les choses, des choses fondamentales, qui sont la base de ce que nous pratiquons tous les jours dans nos métiers. Ainsi, lorsque nous rencontrons ces cas concrets dans nos projets, nous nous sommes déjà dans bien des cas forgés une expérience dessus. Certaines de ces sessions seront transmises au-delà de l’atelier via notre réunion mensuelle d’échange de connaissances XKE (Xebia Knowledge Exchange).

Robert C. Martin, alias Uncle Bob est une personnalité reconnue du mouvement Software Craftsmanship. Pour voir ce qu’il en est vraiment rien de tel que d’apprendre par les meneurs eux-mêmes. C’est pour cette raison qu’il va venir dans les locaux de Xebia lors d’une série de formation de deux jours sur les pratiques de clean code, conception et tests. Les prochaines dates sont les 20 et 21 avril à Paris.

L’idée est bien d’apprécier la substantifique moelle de ce que prône ce courant. Et c’est bien ce qui est le plus difficile, car au-delà des débats sur les problématiques de métaphores ou de définitions bien précises, ce que l’on cherche à comprendre c’est comment embrasser cette attitude tournée vers plus de professionnalisme. Afin que nous-même, mais aussi toute notre profession soit plus pertinente demain. Que cela soit sur les méthodes mais aussi et surtout dans ces techniques et pratiques.

Crédit photo RobertBasil

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.