éric mignot

Mon premier objectif professionnel est de construire des logiciels avec plaisir et d'aider les autres à avoir du plaisir dans cette industrie. Les approches Agiles sont pour moi aujourd'hui la meilleure façon d'y arriver. C'est pourquoi je me concentre sur l'évangélisation des approches Agiles en enseignant Scrum et les pratiques XP dans mes mandats.
voir mon profil complet »

Articles de éric :


    dans Agile

    Kata @onf

    Du nouveau dans l’équipe web @onf. On avait déjà fait des randoris et nous avons commencé les katas. Comme l’exercice était nouveau pour l’équipe, nous avons emprunté une structure d’atelier tdd. L’atelier que j’avais en tête était la session de craftsmanship de @slagyr lors du Scrum gathering à Orlando début 2010.

    Pendant une rétrospective, l’équipe avait décidé d’explorer les katas le lundi suivant. Je leur ai proposé la structure suivante, répartis sur 1h45:

    - 15mn : on regarde une vidéo de kata. En l’occurrencehttp://vimeo.com/16935085

    - 45mn : chacun pratique seul ce kata dans le langage de son choix.

    - 15mn : pause

    - 15mn : quelqu’un se lance et fait le kata devant tout le monde

    - 15mn : feedback du public au démonstrateur sous la forme d’un jeu de la perfection

    Pendant la pratique, la consigne est de réussir à trouver un chemin qui puisse être parcouru en moins de 15mn.

    Etant à l’ONF, Office Nationnal du Film canadien, les analogies évoquées par l’équipe après l’exercice ont tourné autour du film. La personne qui fait le kata s’est retrouvé tantôt réalisateur tantôt héros malheureux malgré lui. Les tests plutôt dans le rôle de l’agresseur. A un moment, un copier/coller malheureux s’est retrouvé être le méchant de l’histoire. Le public l’avait vu, pas le héros…

    Ce que j’ai aimé avec cette analogie proposé par l’équipe et nouvelle pour moi c’est l’idée consistant à voir le kata comme un film dans lequel le scénario est autant important que le dénouement, voir plus important. En effet traditionnellement dans un kata, le héros gagne à la fin ; peu de suspence de ce côté. Le public est sensible au scénario, au chemin incrémental choisi par le réalisateur, et apprécie un tableau final original et des émotions fortes en cours de route.

    Cela m’a donné envie de scénariser plus mes katas en empruntant des chemins dangereux, en revenant en arrière, … pour finalement gagner tout de même à la fin ;) .

    dans Scrum, Sur le terrain

    Definir “Terminé”

    Résumé
    Les axes de réflexion que je considère pour construire une définition de Terminé :

    • qualité externe
    • qualité interne
    • autorisations
    • déploiement
    • exploitation

    Lorsque je travaille avec une équipe à établir ou modifier notre définition de “Terminé” (le Done de Scrum), je ne leur propose pas d’exemple comme point de départ de la discussion. Par contre je leur propose les différents axes de réflexion dans lesquels nous allons identifier les points pertinents pour eux.

    Pour démarrer la discussion, je propose de commencer par explorer les axes qualitatifs :

    • qualité externe
    • qualité interne

    Qualité externe
    Cette notion de qualité externe nous parle de notre capacité à construire le bon logiciel, celui qui rend les services souhaités, à un niveau de performance satisfaisant, à un niveau d’ergonomie qui fluidifie sa prise en main et son utilisation. C’est la qualité perçue lorsqu’on utilise le système.

    Pendant cette réflexion, nous partageons alors comment nous comprenons cette idée de qualité externe et nous décidons quels types de tests nous souhaitons construire notre confiance dans notre code : des tests automatiques qui exercent le système dans son ensemble avec des données réalistes, des tests qui spécifient les conditions aux limites des services rendus, des tests de performance, des tests de sécurité, des tests de traduction, …

    La question des anomalies est parfois abordée à ce moment dans la discussion. Cette discussion peut être difficile parce que chargée d’un historique peu flatteur pour les programmeurs. On distingue ici deux types d’anomalies: les anomalies que l’on découvre après la mise en production et celles que l’on connaît avant la mise en production.
    Pour les premières, il s’agit de définir comment nous allons les prendre en compte, c’est à dire comment leur découverte va impacter le travail en cours. La démarche stop the line du Lean est la démarche la plus cohérente avec une approche empirique, même si elle représente des défis importants.
    Pour les secondes une attitude cohérente avec ce que l’on vient de dire consiste à ne jamais déployer un système avec des anomalies connues. Cela demande souvent beaucoup de courage dans des environnements qui ont malheureusement appris à supporter des systèmes avec beaucoup d’anomalies.

    Qualité interne
    Cette notion de qualité interne nous parle de notre capacité à construire correctement un logiciel. Par correctement, on entend ici un logiciel que l’on peut faire évoluer durablement. Plusieurs outils aujourd’hui sont capables de construire des indicateurs qui, lorsqu’on les améliore, nous aide à construire un logiciel que l’on peut faire évoluer durablement. Par exemple le pourcentage de couverture de code par des tests unitaires et d’intégration, la compléxité cyclomatique, le taux de duplication… Certains outils, comme Sonar, vous permettent même assez simplement d’implémenter votre propre règle.

    Les tests automatiques sont des indicateurs de qualité assez simples à construire car ils se basent sur une analyse statique du code, c’est à dire sur une photo du code à un instant donné. Or il se trouve que l’on a constaté que le fait d’écrire un test avant d’écrire le code de production qui le fait passer a un impact majeur très positif sur la qualité du logiciel construit. On parle ici d’un indicateur de qualité dynamique qui nous renseigne sur la manière dont le logiciel a grandit. La plupart des équipes mettent en place cette idée simplement en ayant la discipline de toujours écrire un test avant d’écrire du nouveau code.

    Vient ensuite, dans l’ordre chronologique des étapes à passer pour être prêt à déployer un système en production, la question des autorisations nécessaires.

    Autorisations
    Certaines industries contrôlées imposent aux créateurs de logiciels de faire la preuve de certaines caractéristiques dans un format imposée par une convention. C’est le cas par exemple dans l’avionique ou la pharmacie, pour en citer deux à priori assez éloignées. D’autres normes, internes celles-ci s’imposent parfois aux équipes.

    La plupart du temps, ce besoin d’autorisation déclenche la rédaction de document dans un format souvent imposée à l’équipe. Le travail récurrent d’une itération à l’autre consiste alors selon les cas à les créer ou bien à les tenir à jour.

    Déploiement
    Le déploiement par incréments successifs suppose que plusieurs déploiements vont être effectués pour mettre à jour un système. Dans ce contexte, il est pertinent de ne pas considérer le premier déploiement comme un cas particulier mais bien comme le déploiement d’un incrément qui part d’un état précédent vide.
    Des éléments de différentes natures sont à considérer. Sans ordre d’importance, on peut citer : un moyen d’interdire l’accès au système pendant le déploiement du nouvel incrément, la modification de l’environnement, la modification des configurations réseaux, la modification de la structure de données, la migration des données, … Disposer de tests automatiques de déploiement s’avère encore une fois très utile pour être capable de déployer chaque incrément sans détruire le système déjà en place.

    Exploitation
    Ce qui précède concerne la préoccupation de mise à jour d’un système existant. Il faut aussi considérer les activités qui tournent autour de l’utilisation du système en place. Selon les cas il s’agit de choses aussi variées que des scripts de redémarrage, la formation des utilisateurs, la formation des équipes travaillant à la hot-line du système, …

    Si le développement incrémental est nouveau pour vous et que vous avez des difficultés à établir votre définition de Terminé avant de commencer, rassurez-vous c’est normal. Explorez pendant une première discussion les différents axes de réflexion qui vous semblent sensés et établissez vos premiers indicateurs en fonction de la vision du produit. Faites une itération et pendant la revue d’itération posez vous la question: est-on prêt à déployer cet incrément en production ? Si oui, faites le. Si non, améliorez votre définition de Terminé pour la suite.

    dans Scrum

    Agenda cyclique

    J’étais récemment chez un client pour faciliter une journée de planification de release et encore plus récemment en Belgique pour animer une session de formation Scrum pendant laquelle je décrivais cette journée. Ce retour d’expérience s’est avéré être de valeur pour les participants alors je tente une version écrite ci-dessous.

    J’utilise de plus en plus ce que j’appelle un agenda cyclique pour animer ce type de rencontres. Il s’agit d’une part de rendre visible que nous faisons une réunion avec un objectif partagé et que plusieurs activités vont nous aider à l’atteindre. Et d’autre part d’afficher clairement le droit qu’ont les participants de changer d’activité.

    Donc ce jour là nous étions réuni pour construire un planning de release. Je commence par le dessin ci-dessous.

    Notez au passage que cela permet de garder visible au tableau et clair dans nos têtes l’objectif de notre journée. Puisque le client du jour nous avait demandé de l’aide à la mise en place de Scrum, j’ai commencé à dessiner des activités en utilisant le vocabulaire de Scrum.
    Au début de la journée, il n’y avait que les éléments faciles puis au fur et à mesure de la journée, j’ai ajouté les éléments potentiellement plus polémiques qui nous permettait d’avoir les conversations les plus utiles pour la suite.
    Comme le pointait récemment Vincent (dans ce blog), l’art de déclencher les bonnes conversations est le coeur du boulot du ScrumMaster. Laisser des places vides dans le cercle de l’agenda vous donne la chance d’être opportuniste pendant la réunion et de focaliser l’énergie des participants en pointant l’élément difficile pour eux, tout simplement en l’écrivant au mur et en proposant d’en parler.
    Maximiser l’intérêt de ce cercle réside essentiellement à ne pas reproduire avec lui un comportement de réunion en cascade pendant laquelle les activités s’enchaîneraient dans un ordre établi à l’avance et où implicitement on se revient pas sur une activité passée.

    Ici au contraire, itérer sur les mêmes activités pour profiter de ce que l’on a appris a beaucoup de valeur.

    Exemples:

    Le PO essaye d’estimer une valeur d’affaire relative pour un groupe d’éléments. Il n’y parvient pas. Son sentiment intime est qu’il faut faire l’ensemble ou rien. Il a donc envie de mettre la même valeur relative à chaque élément. Tout le monde l’invite à se forcer à trouver des valeurs différentes. On semble dans l’impasse.
    Et si on fusionnait ces éléments et qu’on cherchait un autre axe de découpage, plus orienté valeur ?

    Un calcul automatique de ROI nous incite à adopter une priorisation qui semble n’avoir aucun bon sens. Faisant appel à ce bon sens, le PO et la Team priorise le Product Backlog et le résultat frustre les participants car les premiers éléments prioritaires n’apportent aucune valeur et il faudra attendre longtemps avant de pouvoir déployer un logiciel utile.
    Et si on effaçait tout le Product Backlog et qu’on se demandait quel logiciel construire en 2 semaines pour rendre service à au moins une personne ?

    Dans ces deux exemples, je constate que les participants résistent à cette idée d’effacer ou de remettre en cause le travail déjà effectué. Encore plus surprenant : c’est également le cas pendant une formation, c’est à dire pendant un exercice.

    Pour aider les participants à effectuer cette remise en question, j’utilise des time-boxes assez petites pour chaque activité. Cela rappelle aux participants de ne pas tenter de finir une activité, mais de la faire contribuer à l’objectif commun.

    A titre d’exemple, ci-dessous une photo de l’agenda cyclique d’un sprint planning. A l’époque je ne notais pas l’objectif de la réunion au centre du cercle mais au dessus. Maintenant je le met à l’intérieur du cercle.

    dans Scrum

    Total cost of Ownership

    Scrum est un outil de visibilité. On ne le dira jamais assez. Et sans doute faut-il trouver des formulations alternatives pour pouvoir être compris par des gens différents, avec des cultures et des expériences qui modifient la façon dont ils interprètent cette phrase. Et parfois, un dessin suffit, un graphique suffit.

    Aujourd’hui j’ai passé une bonne heure avec un gestionnaire de projet traditionnel qui souhaitait savoir comment faire un suivi budgétaire “avec Scrum”, selon sa formulation. Nous nous concentrons donc sur cette idée de “suivi budgétaire”. Une chance pour moi, il est très ouvert et me dit simplement “comment fais-tu toi ?”. Magnifique non ?

    Simple : la clef dans son cas c’est la définition de Done. En effet, nous plaçons un curseur dans la définition de Done. Ce curseur sépare ce que livre l’équipe à chaque itération et le reste des activités qu’il faudra faire pour avoir un Working Software, soit un logiciel en production utilisé par quelqu’un.

    D’un seul coup, la définition de Done devient un outil concret pour lui. Voici ci-dessous une version simplifiée de ce à quoi nous sommes arrivés. Il lui apparaît très naturellement que les activités concrètes de mise en production sont liées au Done et que le voir exprimé ainsi lui fait réaliser tous les éléments que l’ensemble de l’équipe avait jusque là oublié.

    Combinés aux Release burndown chart et au Value burnup chart, ce budget plan complète la vision 360° qu’il a du nouveau jeu dans lequel il joue.

    Selon les prévisions que vous ferrez, vous pourrez utilisez ces graphiques pour amener une discussion autour de la vision partagée que vous avez des prochaines itérations. Par exemple aujourd’hui, les graphiques étaient sensiblement semblables à ceux-ci et la réflexion principale de mon interlocuteur a été de dire que le budget serait consommé avant que la courbe de valeur ait commencée à s’infléchir, ce qui lui a donné envie de trouver plus de budget.

    Attention néanmoins à ce que l’on fait dire aux chiffres. Même dans ce cas d’un petit nombre d’itération, la courbe de valeur qui ne décroit pas pourrait nous mettre la puce à l’oreille et nous parler de la piètre qualité des estimations de valeur. Il se pourrait que l’on ait affaire à des priorités et non à des estimations relatives de valeur ajoutée. Mais ceci est une autre histoire ;)

    dans Agile, Développement logiciel, Scrum

    “S’engager”

    Pendant un planning d’itération, il est commun de demander à l’Equipe de fixer/choisir/établir son “engagement”. Et la plupart du temps, le comportement attendu consiste à choisir un ensemble de fonctionnalités à livrer au client à la fin de l’itération qui commence ce jour là.

    Dans Scrum, ce rituel de planning se répète à chaque commencement d’itération.

    planning

    Pendant l’itération, c’est le temps de la réalisation. C’est là que les artistes-artisans informaticiens réalisent le miracle de leur art pour livrer un morceau de logiciel d’une qualité exceptionnelle. Hum… Mais au fait, c’est quoi pour vous la Qualité ? Autour d’un café on devrait probablement s’entendre sur le fait que des professionnels de l’informatique devraient livrer des logiciels de qualité. Voire, que leur “engagement” a quelque chose à voir avec “livrer un logiciel de qualité”.

    Durant les dix dernières années, une technique appelée TDD s’est développée. J’imagine que vous connaissez ça très bien, ainsi que sa représentation la plus populaire :

    tdd

    La couleur pour le côté du refactoring est parfois le vert pour exprimer que pendant une opération de refactoring, “les tests passent toujours”. J’ai pris ici le gris surtout parce que sur ma magnifique casquette tdd, le refactoring est en gris.

    Mais au fait : quelle est la vocation du refactoring ? Parce que si le test passe, je pourrais livrer le code et n’en parlons plus ! Bien sûr la plupart du temps le logiciel n’est pas fini ; il faut continuer. Pour pouvoir continuer, on met à profit ce temps de refactoring pour transformer le code que l’on a écrit à la va-vite pour faire passer le test en un “code de qualité”. L’objectif semble donc être la qualité. Autrement dit, l’artiste-artisan informaticien professionnel construit un code de qualité pendant le refactoring. Encore autrement dit : l’artiste-artisan informaticien respecte son engagement de qualité pendant le refactoring.

    Maintenant si je dessine le cycle du TDD plutôt comme ça, est-ce que vous me voyez venir ?

    fusion

    En mélangeant les notions d’engagement du planning d’itération et de refactoring du tdd, on pourrait vivre la situation suivante : pendant un planning d’itération, l’Equipe considère les premiers éléments de carnet de produit, écrit les tests et les fausses implémentations qui font passer les test, et réfléchit à son engagement : quel part du code écrit pendant le planning pouvons-nous transformer en code de qualité pendant l’itération ? Par exemple pendant le planning on a fait passer 4 tests mais notre engagement ne couvre que la livraison du code faisant passer les 3 premiers.

    Cette approche met au premier plan les notions de qualité et de professionnalisme des équipes on affichant que la valeur des professionnels de l’informatique va se chercher pendant le refactoring. “Pisser du code” ne s’appliquerait plus qu’au code écrit le plus vite possible pendant le planning pour faire passer les tests, pas au code que l’on livre.

    dans Agile

    Randori pendant l’inter-contrat

    En y pensant un moment, il nous est apparu que dans beaucoup de sociétés autour de nous, sociétés de services entre autres, il y avait des consultant en inter-contrat et que « gérer » ces personnes était pour certaines un petit casse-tête. Une des préoccupations souvent évoquée est comment profiter du passage en inter-contrat pour améliorer les compétences des personnes concernées ?

    Il y a quelques temps j’ai appelé un ami dans une de ces sociétés et je lui ai proposé de venir animer un coding-dojo pour tous les consultants en inter-contrat de son service. Je me rappelle que lorsque que je lui proposé cela, il a tout de suite été emballé et m’a dit « demain ? ».

    Ils m’ont accueilli fin septembre pour animer un coding-dojo randori chez eux et les participants en redemandent. C’était la première fois qu’ils participaient à un coding-dojo alors nous avons dédié 30 minutes, sur les 4 heures, à en parcourir les principes et le fonctionnement. Je me suis limité au rôle d’animateur et de coach TDD. Le soir cela me manquait de ne pas avoir touché le clavier ;-) .

    Si vous aussi vous avez des inter-contrat et que l’expérience vous intéresse, appelez-nous !

    dans Agile

    TDD vs DDD vs BDD vs xDD vs …

    Ce que je tente d’expliquer pendant les cours de Test-Driven Development (TDD) c’est que le TDD est une approche générique pour aborder un développement logiciel.

    « Malheureusement », quand on lit « TDD », on comprend souvent tests « unitaires ». Sans doute parce qu’historiquement les premiers tests écrits en suivant cette approche ont été des tests « unitaires ». Mais le concept peut se voir plus globalement.

    Par exemple si on ne prend les deux cours suivants proposés par Pyxis:

    • Test-Driven Development
    • Specifications exécutables avec GreenPepper

    Le premier propose des ateliers d’écriture de tests automatiques écrits avec un framework xUnit alors que le second se concentre sur l’écriture de tests automatiques écrits avec GreenPepper. En lisant plusieurs forums je réalise que certains contributeurs classeraient sans doute naturellement le premier dans une case TDD et le second dans une case DDD, voire BDD. En fait les deux cours appartiennent à la catégorie TDD.

    « Test-Driven » est seulement une autre manière de dire : définissons ce que nous attendons sous la forme d’un test. Pour moi – je suis Scrum Master ;-) – cette approche est similaire à avoir une définition de « terminé ». Cette façon de nous exprimer pourrait d’ailleurs nous emmené sur plusieurs branches si nous poursuivions l’analogie avec Scrum. Quel est votre fil de penséé ? tests->liste de tests->backlog de tests->specifications exécutables->Product Backlog ?

    dans Scrum

    Quel est le profil d’un bon ScrumMaster ?

    Bien sûr, en premier lieu, un ScrumMaster est convaincu de la valeur de Scrum en tant que prisme à travers lequel il appréhende les évènements, les situations.

    Scrum est très simple à décrire et très difficile à mettre en oeuvre.

    Un bon ScrumMaster comprend en quoi Scrum est difficile. Défis humains, défis organisationnels, défis techniques. Lesquels seront les plus pénalisant pour le projet ? Cela dépendra des contextes. A chaque projet cela sera différent, plein de surprises, enrichissant.

    Un bon ScrumMaster aide tout le monde à tirer le meilleur profit de Scrum. Au delà de sa connaissance pointue de Scrum, la forme de cette aide peut varier du tout au tout selon les contextes. Un bagage technique aidera-t-il à déceler une incompréhension entre deux membres d’équipe ? Peut être. Une attitude enjouée favorisera-t-elle la motivation pendant les mois d’hivers ? Peut être. Un naturel curieux permettra-t-il d’apprendre par hasard une information capitale à la machine à café ? Peut être. En se concentrant sur les aspirations personnelles des gens, un ScrumMaster aidera-t-il à favoriser le climat de confiance si chère à l’émergence d’une équipe auto-organisée ? Peut être. Peut être cette fois-ci. Sans doute pas à chaque fois.

    Aspirer à ce que tout le monde tire le meilleur profit de Scrum c’est aussi reconnaître que Scrum ne se met pas en place en 1 jour. Patience. Gardons-nous de juger hâtivement un ScrumMaster en regardant “son” Scrum sans lui en parler. Il a sans doute lui aussi un backlog d’adoption, une stratégie incrémentale de mise en place des pilliers de Scrum, qui sont comme une petite musique dans sa tête :
    - équipe auto-organisée
    - backlog priorisé
    - livraison d’incréments terminés à chaque fin d’itération
    - processus empirique