SOCIALHORTIS

Voici (enfin) notre feedback sur les présentations qui nous ont le plus marqués lors de cet événement qui a eu lieu fin mai à Paris.

Blanche Neige et les Sept Nains
Portia Tung et Pascal van Cauwenberghe

Le “Conte de Fées Agile” de Blanche Neige et les Sept Nain est un jeu qui amène une réflexion à plusieurs niveaux. A travers l’histoire de Blanche-Neige, on nous présente une petite palette de personnages stéréotypés (Blanche-Neige, la Méchante Reine, Joyeux, Grincheux, etc.), avec leurs points forts et leurs faiblesses. Ensuite l’exercice se décline en deux parties.

• D’abord, par petits groupes, chacun du groupe doit nommer quelqu’un de sa connaissance qui ressemble à un des personnages du jeu, et expliquer en quoi ils véhiculent ce personnage (points forts et faible). Puis on réfléchit à ce que ce jugement nous enseigne sur nous-même, et quelles actions est-ce qu’on peut prendre pour mieux communiquer avec la personne en question.
• Dans la deuxième partie, le groupe doit imaginer un produit dont on va monter une équipe pour le développer. On tire les premiers membres de cette équipe fictive parmi les cartes des personnages du jeu ; ensuite on peut choisir 2 autre personnages pour compléter l’équipe. On finit par présenter son projet à la salle et expliquer son choix d’équipe.

Ce jeu est, à part égal, un outil de réflexion sur soi-même, sur les autres et sur ses rélations avec les autres. Aussi un outil dans le composition d’une équipe. Il fait réfléchir sur les points forts et faibles de chacun, et permet de voir que même les points faibles ont un intérêt : on peut s’en servir pour mieux comprendre ses propres faiblesses, et pour constituer une équipe de choc en trouvant les compléments des faiblesses de chacun. Ainsi par exemple a-t-on appris que chacun avait quelque chose à contribuer puisque toutes les équipes projet qui ne l’avait pas déjà tirée, ont ajouté à leurs équipes la Méchante Reine (manipulatrice, amoral et à première vue la dernière personne avec qui on aurait envie de travailler), pour sa capacité à toujours arriver à ses fins.

On peut télécharger le jeu depuis le site de Portia : http://www.agilefairytales.com/games.html

D’autres outils pour réfléchir à ces questions : MBTI et Belbin Team Rôles (je ne connais pas le second, mais le premier, basé sur les théories de CG Jung, m’intéresse depuis fort longtemps).

Christopher Alexander’s Theory of Centers
Régis Medina

Cette présentation donnait une introduction aux travaux de Christopher Alexander, architecte (du bâtiment), et tout particulièrement de sa théorie des centres.

Pour Alexander, l’activité de conception est une activité d’élimination de défauts / d’erreurs. Non pas un processus de recherche des éléments nécessaires (“Voici le problème -> voilà la solution”). La grande difficulté est qu’il y a une forte interdépendance entre les différents éléments : c’est difficile de résoudre un problème sans en créer d’autres. Dans l’espace des contraintes, il y a des nœuds : certaines contraintes sont interdépendantes, d’autres non (ou moins). Pour chacun de ces nœuds, ou de ces grappes, de problèmes, il y a généralement une solution (ou un modèle de solution) déjà trouvée par l’humanité : c’est un pattern. Cette idée développée dans l’architecture par Alexander a été reprise par Kent Beck dans l’informatique avec les design patterns. La notion d’Alexander était que les gens développent ou adaptent leurs propres patterns. Toutefois en essayant de mettre en pratique cette notion, il s’est rendu compte que cela ne marchait pas parce que les gens n’avaient souvent pas les compétences (le feeling, l’expérience) nécessaire pour choisir, créer ou appliquer des patterns de manière appropriée. Alexander s’est alors mis à travailler sur le processus.

Principes :

• “organic order” tout doit être bien pensé à toutes les échelles
• “Participation” : pour que les gens soient bien dans l’environnement bâti, il faut leur expliquer l’architecture, les impliquer.
• “Piecemeal Growth” : la conception du bâtiment doit évoluer dans le temps.
• “Patterns” cf ci-dessus
• “Diagnosis” éliminer ce qui ne marche pas
• “Coordination”

Ce deuxième développement dans ses idées sur l’achitecture a également été repris en informatique : par l’eXtreme Programming.

Propriétés des centres réussis : 15 propriétés identifiées lors d’une gigantesque étude empirique, entre autres :

• levels of scale (des détails à différentes échelles)
• strong centers (des centres forts)
• boundaries (bordures)
• echoes (des motifs qui se répètent, éventuellement en variant)
• …

Design vs processus : l’important n’est pas comment on conçoit l’architecture, mais le processus qui nous permet de la perfectionner de manière iterative. Elaguer les centres faibles, renforcer les centres faibles, ou renforcer les centres latents -> des centres forts. Comment évaluer la qualité des centres ? “La qualité qui n’a pas de nom” : notion décrite dans le livre “Zen and the Art of Motorcycle Maintenance”, et développée par Alexander, la qualité est dans la perception d’un objet par un observateur. Faire évaluer la qualité oblige les gens à développer leur capacité à la percevoir.

Pour le développement logiciel, les centres sont les principaux éléments, par exemple, suivant les cas : struts-config.xml ; ArrayList ; mapping.findForward() ; etc. Il faut identifier les centres qui sont bien installés, ceux qui luttent entre eux, élaguer ou renforcer ces dernières, ou faire sortir les centres latents : c’est l’activité de refactoring.

Finalité de la présentation : le refactoring vu sous l’angle de l’évaluation et l’évolution des centres.

• Boundaries se traduit par l’encapsulation.
• Levels of scale se traduit par le découpage hiérarchique des éléments.
• Gradients se traduit par exemple par la graduation des paramètres d’une méthode : les plus importants au début, les moins importants après.
• Echoes se traduit par ce que le même concept se retrouve à plusieurs endroits.
  Le “bruit” qu’on retrouve dans du code non refactoré est dû au fait qu’il y a plein de centres latents et des centres faibles en conflit ; il n’est pas possible d’avoir une lecture claire et rapide, l’esprit du code est brouillé.

Pour finir, Régis nous a donné une masterclass de refactoring à la lumière de la théorie des centres, pour illustrer son application au développement logiciel.

Ce que j’ai retenu : à part la théorie des centres, dont je compte acquérir une connaissance plus approfondie, il faut également que j’apprenne mieux les fonctionnalités de refactoring d’Eclipse et leurs raccourcis claviers !

Soigner sa schizophrénie projet MOA / MOE : voyage autour des exigences fonctionnelles exécutables

Emmanuel Hugonnet,
Rémy Sanlaville,
Hervé Lourdin

La MOA représente le métier, les idées
La MOE représente la technique, l’architecture

Ce modèle est très cloisonné et aboutit à ce que seulement 20% des fonctionnalités développées sont réellement utilisées. Cela montre un manque de communication.

Certaines pratiques permettent d’estomper ce clivage MOA/MOE et d’instaurer une communication claire entre les 2 parties. C’est le cas de l’ « Acceptance Test Driven Development » et du « Behaviour Driven Development »
Elles suivent un processus itératif de ce genre:

• 1 – Discussions MOA/MOE pour faire émerger un langage commun. Par exemple en formalisant le besoin par des phases-types « Given …, When … Then … »
• 2 – Traduction de ces phrases en tests exécutables (avec FitNesse par ex)
• 3 – Développement: le but est de faire passer les tests précédents. Un des présentateurs de la session fait remarquer que cette démarche possède un caractère scientifique, dans le sens où l’écriture du code s’apparente à l’élaboration d’une théorie, et le passage des tests sur ce code prend le rôle de l’expérience, destinée à confirmer ou infirmer la théorie.
• 4 – Exploration: les tests d’acceptance précédents servent à décrire la fonctionnalité. Ils ne sont pas suffisants pour la valider complètement. Ici apparaît le rôle du testeur humain dont l’imagination (non automatisable!) permet de « secouer » l’application pour en faire ressortir les défauts.
• Ensuite, on repart à l’étape 1.

Les outils:

• Bruts: Jbehave, Rspec, Easyb
• Plus faciles d’accès à la MOE: Wiki (FitNesse, GreenPepper), HTML (Concordion, RobotFramework)
• Nouveaux: Jbehave2 (texte libre), Twist (environnement intégré)

Perspectives: Même si c’est encore au stade expérimental , on assiste à un rapprochement des outils de dev et de description des specs exécutables et par la même au rapprochement MOA/MOE.

Les outils ne sont apparemment pas centraux dans le dialogue MOA/MOE. Toutefois, je remarque que le formalisme qu’il apportent aident à une meilleure compréhension entre les 2 mondes. Ce sont les ambiguïtés (parfois volontaires) qui éloignent.
Cette présentation me semble appropriée pour des développeurs mais aussi pour les AMOA (assistants à la Maitrise d’OuvrAge): les outils de description de specs exécutables n’étant pas encore suffisamment accessible a la MOA, le rôle d’intermédiaire de l’AMOA et sa connaissance technique devrait lui permettre d’Assister la MOA dans ce travail.

XP 2.0
Régis Médina
Antoine Contal

Le Lean est présenté ici comme un bond en avant dans l’agilité quand on pratique déja l’eXtreme Programming avec succès. Plus clairement et en utilisant les termes de Régis Médina: « le Lean est un moyen de passer d’une équipe qui déchire à une équipe qui déchire… grave! »
D’abord, Régis et Antoine abordent quelques problemes rencontrés dans la vie d’une équipe de dev en les rattachant à des mots/concepts du vocabulaire Lean pour montrer qu’ils sont connus et adressés par la méthodes:


• surcharge de travail → MURI
• variation des besoins → MURA
• gaspillage → MUDA (souvent conséquence de MURI et MURA)

les principes du Lean sont (dans l’ordre):


• augmenter les ventes, en satisfaisant le client
• réduire les couts, en éliminant les gaspillages
• développer les collaborateurs

Pratique essentielle du Lean, le Kaizen (amélioration continue) est un processus rigoureux de résolution de probleme qui s’attache à les faire disparaître définitivement. Il se décompose en 4 phases:

• 1 – voir sa performance (dans le référentiel du client) → définition d’un moyen de mesure (ex: vélocité, pourcentage de nouvelles fonctionnalités / temps, …)
• 2 – voir les problèmes: comparer la performance attendue avec la performance réelle les rend plus visibles. En lean, les problèmes sont « appréciés » car ils sont source d’amélioration. Il semblerait que quand ils deviennent rares et difficiles à débusquer, on les regrette ?
• 3 – résoudre lesdits problèmes… mais pas n’importe comment:
  
  • simples: just do it! Souvent on entend « je sais quelle est la solution efficace et définitve pour ce problème mais je n’ai pas le temps de la mettre en place maintenant alors je fais une grosse verrue moche ». Dans beaucoup de cas, la solution efficace est rapide à mettre en place. S’accorder une timebox de 10 min dans ces cas s’avere tres bénéfique.

  

  • moyens: mettre en place des « contre-mesure »: solutions temporaires qui ont l’avantage de réduire rapidement les effets du problème.

  

  • Problèmes de fond: atelier Kaizen
• 4 – en tirer les leçons: les nouveaux standards sont établis. Ils pourront encore être améliorés par l’équipe.

Bonne présentation du Lean sous forme de dialogue, ce qui rend l’explication claire et la lie à un contexte connu.
Le “just-do-it” est à lui seul une source d’amélioration et de motivation, il est de plus très facile à mettre en place. La prochaine fois que vous dites “je n’ai pas le temps”, réfléchissez-y une 2eme fois en cherchant si cette réponse toute faite n’est pas juste un prétexte… si c’est le cas, usez de votre courage et accordez vous ce fameux temps pour venir à bout de ce problème.
Régis nous a également faire partager une vision du Lean qui va jusque dans le code lui-même. Ainsi, ce les commentaires inutiles, le code dupliqué, le code mort, … sont autant de gaspillages qui ralentir la lecture sereine du code.

Parabole du trafic urbain
François Bachmann

Présenté par un de nos délégués suisses: François Bachmann (sprint-it.ch)
le but ici est d’utiliser un langage « universel », le trafic automobile, pour communiquer des concepts agiles à des personnes qui sont hors du monde du développement mais qui peuvent fortement l’influencer, les décideurs notamment, mais aussi la MOA.
Par plusieurs (beaucoup) exemples illustrés de situations que chaque conducteur a déjà rencontré sur la route, François nous montre qu’ils sont autant de métaphores des idées ou pratiques issues des méthodes agiles. Les points communs entre le trafic et le développement abondent: ils sont constitués d’acteur multiples et variés qui interagissent, ils nécessitent une planification plus ou moins poussée, des événement imprévus surviennent, les « ressources » sont limitées, elles sont souvent « communes » à plusieurs acteurs
En voici 2 exemples qui m’ont particulièrement plu car on peut y lire les valeurs agiles de communication, feedback, courage, simplicité:


• la gestion des carrefours: la méthode traditionnelle gérer une intersection de routes et d’imposer une régulation extérieure par des feux, ce qui conduit à des périodes sans circulation, blocages du trafic et à une déresponsabilisation des usagers, parfois génératrice d’accidents. Le pendant « agile » est le rond-point: il permet au trafic de s’autoréguler, rend les conducteurs attentifs, autorise toutes les directions, et fluidifie les déplacements.



• L’événement inattendu: par exemple un accident sur l’autoroute: il concerne seulement quelques acteurs mais a des conséquences plus ou mois directes sur tout le trafic: les autres voiture ralentissent pour éviter les débris ou pour regarder la scène, ce qui cause souvent un bouchon et nécessite de canaliser les véhicules vers un autre itinéraire. Dans ce cadre, une séries de mesures préventives (bande d’arret d’urgence, limites de vitesse, gestion du débit par des prévisions et des itinéraires bis, téléphones de secours, …) et correctives (messages d’avertissements quelques kms avant le bouchon, véhicules de secours facilement identifiables, …). De même, un imprévu sur une fonctionnalité logicielle peut avoir des effets sur d’autres personnes que les développeurs qui en sont en charge. Cela peut déboucher sur des retards de livraison, une ré-architecture partielle, …

Deux choses très intéressantes à mon sens dans cette session: La forme (l’analogie), le fait d’utiliser un langage commun pour faire passer des idées entre personnes qui n’ont pas les mêmes connaissance mais qui doivent construire quelque chose ensemble. La métaphore est d’ailleurs elle-meme une pratique XP, parfois mise de coté mais qui mériterait d’être approfondie et travaillée. 2ème intéret fort: le fond. l’analogie du trafic est remarquable et je vous encourage à la tester, vous verrez la route différemment.

Conclusion
Un très bon cru pour cette conférence qui atteint aujourd’hui une taille critique et lui permet d’être un véritable acteur influent de l’Agilité en francophonie.
Bravo aux organisateurs.
Nous vous souhaitons la même réussite pour l’année prochaine.

Andrew Spencer
Sylvain Labussiere