Intro

SCRUM, Extreme Programming (XP), Lean-management, le développement agile, c’est tendance !

Objectifs : améliorer la réactivité, la qualité et le coût du logiciel avec en ligne de mire la sacro-sainte satisfaction client.

J’ai participé, pendant deux ans, à un projet réalisé « from scratch » en suivant une méthodologie agile : l’Extreme programming. En tant que développeur (sur les deux ans), et « coach XP » (sur les six derniers mois).  L’objectif du projet était le développement d’une application de trading « in-house » dans une banque d’investissement, la taille de l’équipe a varié au cours de ces deux ans de 3 à 7 (manager compris).

Ce post a pour but d’expliquer les pour et les contre de cette méthode tel que je l’ai vécu.

L’extreme programming

Sans chercher à être exhaustif (wikpedia est ton ami), voici les grands principes XP :

• Pair-programming : on code à deux devant un PC, le codeur et le reviewer. les rôles s’inversant régulièrement. On change de binôme à chaque tâche.
• TDD (Test driven development) : chaque méthode, chaque portion de code est systématiquement testée avant d’être codée.
• KISS (Keep It Simple, Stupid) : On cherche toujours la solution la plus simple sans anticiper les besoins futures (pêché mignon du développeur ?).
• Refactoring : On cherche en permanence à avoir le code le plus propre possible
• Itérations courtes : le cycle développement-release est très court (1 semaine à 1 mois)

Les plus

• Un code clean : Non seulement l’XP via ses principes favorise une plus grande qualité de code, mais j’irai plus loin : il l’impose ! En effet, le TDD dans du code spaghettis, dupliqué, du code mort…c’est sinon impossible, franchement pénible. Idem pour le refactoring, très cher s’il n’est pas fait suffisamment tôt.
• Agilité : Je vous entends « Il est malin le type, c’est l’objectif ! ». Ok, mais c’est un objectif atteint. Le client peut changer d’avis et ses priorités comme de chemise (et il ne s’en prive pas).
• L’équipe te rend plus fort : Grace au pair-programming, les développeurs montent rapidement en compétence. Pour le développeur, c’est l’opportunité de se former grâce au reste de l’équipe. Se former sur l’application bien sur, mais aussi sur tout ce qu’on peut apprendre à observer un autre développeur à l’oeuvre.
• Interchangeabilité : XP refuse la spécialisation, chaque développeur doit maîtriser l’ensemble de l’application. C’est possible en associant sur chaque développement un « sachant » et un « ignorant » sur la partie concernée. C’est clairement un luxe pour le manager étant donné le turnover dans la plupart des projets informatiques. Les mauvaises langues parleront de développeur « jetable », mais pour le projet, c’est un plus.

Les moins

• Dites au revoir à votre « Touch » : Si vous aimez utiliser vos raccourcis « custom », vos conventions de nommage, vos patterns, vos lib. Bref ! VOTRE façon de coder : Oubliez ! vous allez coder la moitié du temps sur un autre PC, et quelqu’un d’autre codera sur le votre. L’uniformisation des l’environnement, des outils et des pratiques est par conséquent obligatoire. C’est positif pour le projet, mais l’effort d’adaptation est réel.
• Explications, négociations, compromis : Développer à deux, ce n’est pas naturel. Il faut en permanence argumenter, expliquer son cheminement de pensée. Quand au reviewer, il doit rester concentrer sans le clavier, challenger chaque décision,  être force de proposition et chasser chaque bug ou coquille, il doit enfin être patient s’il maitrise mieux le sujet sans chercher à « attraper » le clavier. Il faut aussi veiller à garder un équilibre, le plus timide ou le plus junior ne devant pas se faire « manger ». Bref, c’est formateur, le code écrit est meilleur, mais je suis convaincu que c’est plus exigent que de coder seul.
• Le TDD, ce n’est pas sexy : Je suis fermement convaincu de l’intérêt du TDD (limitation des bugs et des régressions, refactoring sure, spécification, code découplé), mais il faut avouer qu’écrire des centaines de tests et avoir la (fausse ?) impression d’aller deux fois moins vite, c’est parfois rébarbatif.
• Pas de petit chef : Le pair-programming, l’absence de spécialisation et la volonté en XP d’aller vers l’essentiel (le code) limite quelque part les responsabilités du développeur. Dans une équipe classique, chaque développeur deviendra probablement référent sur certains domaines, participera à des réunions, et prendra en charge certaines responsabilités.  En XP, le manager manage, les codeurs codent (PS : si c’est tout ce que vous aimez, vous pouvez passer cela dans la rubrique plus), et nul n’est indispensable.

Avant de conclure, quelques remarques inclassables, ni en plus, ni en moins

L’extreme programming, à prendre ou a laisser.

Je ne vois pas les différentes pratiques de l’XP comme une boîte à outil où l’on prend et on jette en fonction des envies. Les différentes pratiques se complètent et se renforcent mutuellement.

• Pour livrer très fréquemment, il faut pouvoir valider une version très rapidement, d’où le TDD. (Si vous voulez tester l’application de fond en comble tous les 15 jours à la main, ce sera sans moi).
• Prendre systématiquement la solution la plus simple en négligeant le refactoring, c’est la porte ouverte au code spaggeti et autres rustines.
• Faire du refactoring fréquemment sans couverture de tests unitaires, c’est l’assurance de régressions.
• Refactorer, c’est bien plus sûr avec une deuxième paire d’yeux.

Bien sur, ça n’est pas vrai pour tout,  le TDD n’a pas attendu l’XP pour exister.

N’est pas XP qui veut

Tout projet n’est pas adapté à l’XP. Il faut un client accessible et prêt à s’investir et des développeurs ouverts aux pratiques XP. Il faut enfin que le manager soit convaincu par la méthode et à l’écoute des développeurs (accepter les coûts donnés par des développeurs et les dépassements inévitables par exemple).

L’environnement de développement est également primordial. Framework de tests unitaires, de mocking, outils de refactoring, d’analyse statique de code, de couverture de tests, usine de build…Tous ces outils « nice-to-have » dans un autre projet deviennent plus ou moins indispensables en XP. En conséquence,  un projet C++ ou dans un langage web est sans doute moins adapté à l’XP qu’un projet Java ou .NET.

Conclusion

Au final, même si j’ai la critique un petit peu facile par nature, je me range plutôt du côté des « pro-XP / pro-agiles » .Le projet auquel j’ai participé est à mon avis un succès, mais il est important de noter qu’il correspond en tous points au « contexte idéal » décrit ci-dessus.

Quant aux objectifs mentionnés au début du post (améliorer la réactivité, la qualité et le coût du logiciel), les deux premiers sont clairement atteints. Pour le troisième,  c’est la question à 1 Milliard.

Ce qui est sûr, c’est que l’on est très loin d’un coût multiplié par quatre. Certes on code deux fois plus (TDD), et à un instant donné, la moitié de l’équipe ne code pas (elle ne dort pas non plus). Mais cela est compensé par des bugs à fixer en moins, un code de meilleur qualité, une montée en compétence plus rapide et un scope correspondant exactement au besoin client. Est-ce que c’est « surcompensé » ou « sous-compensé », là est le vrai débat. Mon intuition c’est que le gain est négatif dans un premier temps (un an, peut-être deux) puis positif par la suite.

Voilà pour ma vision de l’Extreme programming, à prendre pour ce que c’est, un avis basé sur une expérience mais certainement pas une vérité.

The post Extreme programming : retour d’expérience first appeared on In Fine - Le Blog.

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

The post Conférence Agile France 2010 : Jour 2 first appeared on In Fine - Le Blog.

La conférence Agile France de l’année 2010 (appelée les années précédentes XP Days France) s’est déroulée le 31 mai et le 1er juin. Comme l’année dernière, elle avait lieu dans le cadre champêtre du Bois de Vincennes, précisément dans le Chalet de la Porte Jaune. D’ailleurs, il était tout à fait possible de faire, entre 2 sessions, un peu de barque sur le Lac des Minimes… mais revenons au sujet.

Sur deux journées, sont donc attendus 300 visiteurs pour 73 sessions tournées autour de l’agilité en général. Cette conférence francophone attire des gens de toute la France et de tout horizon. Je vais vous présenter sur deux articles les sessions auxquelles j’ai assistées. Cette article porte sur la première journée.

Je vais vous détailler la keynote plus particulièrement. Les autres sessions seront uniquement résumées. Le but de cet article n’est pas de faire un compte-rendu exhaustif, mais plutôt de vous donner un aperçu de tous les sujets abordés dans cette conférence.

J’ai essayé de classer les sessions en 3 catégories :

• Modèle : Il s’agit de la présentation d’un concept généralement issu de l’observation. Les modèles ont pour vocation de s’appliquer à l’ensemble de la population. La mise en pratique d’un modèle n’est pas toujours évidente à imaginer.
• Bonnes pratiques : Partage de connaissances généralement admises comme étant bonnes. L’application des bonnes pratiques est immédiates si on connait le sujet traité.
• Retour d’expérience : Des personnes nous font part de la manière dont ils ont mis en pratique une méthode, une technologie.

9h00 : Programmation Neuro Linguistique (PNL) et Agile : les yeux, les oreilles et les sensations

Keynote de Bruno Sbille

Typologie : modèle

Après une petite présentation générale de la part de l’organisation, une keynote sur la PNL (ne pas confondre avec le PNL en finance) est présenté par Bruno Sbille. Dans la grande salle de 300 personnes, Bruno, à travers son expérience sur l’agilité et de ScrumMaster, va nous présenter cette branche de la psychologie qu’est la PNL, et va ensuite nous parlé de VAK.

PNL : Programmation Neuro Linguistique

La PNL est une branche récente de la psychologie. Elle a été inventée dans les années 70. Les principes de la PNL sont les suivants :

• Observation des compétences des personnes de talents
• Déduire des structures communes à partir de ces observations
• Construire des modèles à partir des structures communes
• Utiliser les modèles

Bruno donne plusieurs exemples d’applications de la PNL, notamment Walt Disney qui lors des réunions qu’il organisait, n’hésitait pas à inviter tous les employés (et pas seulement les gens concernés), afin d’avoir le maximum de compétences à disposition.

VAK : Visuel, Auditif, Kinesthesique

Chaque personne utilise un canal de communication principal pour interagir avec d’autres personnes. Ces canaux sont au nombre de cinq, et font référence aux cinq sens :

• V : Visuel
• A : Auditif
• K : Kinesthésique
• O : Odorat
• G : Goût

La PNL regroupe les trois derniers sens au sein d’un unique canal : le canal kinesthésique.

Pour connaître quel est son canal prioritaire, Bruno demande à l’auditoire de repenser à un bon moment du passé, par un exemple un anniversaire où l’on s’est bien amusé. Lorsque chacun d’entre nous a fini de se remémorer ce bon moment, Bruno nous demande l’idée qui est venue en premier. S’il s’agit plutôt du discours qui a été fait lors de cet anniversaire, alors on est plutôt auditif. Si c’est le cadeau reçu lors de l’anniversaire qui ressort dans les pensées, alors on est plutôt visuel. Si on se souvient plutôt de l’ambiance générale, alors on est plutôt kinesthésique.

Ensuite, Bruno nous donne des indices pour repérer quel est le canal de communication prioritaire de nos interlocuteurs, notamment pour les membres de notre équipe :

• Une personne auditive parle beaucoup pour exprimer ses idées, même si on les a compris. Elle utilise des expressions du type : “On s’était dit quoi à la dernière réunion déjà ??”. Ce canal est très utilisé d’après Bruno
• Une personne kinesthésique n’entrera pas forcément en contact avec les gens, car c’est un sujet tabou dans les entreprises. En revanche, elle sera attachée aux valeurs que véhicule la société dans laquelle elle travaille. Elle utilise des expressions du type : ” Tu la sens comment cette réunion ?”. Pour elle, c’est un problème si on prend sa place sans lui demander.
• Une personne visuelle a besoin de dessins pour comprendre les choses. C’est un canal qui véhicule des idées puissantes. Les problèmes sont plus facilement identifiables s’ils sont montrés via un dessin.

Toute cette théorie est utile et utilisable dans le contexte professionnel afin d’identifier son propre canal, ainsi que celui de chacun des membres de l’équipe.

Les applications quotidiennes sont très concrètes :

• Se synchroniser sur le canal de communication de son interlocuteur (exemple : le lors du daily scrum qui fait intervenir les 3 canaux)
• Donner de la reconnaissance à quelqu’un en utilisant le bon canal
• l’IPhone est un succès car son interface utilise les 3 canaux de communication

Triangle dramatique

Triangle Dramatique de Karpman

Le triangle dramatique de Karpman représente les rôles que chacun d’entre nous sommes amenés à jouer dans notre milieu professionnel. Ces rôles se retrouvent chez les gens que l’on côtoie tous les jours et se manifestent de différentes manières :

• Le persécuteur est méchant. Il critique, mais cela peut être sournois, et peut affecter une personne sans qu’elle s’en rende compte
• La victime trouve la vie trop dure. Elle est poursuivie par des déboires. Elle a tendance à se dédouaner de ses fautes. C’est une personne difficile à supporter et qui peut apporter de l’énervement dans l’équipe.
• Le sauveur semble avoir le beau rôle. Il est là pour sauver les mauvaises situations. Il va trouver des problèmes à régler même si on ne lui a rien demandé. Il est intrusif.

Chaque personne y trouve son compte en jouant un de ces rôles. Bruno nous expose donc quels sont les besoins et les bénéfices à jouer ces rôles :

• Le persécuteur a besoin d’un prétexte et d’une victime. Il obtient en bénéfice un sentiment de toute puissance et cela lui permet d’évacuer sa frustration
• La victime a besoin d’un persécuteur où elle crée un contexte défavorable. Elle obtient en bénéfice de la pitié et de la sympathie.
• Le sauveur a besoin d’une victime. Il obtient en bénéfice de la reconnaissance, et cela lui permet de ne pas s’occuper de ses problèmes.

Les effets pour le travail en équipe sont évidemment pervers. Il faut donc que personne ne joue ces rôles, d’après Bruno. Différents moyens sont possible pour que chacun puisse sortir de ces rôles.

Conclusion

Cette keynote a été l’occasion pour moi d’aborder un pan complet de la psychologie que je ne connaissais pas. Malgré tout, cela apporte une dimension sur la communication au sein de l’équipe qu’il faut essayer de s’approprier de manière à mieux faire passer le message que l’on souhaite faire passer.

La présentation peut être revue sur slideshare : http://www.slideshare.net/brunosbille/prs-agile-france2010bsbv3-4379231

Une ancienne présentation de Bruno sur le sujet : http://www.slideshare.net/brunosbille/sug-pres-bsb-soiree-anniversaire-v3-final-3628800

10h00 : La revue de code: agile, lean et indispensable !

par Lucian Precup

Typologie : bonnes pratiques

A travers sa présentation, Lucian à pour objectif de nous persuader que la revue de code est une étape clé dans la phase de développement, et que cette revue n’est pas qu’une étape rébarbative et manuelle puisqu’elle peut se faire assister par des outils.

Commençons par définir ce qu’est la revue de code : il s’agit d’une inspection systématique du code source par une autre personne que celle qui l’a écrit. Cette pratique a été démocratisée avec les méthodes agiles avec le pair programming notamment. La revue de code a différents buts pour l’équipe. Elle permet de trouver les bugs fait par l’auteur, et améliore donc la qualité du logiciel. De plus, cela améliore les compétences de développement de chacun, en apprenant les bonnes pratiques et en les diffusant. Les revue de code peuvent être formelles ou non, et peuvent se faire pré ou post-commit.

Voici une petite liste non exhaustive des nombreux avantages de la revue de code :

• Détecter les bugs
• Promouvoir l’apprentissage
• Former les nouveaux membres de l’équipe
• Promouvoir le partage
• Rendre le code plus maintenable en y ajoutant plus de documentation par exemple
• Trouver de meilleures solutions techniques

La revue de code, comme toute pratique un peu moderne, a ses détracteurs. Voici quelques idées reçues que Lucian nous présente :

• La revue de code augmente la durée des développement : Oui la phase de développement est plus longue à cause de la revue de code, et des éventuels bugs à corriger que la revue de code à fait émerger. Mais la phase de recette est bien moins longue car l’application gagne en fiabilité. Cela entraîne moins de bug en production. Au final, on passe moins de temps en recette et l’application gagne en qualité. Des études citées par Lucian indiquent que 60 à 70% des bugs sont trouvés lors de la revue de code.
• Peut-on automatiser la revue ? Une partie peut être faite par des outils. Ces outils peuvent indiquer des patterns à éviter, et sortir des métriques sur le code. Mais rien ne remplace le partage des connaissance que la revue apporte.
• Il faut donc faire du pair programming ? C’est très efficace, mais bien plus coûteux qu’une revue classique.

11h30 : Comment j’ai remplacé 30% de mes développeurs en adoptant l’agilité

par Jean-Laurent de Morlhon

Typologie : retour d’expérience

Sous ce titre original, se cache un retour d’expérience de l’entreprise Vidal Software sur la mise en place de Scrum au sein de leurs équipe. Ce retour d’expérience était surtout un échange entre nous et les orateurs.

Vidal a dans un premier temps expliqué l’évolution de leur Scrum Board. Il y en a eu trois versions différentes. Chaque nouvelle version a ajouté une colonne : par exemple la V3 a ajouté une colonne pour indiquer qu’une user story est validée et testée.

Ensuite Vidal nous as parlé de la rétrospective. Pendant les six premiers mois, il n’y avait pas de rétrospective. Une fois mise en place, une des tâches que l’équipe faisait lors de la rétrospective, était de noter l’équipe sur un ensemble de critères qu’ils avaient choisis. Cela permettait à chaque rétrospective de voir l’évolution de l’équipe, et aussi de déterminer les point noirs à corriger.

14h30 : Vaincre le Plouf

par Guillaume Duquesnay

Typologie : modèle

Cette présentation fut la plus originale dans sa forme de celles auxquelles j’ai assisté. Guillaume joue presque une pièce de théâtre lorsqu’il nous présente son plouf.

Le plouf est ce phénomène qui nous empêche d’accomplir des choses que l’on doit faire. C’est cette force mystique qui nous fait toujours remettre les choses au lendemain. Le plouf s’applique aussi bien au domaine professionnel que personnel.

Guillaume commence par nous donner les grandes caractéristiques du plouf. Certaines des caractéristiques sont son silence, le fait qu’il se répand d’un individu à l’équipe, et qu’il attaque au commencement des projets…. Après avoir caractérisé l’ennemi, Guillaume nous donne les moyens de le vaincre. Ces conseils peuvent paraître simple, mais sont sûrement la clé pour vaincre le plouf. Quelques unes des actions à entreprendre pour éviter le plouf :

• Engager une action pour se rapprocher de l’objectif
• Lors de réunion, commencer le plan d’action définit dès les dernières minutes de la réunion
• Demander les choses directement (de visu), plutôt que d’envoyer un mail, ou de laisser un message répondeur
• S’inspirer des méthodes des équipes du marketing

15h00 : Sortez vos crayons

par Benoit Gantaume

Typologie :  bonnes pratiques

L’objectif de cette présentation est de présenter des idées plus percutantes grâce au dessin. Cette présentation est un bon mélange entre pratique et théorique.

Benoit commence par nous rappeler quels sont les prérequis de la pensée visuelle :

• un crayon
• des yeux
• un cerveau
• une main
• un support

Il continue en nous décrivant les 4 étapes de la pensé visuelle :

1. regarder
2. voir
3. imaginer
4. présenter

Une fois ces prérequis établis, Benoit nous explique des manières de dessiner et de schématiser les pensées que l’on veut exprimer. Par exemple, si on veut dessiner quelque chose qui répond à la question “qui ?”, alors il est bien dessiner un portrait. Si le dessin doit répondre à “Où ?”, il est bien de dessiner une carte. Les règles qu’il donne ne sont pas absolus, et peuvent être contourner en fonction du besoin.

S’en suivent beaucoup d’ateliers en petits groupe, pendant lequel nous devions représenter Scrum en dessin en répondant aux question du style : Qui est scrum ? Où est scrum ? pourquoi scrum ?…

Bilan à mi-conférence

Cette première journée a été l’occasion de rencontrer des professionnels de l’Agile. Leur présentation est l’occasion de chercher les meilleures idées à utiliser tous les jours durant nos projets. Mon but était de trouver des bonnes pratiques afin de faire entrer l’agilité chez mon client où les pratiques agiles sont inexistantes. De bonnes idées me sont parvenues dès ce premier jour. Le deuxième jour ne pouvait s’annoncer qu’excellent !

Bibliographie

Vaincre le plouf : http://vaincre-le-plouf.fr/

The post Conférence Agile France 2010 : Jour 1 first appeared on In Fine - Le Blog.