InfOsaurus

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 3 novembre 2011

Agile(s) Tour(s) 2011

Cette année, j'ai eu la chance de participer à deux dates de l'Agile Tour : le 20 Octobre à Montpellier suivi de celui de Bordeaux le 21. Voici un petit retour sur les 2 événements.

Agile Tour Montpellier


Agile Tour Montpellier

Le lieu

Ce premier Agile Tour montpelliérain avait lieu à l'école Polytech sur le campus de l'Université Montpellier 2. Quatre salles dont un grand amphi avaient été réservées pour l'occasion. Du côté du programme, la volonté affichée était de cibler 2 types de publics : les décideurs ("boss") et les développeurs ("geeks") plus les étudiants et universitaires.


Sessions

Software Craftsmanship par Jean-Laurent de Morhlon

J-L de Morlhon
Beaucoup de choses intéressantes dans cette présentation qui couvrait plein de sujets sur la théorie et la pratique de Software Craftsmanship, de l'historique du mouvement au manifeste en passant par les pratiques comme TDD et SOLID. Quelques morceaux choisis :

  • Ne pas s'en tenir au Craftsmanship Manifesto, flou et difficile à comprendre, voire même l'oublier.
  • Besoin de rétablir l'équilibre entre process et pratiques de développement, ces dernières sous-estimées notamment dans certaines implémentations actuelles de Scrum.
  • Une des techniques d'apprentissage les plus efficaces reste le mentoring ("conduite accompagnée").
  • Notion "d'heures de vol" accumulées nécessaires pour atteindre un certain niveau, comme un pilote d'avion.
  • Pair Hero et Ping Pong Programming permettent de pratiquer en s'amusant.

A noter que la slide "! Art" (le développement n'est pas de l'art) a fait réagir et suscité un vif débat philosophique sur la signification de l'art ;-)

Au final, une session maitrisée et fort sympathique ; même si on connait déjà un peu le sujet, c'est toujours enrichissant d'avoir le point de vue de personnes éclairées surtout sur un domaine peu exploré en France comme Software Craftsmanship.

Le pilotage par les tests par Jérôme Avoustin

Cette session présentait TDD, ATDD et BDD avec des démos et en filigrane un retour d'expérience sur un projet piloté par les tests. Jérôme nous avait prévenu que le rythme allait être élevé pour tout faire tenir en une heure, et en effet le contenu était riche.

  • J'ai bien aimé l'approche "top-down" mise en place sur le projet qui est une sorte de méta-cycle red-green-refactor où on crée un test BDD rouge avant d'écrire les tests de plus bas niveau en TDD, et on reboucle sur le passage à vert du test BDD pour finir.
  • Enseignement instructif sur l'évolution de la façon de développer : avec cette approche, le temps passé en tests a beaucoup augmenté mais celui passé à debugger a énormément diminué.
  • Définition de la qualité qui me plait bien : c'est quand le coût d'ajout d'une fonctionnalité est stable.

En tout cas, encore une présentation qui donne envie de faire du BDD :) Il est intéressant d'avoir des retours d'expérience sur de vrais projets qui l'ont mis en place, finalement pas si nombreux.

Contractualisation agile par Jean-Francois Jagodzinski

La session de cet Agile Tour qui m'a laissé le plus perplexe. J'ai l'impression que toute la présentation tournait autour du pot des contrats agiles sans jamais vraiment attaquer le sujet. Jean-Francois Jagodzinski était un peu en mode questionnement socratique et je n'ai pas vraiment vu où il venait en venir...
Heureusement des membres du public ont posé les "questions qui fâchent" à la fin en allant droit au but, ce qui a permis d'amorcer une discussion sur les difficultés des contrats agiles.

Une autre présentation de Jean-François est disponible sur slideshare mais ce n'est pas exactement celle de l'AT Montpellier.

Bref, je sors mon joker pour celle-là, je devais être trop endormi après le buffet...

Transformation agile au delà des équipes projet, par Romain Vignes

Un retour d'expérience instructif sur la transformation agile menée au sein de la société Wyplay, éditeur de logiciels de TV numérique, avec notamment comme clients SFR et Vodafone. Voici ce que j'ai noté :

  • Points de difficulté dans l'adoption de Scrum : organigramme à revoir, auto-organisation et discipline, transparence, disponibilité du client.
  • Autre difficulté importante : passage d'équipes multi-projets mais mono-métier à des équipes mono-projet mais inter-disciplinaires.
  • Une métrique intéressante utilisée chez Wyplay pour limiter l'éparpillement : Team Turn Over = Nb développeurs à cheval sur 2 projets ou + / nb total de dev.
  • Point d'accord avec la présentation de Jérôme Avoustin : le temps de debug s'est rapidement raccourci suite à l'adoption de l'agilité.

Projet et Cycle de vie agile par Thierry Cros


Thierry Cros

Une présentation classique mais efficace sur le cycle de vie des projets agiles. Quelques points que j'ai relevés :

  • Nécessité d'apprendre le "jeu de la planification agile"
  • La phase projet et la phase maintenance d'une application ne formeraient qu'une seule phase de pilotage par feedback
  • "Estimation belote" est plus proche de la réalité que Planning Poker :)


Ce que j'ai aimé

  • L'accueil très pro des organisateurs
  • Bonnes présentations "Geek"
  • Pas mal d'ateliers
  • Le buffet servi à midi
  • Les conférences de l'amphi retransmises sur Lanyrd


Ce que j'ai moins aimé

  • Peut-être moins de mélanges entre "populations" du fait de la séparation très marquée des sessions "geeks"/"boss"

Quoi qu'il en soit, pour une première c'était très réussi, chapeau bas aux organisateurs et orateurs qui ont parfaitement su faire prendre la mayonnaise !


Agile Tour Bordeaux


Agile Tour Bordeaux

Le lieu

Pour la seconde fois, l'AT Bordeaux se déroulait à l'Enseirb. Là aussi, 4 salles dont un grand amphi étaient réservées, avec un sympathique espace ouvert au rez-de chaussée. Le programme était un peu plus orienté ateliers que les années précédentes, avec un coding dojo, un Kanban Game, un atelier Billes Rouges, l'espace ouvert... mais les présentations techniques ou orientées projet étaient bien entendu présentes.


Sessions

Kata Marrant par Emmanuel Gaillot et Jonathan Perret


E. Gaillot et J. Perret

Si vous n'avez pas encore vécu une prestation de ces deux hurluberlus, je vous conseille vivement d'en faire l'expérience. On assiste à une vraie pièce de théâtre d'impro, où le public participe en déposant des suggestions de thèmes ou de manières de coder dans une corbeille.

Chaton interstellaire, arc-en-ciel de sodium... difficile de décrire ce qui est sorti de ce kata mais le fun était bien là !

J'ai découvert par la même occasion CoffeeScript, un petit langage sympa qui dépouille JavaScript de ses accolades et points-virgules.

Ni gladiateurs, ni bisounours par Christophe Thibaut

Sans doute la présentation la plus radicale et la plus propice à réflexion à laquelle j'ai eu l'occasion d'assister lors de ces Agile Tour. La première partie recensait des anti-patterns d'équipes très bien vus ("Nez dans le guidon", "Maillon faible", "Feu de camp"...) dans lesquels je pense la majorité du public s'est reconnu. Venaient ensuite des propositions de solutions avec les Core Protocols. Je ne vais pas tous les décrire mais il s'agit de techniques (dont certaines assez déconcertantes) favorisant la communication d'équipe. Je ne sais pas si elles sont toutes applicables telles quelles partout, mais c'est en tout cas certainement une bonne source d'inspiration.

2 moments de "déclic" parmi d'autres :

  • "On peut influer sur la motivation d'une personne uniquement négativement"
  • "Les membres d'une équipe sont comme les cartes composant une quinte flush, elles n'ont d'intérêt que par les relations qui les lient"

Quarante ans de crise, dix ans d'agilité par Laurent Bossavit


Laurent Bossavit

J'avais déjà vu cette présentation en vidéo, mais en vrai, c'est quand même vachement mieux... Laurent y met en perspective - ce qui à ma connaissance a rarement été fait auparavant - l'histoire du génie logiciel depuis ses origines à une conférence de l'OTAN en 1968 jusqu'à nos jours, avec l'état actuel de la discipline. L'exercice est riche en enseignements et force est de constater que la plupart des questions posées il y a 40 ans n'ont toujours pas trouvé de réponse.

La présentation explique ensuite pourquoi Agile est une innovation de rupture et s'ouvre enfin sur la perspective de l'avenir de l'agilité et la proposition de passer d'une culture agile orale à une culture plus formalisée avec l'Institut Agile et une prise en compte accrue de l'agilité dans les programmes des universités.

Si vous n'avez pas encore vu cette vidéo, je vous la conseille vivement.

TDD, je commence demain ! par Fabien Bézagu

Le pari de cette session était osé - faire découvrir Test Driven Development et convaincre les développeurs présents de franchir le cap dans leur job. Tout cela en commençant par une démonstration en PHP (qui a dit qu'il y avait des sous-langages ?...) L'ensemble était bien mené par Fabien malgré un public que j'ai senti pas aussi avide d'échanges qu'espéré.


Ce que j'ai aimé

  • Beaucoup de sessions techniques orientés "geek" (même si je n'aime pas ce mot) et d'ateliers
  • Le mot des sponsors beaucoup plus agréable, avec moins de concours de qui a la plus grosse agilité que l'année dernière (qui a dit normal, il n'y avait pas de SSII ?...)
  • L'organisation toujours au poil
  • Les orateurs toujours disponibles pour discuter, un plaisir


Ce que j'ai moins aimé

  • L'espace ouvert qui manquait de prise en charge des nouveaux arrivants
  • Le coding dojo dur à rattraper en cours de route si on n'avait pas suivi au début
  • Les coups de gong du Sky Castle Game qui ont semblé perturber les acteurs du Kata Marrant (qui ont quand même essayé de rivaliser, avec leur petite sonnette !)
  • Les 2h de retard du TGV de la nuit précédente, heureusement j'ai pu tenir avec moult café pendant la conférence ;)


L'équipe de l'Agile Tour Bordeaux


Pour conclure, un grand merci à tous les organisateurs et participants des deux Agile Tour et à l'année prochaine !

mardi 5 octobre 2010

L'auto-organisation : analyse d'un concept subversif

« The best architectures, requirements, and designs emerge from self-organizing teams. »

Cet extrait du Manifeste agile met en lumière un des points importants de la réussite d'une démarche agile : la capacité d'une équipe projet informatique à s'organiser elle-même. Mais même si la notion est connue et souvent évoquée comme qualité première d'une équipe agile, qu'entend-on précisément par auto-organisation et quelles peuvent être ses limites ?

Auto-organisation 3

Un phénomène émergent

Voici la définition que donne Wikipedia de l'auto-organisation dans le domaine des sciences physiques et de la systémique :

« Le terme auto-organisation fait référence à un processus dans lequel l'organisation interne d'un système, habituellement un système hors équilibre, augmente automatiquement sans être dirigée par une source extérieure. Typiquement, les systèmes auto-organisées ont des propriétés émergentes (bien que cela ne soit pas toujours le cas). »

Il est amusant de constater une certaine ressemblance avec la définition agile de l'auto-organisation, bien qu'elle recouvre d'autres réalités. L'auto-organisation n'est pas une valeur, ni une pratique ou même une compétence. Le manifeste agile la classe parmi les principes, mais on peut aussi parler de phénomène d'auto-organisation car c'est en réalité le résultat de plusieurs façons de fonctionner qui se mettent en place progressivement au sein d'une équipe :

Répartition collective des tâches. Alors que dans un système hiérarchisé traditionnel de type command and control c'est le plus souvent le chef de projet qui assigne individuellement les tâches aux développeurs, les équipes agiles se répartissent le travail de manière collective. Plus exactement, il s'agit d'une auto-attribution libre du travail avec accord tacite du collectif : le membre de l'équipe choisit lui-même sa prochaine tâche mais il le fait en présence et avec l'approbation de tous ses coéquipiers. Le moment précis pour cette attribution est celui du standup meeting / daily scrum dont la fréquence journalière permet un ajustement du partage du travail au plus près de la réalité du moment. Effet collatéral : exit les diagrammes de Gantt planifiés des semaines à l'avance ; une partie importante des prérogatives du chef de projet disparait, ce qui n'est pas sans poser problème à certains comme nous le verrons plus loin.

Engagement collectif. Dans un mode de fonctionnement agile, l'équipe s'engage auprès du client à produire au cours de l'itération suivante un certain nombre de fonctionnalités représentant une valeur métier pour ce dernier. C'est un des moments importants où l'équipe en tant que bloc solidaire prend ses responsabilités vis-à-vis de l'extérieur. Cela contraste fortement avec la gestion de projet classique où la responsabilité est plutôt individuelle, chaque développeur s'engageant à respecter l'estimation qu'il a chiffré (ou que quelqu'un d'autre a chiffré pour lui !) et des "fusibles" hiérarchiques successifs sont en place : si quelque chose dysfonctionne, c'est d'abord le chef de projet qui est responsable puis il va chercher le membre de l'équipe qui a fauté pour en tirer les conséquences.

Appropriation collective du projet. Une équipe auto-organisée se caractérise ensuite par une cohésion interne forte assortie d'une réelle prise en main des enjeux du projet, obligatoire du moment où l'équipe ne reçoit plus d'ordres extérieurs directs sur la façon de faire. Ce sentiment d'appartenance à la une même tribu, d'adhésion à une même cause est renforcé par les "rituels" agiles tels le daily standup (et qui gravitent autour du task board, comme le décrit très bien Tobias Mayer) ainsi que des pratiques comme le pair programming qui permettent de propager la connaissance du logiciel efficacement parmi les membres de l'équipe.

Amélioration collective. Ce point rejoint la deuxième partie de la définition scientifique de l'auto-organisation : "Typiquement, les systèmes auto-organisées ont des propriétés émergentes". En effet, un système auto-organisé ne naît pas avec un fonctionnement parfait, il l'adapte et l'améliore au fil du temps. En agilité, ce sont bien sûr les rétrospectives et autres dispositifs inspect & adapt qui jouent ce rôle en vue d'une évolution continue.


Auto-organisation4

Les raisons du débat

Voilà pour les traits principaux d'une équipe auto-organisée, mais force est de constater que le concept est loin de faire l'unanimité parmi les acteurs de l'informatique et suscite beaucoup de réticences. Pourquoi cette subversivité alors que les méthodes agiles se veulent être de plus en plus courantes ? Je pense que cela tient essentiellement à trois raisons :

  • Comme je l'ai dit plus haut, le déplacement vers l'équipe de beaucoup des prérogatives du chef de projet (pouvoir d'assigner et de planifier les tâches de développement comme bon lui semble, interface avec le client...) fait grincer des dents, en particulier chez les premiers concernés. On peut les comprendre, d'autant plus qu'en étant tout à fait honnête, il reste quand même aujourd'hui un gros flou autour de ce qui se passe une fois que la méthode a dit "le Scrum Master/coach n'est pas un chef de projet", voire "il n'y a plus de chef de projet du tout". A qui reviennent les responsabilités comme le suivi budgétaire et comptable, les aspects administratifs, les procédures internes, le recrutement... ?
    Piste intéressante : dans un récent billet, Laurent Bossavit, fondateur de l'Institut agile, fait appel à une théorie de l'économiste Ricardo sur la spécialisation du travail pour apporter un début de réponse à cette crainte. Il pose la question suivante : dans un environnement agile, est-il obligatoire de conserver des rôles personnels rigides regroupant un cortège de responsabilités bien fixées, ou s'il ne serait pas plus judicieux de les éclater en répartissant les responsabilités en fonction des compétences de chacun ?
  • Deuxième crainte soulevée par l'auto-organisation : le renversement de paradigme que cela implique. Aplatissement de la hiérarchie, bouleversement des canons de l'organisation du travail et des rôles de chacun, et pas seulement à l'intérieur des équipes de développement... C'est tout le problème de la douloureuse transition d'une structure pyramidale de type command & control à un contexte agile où l'encadrement s'apparente plus à du servant leadership, ce qui touche uniquement les équipes projets dans un premier temps mais a vocation à être assez viral dans toute l'entreprise. A ce propos je vous recommande la très bonne présentation de Roman Pichler sur le changement de rôle des managers dans Scrum.
  • En dernier ressort, inutile de se le cacher, l'idée d'auto-organisation déclenche chez beaucoup et surtout les anglo-saxons, par un réflexe quasi-psychologique, un rapprochement avec des concepts revendiqués par des mouvements d'extrême-gauche : pouvoir au peuple, anarchisme, libertarisme... et aussi l'auto-gestion, cousine lointaine de l'auto-organisation. La crainte implicite sous-jacente est que l'équipe devienne un électron libre, hors de contrôle de l'entreprise, ou, pire, que le rapport de contrôle s'inverse.

Auto-organisation2

Le spectre de l'auto-gestion

Apparu à la fin du XIXème siècle, le concept d'auto-gestion caractérise un groupe, souvent producteur de biens ou services en petite quantité, dont le principe est justement d'être un électron libre. Les décisions se prennent exclusivement parmi ses membres qui sont en général sur un pied d'égalité. Au cours de l'histoire, l'auto-gestion a été expérimentée dans des environnements multiples : coopératives ouvrières, agricoles, jardins partagés, regroupements de salariés... Certaines entreprises d'ingénierie informatique s'y essaient même de nos jours.
Malgré le succès d'un certain nombre de ces entreprises, on retient souvent les mésententes fréquentes entre membres de l'organisme auto-géré ou l'embourbement dans des pourparlers interminables qui peuvent paralyser l'activité du groupe et faire avorter l'initiative. Souvent qualifiés d'utopistes, de doux rêveurs, les participants de ce type d'aventure n'ont malheureusement pas une grande réputation de sérieux. Et c'est précisément cela que craignent les managers : remettre un pouvoir de décision entre les mains de l'équipe ne revient-il pas à le confier à des personnes peu habituées à la responsabilité et trop nombreuses pour trancher, résultant en un "grand n'importe quoi" ? Quels que soient les termes, la question mérite d'être posée.

Dans la même mouvance sociale, il est aussi intéressant de voir que certains agilistes se définissent explicitement comme anarchistes et contribuent activement à porter les méthodes agiles à d'autres domaines que l'informatique, comme par exemple Tobias Mayer (oui, encore lui). Ils restent pourtant rares.

Pour finir

Revenons à la définition de l'auto-organisation en agilité : il est utile de noter que le manifeste agile ne s'aventure pas à la prôner en-dehors de l'équipe projet et des "architectures, requirements, and designs". Pas de volonté affichée de révolution sociale à l'échelle de l'entreprise toute entière de la part des "pères fondateurs", donc. Mais essayer de faire fonctionner le phénomène auto-organisation au niveau développement ne serait déjà pas si mal. Si davantage d'entreprises engagées dans une démarche agile faisaient preuve de confiance et de lâcher-prise vis-à-vis de leurs équipes et abandonnaient pour de bon le sacro-saint besoin de contrôle et de pilotage individuel, sans doute ferait-on un grand pas dans la réussite des projets, la qualité du logiciel livré et le bien-être des collaborateurs.

jeudi 1 octobre 2009

Smells DDD, quand votre domaine sent des pieds

Smell

En ce moment, je me replonge dans Domain Driven Design, l'approche du développement logiciel orientée domaine initiée par Eric Evans. Il m'est subitement apparu une chose que je ne m'étais jamais représentée auparavant, certainement parce que j'avais abordé le sujet avant tout par son aspect technique : le plus important à mon avis dans DDD, ce ne sont pas les patterns, c'est la philosophie de la modélisation collaborative du domaine.

Comprenez-moi bien, j'estime que les design patterns évoqués dans DDD sont brillants, ce sont des guides précieux pour développer un code du domaine clair, maintenable et faiblement couplé. Mais pour moi, l'essence de DDD ne réside pas là. Elle réside dans la collaboration étroite entre experts métiers, concepteurs et développeurs pour construire un modèle du domaine qui reflète la réalité et permet de résoudre de vraies problématiques métier. Elle réside dans la constitution d'un langage commun qui, en plus de faciliter la compréhension du métier par les personnes techniques, instaure dialogue et confiance au sein de l'équipe projet. Car je pense que c'est cela qui, au final, permet de faire du bon logiciel.

Je me suis sans doute heurté à ce constat car ce n'est pas du tout le cas dans l'organisation dans laquelle je travaille actuellement. Ca serait même plutôt le contraire. La forme de communication privilégiée est le fichier Word de besoin, de recette ou le ticket d'outil de gestion de bugs. Les conversations téléphoniques sont rares et ont souvent lieu en famille, entre développeurs ou entre experts métier. Sans parler de vraies rencontres entre développement et métier, inexistantes. Une méfiance d'origine floue entre les deux camps a installé une guéguerre perpétuelle MOE/MOA, les uns accusant les autres d'en demander toujours trop et de changer sans cesse de besoin ; les seconds soupçonnant les premiers d'être des tire-au-flanc. Du coup, l'idée de base chez la MOE est de se conformer à la virgule près aux documents, tels des actes notariaux, et chez la MOA d'en fourrer le plus possible dans lesdits documents. Bien sûr, c'est la connaissance du domaine qui en pâtit, tant l'incompréhension est grande. Il est même surprenant de voir que des développeurs avec plusieurs années dans l'organisation n'ont qu'une vision parcellaire et approximative du métier. Au final, le résultat se ressent dans la qualité du logiciel.

D'ailleurs - et ça ne s'applique pas seulement à mon exemple - de tels problèmes refont souvent surface sous la forme de code smells qu'on pourrait appeler Domain smells. Je me suis amusé à en recenser quelques-uns :

  • Domaine fantôme : ça peut paraître abérrent, mais il n'y a pas de couche domaine dans le projet dont je parle, en partie à cause de la technologie employée. Le métier est fondu dans la masse du reste du code. Il va sans dire qu'une couche domaine séparée est indispensable, pour toutes les raisons de découplage, de lisibilité... qu'on peut imaginer.
  • Domaine râpé : On constate aussi parfois que des bouts de domaine sont saupoudrés dans des couches différentes, le plus dur étant de ne pas être tenté d'en mettre dans la couche présentation. Même si ça peut être justifié, il vaut mieux pour la maintenabilité de l'application conserver au même endroit tous les éléments liés au domaine.
  • Domaine indéchiffrable : un des principes de DDD est que le code du domaine doit être clair et compréhensible, et donner tout de suite une vision d'ensemble à celui qui y jette un oeil. Malheureusement ce n'est pas toujours le cas, souvent à cause d'une représentation brouillonne du domaine dans le code dûe à un manque de dialogue avec les experts métier. De plus il est facile de se perdre en créant toujours plus de helpers, de services et autres gestionnaires qui embrouillent la compréhension du domaine.
  • Abus de notion : qui n'a jamais été confronté au mot-valise du domaine, à la notion métier un peu floue qui se retrouve toutes les trois lignes de code dans chaque module de l'application ? Comme si un développeur avait trouvé que le mot sonnait bien et décidé de l'utiliser aussi fréquemment que possible. C'est souvent le signe d'une modélisation pas assez en profondeur, d'un concept du domaine qui recouvre trop d'aspects et devrait sans doute être subdivisé.
  • Frères jumeaux : parfois c'est l'inverse, deux mots différents sont employés à travers l'application pour recouvrir la même notion métier. Cela peut mener à penser qu'il s'agit de deux choses différentes, ce qui est source de confusion. Convenir d'un seul terme précis et bien identifié permettra d'éviter les malentendus.
  • Déphasage de concept : ce smell se fait sentir lorsqu'on interroge un expert métier sur une notion présente dans le code du domaine, et qu'on s'aperçoit qu'elle est en total décalage avec la réalité, même si l'application semble se comporter correctement pour l'utilisateur. Il peut s'agir d'une mauvaise interprétation ou d'une supposition hasardeuse de la part d'un développeur. En tout cas, le code est à reprendre et la communication est à revoir.

Je vois d'ici certains dire "C'est bien beau, mais les experts métier ne sont pas souvent disponibles et une communication écrite restreinte est mieux que pas de communication du tout." Bien sûr, mais après tout, n'est-ce pas dans l'intérêt de la personne métier d'avoir une collaboration aussi efficace que possible avec le développeur qui réalisera l'application pour lui ? N'est-ce pas primordial de s'assurer qu'il est au diapason de la réalité du domaine ?

Même si l'expert métier ne peut pas se rendre souvent disponible, il devrait l'être autant que faire se peut. Une solution au problème pourrait être de timeboxer les scéances de conception collaborative. Parfois, un dialogue d'une demi-heure bien cadré et sans perturbation peut être plus efficace qu'une réunion décousue de deux heures, qui aura pourtant demandé plus de disponibilité à l'expert du domaine...