é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

    Dojo@Pyxis

    J’animerai un coding-dojo dans les locaux de Pyxis à Laval le mercredi 29 juin prochain de 5pm à 7pm. Et vous êtes tous les bienvenus ! Pour ne pas lutter avec un clavier et un IDE inconnus, apportez votre laptop avec votre environnement de développement préféré prêt à faire rouler des tests. Pour cette première édition, je vous proposerai une formule que j’utilise lorsque j’aide un groupe à débuter avec les katas. Cela ressemble au déroulement ci dessous.
    1. 5′ introduction
    2. 15′ présentation du sujet
    3. 40′ travail libre en binôme
    4. 10′ pause
    5. 15′ présentation par un binôme
    6. 15′ perfection game par le public
    7. 10′ clôture
    Habituellement on choisit le binôme qui présente pendant la pause. A bientôt :)
    dans Agile

    ATTD avec Cucumber

    L’exercice proposé ce mois-ci par @12meses12katas m’a donné envie cette fois d’utiliser Cucumber. J’avais dans l’idée d’apprendre à utiliser les Scenario Outline qui sont une alternative intéressante aux tableaux lorsqu’on veut donner plusieurs exemples d’utilisation d’une même formule. Comme je n’avais jamais fait cela, c’était une bonne occasion. Pour ceux qui ne voient pas de quoi il s’agit, voici à quoi cela ressemble rapidement: Je voulais rester dans des temps raisonnable pour l’enregistrement vidéo. Alors j’ai essayé de n’écrire que des tests Cucumber, pour gagner du temps. Je n’étais pas très confortable avec cette idée car j’anticipais que j’allais avoir envie d’écrire des tests plus unitaires en cours de route. Cela m’a incité à écouter les tests avec plus d’attention et à programmer par intention. J’ai vraiment apprécié cet exercice et plus particulièrement:
    • Coder dans le train avec Vincent qui a mis à mal la première version de mon modèle,
    • La liste de tests capturée sous la forme de scénarios à venir,
    • le refactoring de la liste de test qui précise les intentions des tests quand vient le temps de les écrire. Cette activité est homogène à un travail sur un backlog pendant un planning d’itération.
    J’ai fait le choix de mettre toutes les classes du domaine au même endroit. Il s’agissait au début de gagner du temps au chronomètre. Finalement cela s’est aussi avéré très pratique en cours d’exercice.
    dans Agile

    Kata .Net

    Que faites-vous le 15 juin prochain après le souper ? Vous êtes les bienvenus dans les locaux de Microsoft à Montréal à partir de 18:30 pour un kata. Amenez de quoi coder pour en tirer le maximum. Plus d’info sur le site de la communauté .Net de Montréal ici.
    dans Agile

    Professionnal Scrum Foundations

    Salut, Nous (Vincent et moi) venons de donner deux sessions de la nouvelle formation PSF de scrum.org. Et je voulais partager avec vous ce que j’ai appris. Les participants aiment les exercices de simulation pendant lesquels ils construisent du logiciel. J’ai donné des formations pendant lesquelles les participants construisent des prototypes papier. J’ai ressenti qu’ils préfèrent le logiciel. Cela améliore visiblement leur compréhension de comment utiliser Scrum dans leur projet. Cela augmente aussi la participation ; ils sont plus motivés à faire les exercices. La mise en pratique d’un Scrum avec plusieurs équipes a beaucoup de valeur pour les participants. Pendant la PSF, la quatrième itération – pendant la seconde après-midi – impose aux participants de mettre en commun leur travail pour construire un site internet portail de leurs différents produits. Les échanges sur les différentes stratégies d’intégration sont beaucoup plus profonds que dans une formation théorique car les participants sont riches de cette mise en pratique. La PSF est plus pertinente que la PSM pour les équipes qui débutent avec Scrum. J’ai donné beaucoup de PSM. Elle n’est pas faite pour les débutants. La PSM se concentre sur la compréhension de Scrum nécessaire à un Scrum Master. La PSF aborde tous les rôles de Scrum de façon plus équilibrée. Les Product Owner, Team et Scrum Master ainsi que toute personne qui est ou sera en contact avec une équipe Scrum trouveront dans la PSF ce dont ils ont besoin pour commencer: des réponses à leurs questions commençant par « comment ».
    dans Agile

    Classes ouvertes en ruby

    Le kata du mois dernier proposé par @12meses12katas m’a encore appris quelque chose. C’était la première fois que je faisais en Ruby le kata bowling. Comme d’habitude je voulais passer sous les 10 minutes avec un code et des tests avec lesquels je sois confortable, c’est à dire qui communiquent leurs intentions d’une manière que je pourrais encore comprendre l’année prochaine.

    J’ai commencé par écrire des tests qui ressemblaient à ceci:

    describe Bowling do
    specify "spare" do
        claire.sheet = "1/------------------"
        claire.score.should == 10

        claire.sheet = "1/2-----------------"
        claire.score.should == 14
    end
end

    J’ai continué tranquillement avec le kata et lorsque j’ai fait passé les tests avec les cas plus complexes avec des spares et des strikes j’ai regardé mon chronomètre et j’ai pris une baffe: 24 minutes. J’ai recommencé plusieurs fois, j’ai posé mon scénario sur une feuille, pour arrêter de perdre du temps à calculer les résultats attendus, j’ai utilisé un raccourcis clavier de plus pour introduire une variable dans RubyMine, j’ai tapé sur mon clavier comme un fou, j’ai mis une table dans les tests, et j’ai péniblement atteint 18 minutes. Bof.

    Puis je me suis rappelé du kata des chiffres romains de @jacegu du mois dernier et j’avais bien aimé ses tests qui utilisaient une extension de la classe Fixnum. Alors j’ai essayé de mettre ça en pratique et cela donnait des tests assez différents:

    describe Bowling do
    specify "spare" do
        "1/------------------".scores(10)
        "1/2-----------------".scores(14)
    end
end

    J’aime mieux cette version des tests qui se concentrent sur le problème à résoudre et supprime le bruit. En plus cela m’a permis de baisser le chrono :) .

    dans Agile, Développement logiciel, Scrum

    “a working proposal” : semaine 3/3

    C’est toujours émouvant pour moi d’arriver à ce qui semble être la “fin” d’une aventure. Depuis 3 semaines nous avons eu cette journée en point de mire. La construction de cette offre autour d’un logiciel qui fonctionne chaque semaine a été le fil rouge qui m’a guidé dans une foule d’autres activités.

    Ce que j’ai aimé dans cette expérience:

    • binômer avec Xavier
    • avoir un fil rouge parmi une foule d’autres activités

    Pour que cela soit parfait, faudrait-il que notre prospect décide de poursuivre ou bien est-ce que cela va chercher ailleurs ? Cette idée de “gagner la propale” dans le future rend-elle meilleure l’expérience passée ?

    Comme on nous l’a dit souvent, c’est plus l’aventure, le parcours qui nous rend heureux, moins que la destination. Alors je n’ai pas d’idée pour améliorer l’aventure ; le logiciel oui ;)

    dans Agile, Développement logiciel, Scrum, Tutoriel

    “a working proposal” : semaine 2/3

    Deuxième semaine de notre aventure de construction logiciel en parallèle de la mise au point de notre offre de développement. Bien sûr cette semaine s’achève avec une revue d’itération et une rétrospective.

    C’est l’occasion pour nous de faire le point sur notre incrément, le produit dans son ensemble, notre compréhension actuelle d’une stratégie incrémentale pertinente pour atteindre les objectifs visés. Pour cela nous nous sommes retrouvés autour du second incrément déployé sur Heroku, autour de notre Product Backlog et de notre propale.

    La semaine dernière nous n’avions pas partagé avec notre prospect l’incrément réalisé. Cette semaine c’est différent. Maintenant que nous avons deux incréments, nous avons de quoi démontrer ce que veut dire “construire un logiciel par incréments successifs”. Il se trouve que notre prospect n’a jamais travaillé de cette manière. La semaine dernière nous avions décidé de déployer certes mais sans le lui dire. Notre sentiment était que la notion d’incrément risquait d’être très théorique à ce stade. Maintenant nous avons deux incréments, avec des adresses distinctes. On peut donc voir concrètement l’ajout de fonctionnalités entre les deux versions. Quel sera son feedback ? Suspence…

    dans Agile

    « a working proposal » : kick-off

    Lundi matin nous avons fait un sprint planning un petit peu particulier. Je voulais partager ça avec toi cher lecteur :) . Nous travaillons à construire une offre pour un développement logiciel. « Bien sûr », en tant qu’infecté par l’agilité nous nous concentrons sur le « working software » et adoptons une démarche empirique. Sachant que nous avons un délai de 3 semaines ça a été naturel pour nous de partir sur 3 itérations de 1 semaine chacune. Chaque semaine nous allons construire un petit morceau du logiciel et d’autres choses autour ; par exemple le document très officiel de l’offre en elle même qui décrit notre démarche pour la suite. Les étoiles se sont alignées pour nous aider. Nous avons pu passer une journée entière à faire du story mapping avec le client et nous avons pu voir le système actuel. Maintenant nous avons démarré notre première itération sur cette offre. Qu’allons nous apprendre sur le domaine de ce client ? Qu’allons nous livrer ? Suspense…
    dans Agile, Scrum

    #scrum release burndown chart

    PM: I want to see increase the velocity of the Team
    PO: I want to see decrease the remaining work

    PM: If the velocity increases, the remaining work will decrease
    PO: No, new work could be added at the same time

    PM: I don’t like when the Team updates an item with a smaller effort estimation because the velocity could decrease
    PO: I like when the Team updates an item with a smaller effort estimation because the remaining work decreases

    PM: You don’t track the velocity in a velocity chart?
    PO: No, I track the remaining work in a release burndown chart

    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 ;) .