Cet article fait suite au précédent article sur la conférence Agile France. Je vais ici vous présenter ma 2eme journée.
C’est par un temps indigne d’un 1er juin que s’est déroulée la dernière journée de la conférence. Les différentes sessions sont toutes plus intéressantes les unes que les autres, et faire un choix s’est avéré difficile. Comme pour le précédent article, je vais détailler une session en particulier.
9h00 : Self-help for Self-organizing Teams
Keynote par Esther Derby
Typologie : modèle
Le propos d’Esther, au cours de cette keynote, était de montrer que les équipes, pour être heureuse, ont besoin d’être autogérées.
Esther commence avec un constat. Quels sont les points communs des membres des équipes heureuses ?
- Ils ont un but commun
- Leur travail est interdépendant et leur compétences sont complémentaires
- L’équipe ne doit pas être trop grande. Cinq membres est la valeur idéale
- Les membres ont une histoire commune
A partir de ce constat, Esther nous a dressé les moyens à mettre en œuvre afin qu’une équipe ait assez d’autonomie pour être heureuse, et donc productive.
10h00 : Comment écrire du code testable
par Florence Chabanois
Typologie : bonnes pratiques
Cette présentation a pour but de nous indiquer les pièges à éviter lors de développements, afin de pouvoir tester unitairement chaque composant développé. Commençons par définir la finalité du test unitaire : il s’agit de tester chaque composant développé tout en simulant au maximum les conditions qui peuvent être rencontrés sur un environnement de production. Pour pouvoir tester les composants, il faut qu’ils soient séparables. L’idée est donc d’avoir le moins de dépendance possible d’un composant vers un autre, ou plus simplement d’une classe vers une autre. Cela s’appelle, plus généralement, un couplage faible ; contrainte qui est censée être adoptée également entre les applications elles-mêmes.
Le TDD est une méthode de développement qui a pris son essor avec la montée en puissance des méthodes agiles. Il s’agit de bâtir l’application à partir des tests, qui seront donc développés avant le code métier. Florence va donc nous énumérer les cas typiques que nous pouvons rencontrer afin de suivre 2 principes fondamentaux pour avoir du code testable :
- Isolation des composants
- Simplicité du code
Constructeur cher
Il faut éviter les constructeurs qui prennent trop de paramètres. C’est difficile à tester car les dépendances sont trop nombreuses, et l’intérieur du constructeur est difficilement testable. Pour y remédier, il faut faire de l’injection de dépendance. Cela permet lors de la construction de l’objet, d’y injecter des mocks par exemple. Il faut respecter le principe de responsabilité unique : un objet doit n’être responsable uniquement que de sa logique métier.
Instanciation directe
La création d’un objet avec un “new” entraîne un couplage fort entre deux composants. Les “new” doivent être utiliser uniquement dans des factory. Encore une fois, l’injection de dépendance remédie au problème, en externalisant les dépendances.
Bloc statique
Encore une fois, le bloc statique entraîne un couplage fort entre deux composants. Il est donc très difficile de tester un bloc statique. Il est donc préférable de supprimer les blocs statiques et de les remplacer par de l’injection de dépendance. Le couplage devient ainsi faible.
Dynastie de classes
Lors d’héritage de nombreuses classes, il peut s’avérer que les classes filles soient difficiles à tester car un couplage fort est fait avec la ou les classes mères. De plus les tests ont tendances à être fait en double. Afin de changer cela, il est préférable d’utiliser la composition de classes et de limiter l’héritage au polymorphisme.
Etats globaux
Maintenir des états partagés entre instances d’une même classe est un comportement très difficile à tester. Les singletons et les méthodes statiques sont à éviter autant que possible, car cela induit des dépendances cachées. Il est préférable de les remplacer par de l’injection de dépendances.
Annuaire de service
Un peu comme à chaque problème énuméré, l’annuaire de service implique des dépendances cachées. Il faut le remplacer par de l’injection de dépendances au maximum.
Interrogation de collaborateurs
Sous ce nom abscons, se cache en fait l’utilisation de méthodes à partir d’objets passés en paramètres de méthodes. Cela implique un couplage fort avec les objets passés en paramètres, et donc le test est plus difficile à initialiser. Cette fois la solution n’est pas l’injection de dépendance ! En fait il faut utiliser le principe de connaissance minimale (dit Loi de Demeter). En clair, cela signifie remplacer les paramètres d’une méthode qui sont des objets complexes, par des types primitifs. La méthode est donc très facilement testable, le couplage devient faible et aucune dépendance n’est à initialiser.
Classe hyperactive
Ces classes sont les classes utilitaires. Ce sont les classes qu’on retrouve dans chaque projet, et qui permettent de gérer les fichiers XML, les logs, la sécurité…. Elles portent souvent un nom qui se termine par “utils” ou “helper”. Ce genre de classe est difficile à maintenir, la lisibilité y est souvent mauvaise. Afin de pourvoir tester facilement ces classes, il faut identifier les responsabilités, créer de nouvelles classes, et déplacer les méthodes de la classe fourre-tout vers ces nouvelles classes.
Méthode trop chargée
Ces méthodes sont celles que l’on voie régulièrement et qui font des longueurs qui donne le vertige. Quelques milliers de lignes est certainement trop pour une méthode. Ce genre de méthode est difficile à maintenir, très difficile à tester, et est trop sensible aux évolutions. Pour dégrossir ce genre de méthode, il faut en créer de nouvelles qui prendront en charge une partie du code de la grosse méthode. Les codes seront donc bien plus faciles à faire et à maintenir. Déléguer une partie du travail à d’autres classes est également faisable.
Mélange des objets valeurs et des objets services
Cette fois c’est clair. Il s’agit de laisser aux objets valeurs le soin d’être instancié et de conserver un état. Les objets service doivent toujours être injectés et jamais instanciés. C’est lui qui crée généralement les objets valeurs.
11h30 : Bâtir une communauté de développeurs par l’agile
par Bénédicte Taillebois, Matthieu Demay, Jean-Sébastien Hedde et Guillaume Persinette-Gautrez
Typologie : retour d’expérience
Une équipe d’Astria est venu nous présenter leur mise en place de process agiles depuis environ 2 ans. Cette présentation est faite par quatre personnes : la directrice des systèmes d’information, et trois informaticiens (je n’ai pas trouvé de meilleur terme).
La présentation a été découpée en quatre grandes phase pour décrire les avancées qui ont été apportées à tout le pôle informatique d’Astria.
Tout a commencé quand deux équipes ont découvertes qu’elles avaient eu chacune une problématique semblable, et qu’elles l’avaient résolu chacune de leur côté. De ce constat, une bibliothèque commune est née. Aujourd’hui elle existe encore, et contient 50000 lignes de codes. Chacun dans le service informatique peut y contribuer car elle est transverse. De cette bibliothèque est né un espace de discussion, où les gens concernés se réunissent une fois par semaine pour parler de besoins commun dans cette bibliothèque. De plus une règle a été acceptée par tout le monde : la règle des 2 pieds. Dans un espace commun mis en place à cette occasion, lorsque des gens se réunissent pour divers sujets, si quelqu’un ne se sent pas concerné, il peut partir à tout moment.
Cette première phase a commencé à bâtir de nouvelles méthodes de travail dans le service, mais tout n’est pas encore parfait notamment au niveau du process de livraison. Dans l’espace commun, un dashboard est créé permettant de lister les tâches communes en cours. Les livraisons pénibles sont améliorées avec la création d’un automate de livraison qui s’impose comme un standard pour toutes les applications. Une classique intégration continue est mise en place.
La troisième phase a été l’occasion de mettre en place un partage de connaissances. Des dojos hebdomadaires de développement sont mis en place. Afin de communiquer plus efficacement, les flux RSS ont remplacés les mailing list trop polluantes. Enfin, une présentation nommée “les cafés du jeudi” est créée ; il s’agit de faire la publicité sur la machine à café d’une présentation courte (moins d’un heure) qui a lieu le jeudi.
La dernière phase a été pour toutes ces personnes impliquées dans l’améliorer permanente des process et des connaissance, d’avoir un nouveau souffle. Le point transverse commençant à perdre de son intérêt, une rétrospective y est ajoutée afin de lui redonner de l’attrait. Un jeu est créé afin de noter les idées proposer par d’autres personnes.
12h30 : Tests d’acceptation de Workflows automatisés avec Concordion
par Jean-Baptiste Vilain et Gabriel Le Van
Typologie : retour d’expérience
Cette session fut l’occasion de revenir sur la mise en place de l’outil de tests Concordion par la société. Cette présentation ne comporte aucun détails technique, sa durée étant courte. Concordion est un framework de test qui se greffe au dessus de Junit, pour les tests Java.
Jean-Baptiste et Gabriel utilisent le terme “tests d’acceptation” en tant que traduction de l’anglais “acceptance tests”. Le terme “tests de validation” aurait pu fonctionner.
A partir d’une application dont la recette est difficile à faire, ils ont voulu améliorer la partie tests. Différentes frameworks ont été étudiés, et Concordion a été choisi pour la documentation qu’il apporte, et le fait qu’il s’intégrait bien dans l’environnement de développement de l’équipe. L’équipe pratiquait déjà l’XP, mais les aucun tests unitaire ou d’intégration n’est présent dans l’application.
Ce qui a été le plus difficile dans la mise en place de Concordion, a été de convaincre toutes les équipes qui sont parties prenantes. Un PoC a été réalisé, et a convaincu une bonne partie de équipes, aussi bien les équipes qui font la recette car elles ont une application a tester est bien plus fiable, que les décideurs car la mise en place des tests n’est pas un gouffre financier.
Les résultat ont bien entendu été probants. Ce PoC a entraîné une généralisation à l’ensemble des modules du projet, puis à tous les autres projets de la société.
Il y a quelques points négatifs à cette mise en place. D’abord les coûts de maintenance des tests représente un effort supplémentaire. D’autre part, il est difficile pour les personnes dans un environnement non-agile d’être impliquées dans la maintenance de ces tests (maîtrise d’ouvrage par exemple). Les points positifs sont plus nombreux que les négatifs. Concordion fournit une documentation à chaud. La collaboration avec l’équipe de recette a été grandement améliorée. Un domain specific language est en train d’émerger.
14h30 : L’agilité comme facteur de réussite d’un projet au forfait
par Guillaume Leborgne
Typologie : retour d’expérience
Guillaume nous présente comment l’agilité a pu faire réussir un projet au forfait. Ce projet consistait à migrer une application existante vers des nouvelles technologies en y intégrant quelques nouvelles fonctionnalité.
Scrum a été mis en place, avec des sprints de deux semaines. Un espace collaboratif a été mis en place entre le client et le prestataire, de type SharePoint. Une intégration continue a été mise en place.
Quelques difficultés ont été rencontrées. Le client a eu du mal à s’adapter à une approche incrémentale. Lors des premières versions livrées, il était difficile pour le client de comprendre les parties à tester et les parties qui n’étaient volontairement pas encore développées. Il a fallu trouver le niveau de souplesse adéquat pour respecter les demandes du client, et les contraintes d’un forfait.
De nombreux points positifs sont au bilan de ce projet. Le client a été très fortement impliqué. Le prestataire a, grâce à l’espace collaboratif, été très transparent sur l’état d’avancement du projet. L’application a été testable rapidement, et a pu être testé progressivement, ce qui a allégé la recette finale.
Au final, l’agilité a permis de répondre dans les délais à la migration de cette application. La version finale a été livrée avec seulement deux semaines de retard, sur un projet de plus de 6 mois. Le client est entièrement satisfait, à la fois par le logiciel, et par la méthode de travail apporté par l’agilité. En production, l’application a rencontré très peu d’anomalies.
15h00 : Le modèle d’acquisition des compétences de Dreyfus
par Emmanuel Hugonnet
Typologie : modèle
Emmanuel nous présente, au cours de cette présentation, le modèle de Dreyfus. Ce modèle catégorise le niveau de compétence qu’un individu a sur un sujet. Les niveau sont les suivants :
- Le novice
- Le débutant avancé
- Le compétent
- L’efficace
- L’expert
Toute la présentation s’est axée sur la description de chacun des niveau et des interactions possibles entre personnes de niveaux différents. Emmanuel nous donne également quelques conseils pour que nous tendions vers l’expertise, car ce type de compétence est rare et possède pleins d’avantages, comme le fait d’être non délocalisable.
16h30 : Comment être agile dans sa communication
par Eric Bezançon
Typologie : bonnes pratiques
Cette courte présentation avait pour but de nous donner des conseils pour communiquer au mieux en faisant de belles présentations. Eric est consultant Agile, Scrum et expert en communication.
Communiquer signifie délivrer un message. Ce qui est difficile lorsque l’on sait quelque chose, est de communiquer ce savoir. Le secret est donc de se mettre au niveau des gens qui n’ont pas ce savoir afin d’adapter le message qu’on leur transmet.
Une bonne communication se résume en 6 grands principes que je ne vais pas détailler :
- simplicité
- inattendu
- concret
- crédibilité
- émotion
- histoire
Pour faire une bonne présentation (powerpoint par exemple), il faut être créatif. Afin de la préparer, il faut éteindre son ordinateur, et faire un story board, par exemple avec des post-it. Lors de la construction de la présentation, il faut utiliser des visuels forts, tels que des images, des photos, et peu de textes. Il ne faut pas répéter ce qui est dit à l’oral.
17h00 : Le secret de la Rétrospective
par Jacques Couvreur et François Bachmann
Typologie : bonnes pratiques
Cette présentation était entièrement axé sur une mise en pratique. La salle a été séparé en 2 groupes, et à l’aide d’un jeu de carte, chacun a endossé un rôle sur un projet fictif. Le projet est la mise en place de Noël. Les rôles sont nombreux, tels que le père noël qui n’a qu’une envie, faire plaisir aux enfants. Les enfants n’hésitent pas à demander tout et n’importe quoi comme cadeau de noël. Les rennes doivent s’assurer que les cadeaux arrivent à destination et dans les temps. Les nains ont pour tâche la fabrication des cadeaux. Les elfes doivent vérifier la conformité des cadeaux par rapport à ce que les enfant ont demandés, etc.
A travers ces différents rôles, facilement assimilables à ceux que l’on peut avoir dans un projet informatique, Jacques et François nous ont distillé les meilleures pratiques sur la rétrospective. Un de leur conseil par exemple, est de mettre en place une petite liste d’actions a effectué à la fin de la rétrospective. Lors de la prochaine rétrospective, il faut voir quel est l’état de ces tâches. Si rien n’a été fait, alors il ne faut en ajouter de nouvelles.
Fin de la conférence
Conférence très variée, cadre agréable, temps radieux, cette conférence m’a permis de connaître des domaines auxquels je ne me serai pas intéressé si je n’étais pas venu. L’agilité reste le fil conducteur de chaque présentation, et heureusement qu’il ne s’agit pas que de présentations de XP ou Scrum !
Je retiendrai sûrement bon nombres d’idées à appliquer au quotidien chez mon client. Le plus dur n’est pas de vouloir le faire, ni de se lancer, mais de convaincre une DSI qui n’est pas habituée aux méthodes agiles, et qui ne souhaite pas vraiment y adhérer. Voilà ce que je cherchais également, des conseils chez des anciens de l’agilité, qui ont réussi à imposer dans leur projet les méthodes agiles. Nous verrons dans quelques mois si cela a porté ses fruits pour moi.
Bibliographie
Pragmatic Programmer : http://www.pragprog.com/
Concordion : http://www.concordion.org/
Génération de personnages (pour les présentations par exemple) : http://www.weeworld.com/
Ancienne présentation sur le modèle de Dreyfus : http://www.slideshare.net/ehsavoie/le-modle-dacquisition-de-comptences-de-dreyfus
Présentation de Florence Chabanois – Comment écrire du code testable : http://www.slideshare.net/foucha/comment-crire-du-code-testable?from=ss_embed
