Ce qui s’est bien passé

• Mise en place dès le retour de la formation des “Spécifications par l’exemple“
• Les conférences Agiles Grenoble 2012 où je suis intervenu comme orateur pour promouvoir les avantages du TDD.
• Les conférences mix-IT avec notamment la conférence Tests automatique le mythe du ROI et le talk “La voie du programmeur“
• Des coding dojos du CARA intéressants sur le BDD et le SRP.
• Quelques articles que j’ai remarqués cette année:
  • Pourquoi les ingénieurs sont grincheux ?
  • Une modélisation du TDD par des personnes physiques : Programming for business users – By. Brain Marick
  • TDD and the Gamification of Testing
  • BDD in the large
  • Why Developers Never Use State Machines
  • Une étude sur les bénéfices du TDD

Ce qui s’est moins bien passé

• Toujours pas d’article sur les conférences Agile Innovation. Pourtant j’ai pu mettre en place quelques pratiques que j’y ai glanées : le Niko niko, le graphe satisfaction utilisateur, le speed boat…
• Seulement 7 articles contre 11 l’année passée.

Les indicateurs

Belle année 2012, j’espère que 2013 sera une année treize agile pour tous. Merci à ceux qui y contribuent, notamment les démineurs d’information : @gmantel, ‏ @sanlaville, @johan_alps, et bien d’autres…

The post Rétrospective 2012 appeared first on Agilité, Architecture, C++ "in the mix".

Nous nous sommes donc réunis pour un atelier de 2-3 heures dont voici l’agenda :

• Introduction et objectifs (5 min)
• Perfection game (50 min)
• Débriefing (1 h)
• Phoenix game (20 min)
• Tour de table (20 min)

Perfection game

Après avoir précisé les objectifs (trouver des bonnes pratiques pour bien écrire ses exemples), nous avons formé 3 groupes. Chacun dispose d’une version papier de la 20aine d’exemples rédigés au cours des 2 itérations. Le principe du perfection game  a été appliqué sur chaque exemple :

• Identifier ce qui est bien fait
• Identifier ce qui n’est  pas bien fait
• Proposer des axes d’amélioration

Chaque exemple démarre avec une note de 10. On enlève 1 point par sujet d’amélioration. Chaque point est noté sur un post-it.

L’objectif n’est pas de donner une note à chaque fiche mais d’en parcourir un certain nombre pour pouvoir débattre ensuite de ce qu’apporte tel parti pris par rapport à tel autre.

Débriefing

Pour la mise en commun, on coupe le tableau en deux, chaque groupe vient coller ses post-its bon point et point d’amélioration. Parfois il y a divergence : certains groupes ont identifié une pratique à garder alors que d’autres veulent la bannir. Il faut profiter de ces divergences pour bien confronter les deux points de vue. Parfois on ne parle tout simplement pas de la même chose, parfois c’est qu’il y a une troisième voie à trouver.

Phoenix game

Le principe est de choisir l’exemple qui a eu la moins bonne note au perfection game et de le faire renaître de ses cendres en le réécrivant le mieux possible. Pour faire cela, on  reforme les groupes en prenant bien soin de mélanger les personnes. Chaque groupe a un paper board et réécrit sa version idéale de la fonctionnalité. 20 minutes plus tard, on lève les crayons et chaque groupe explique aux autres sa production.

Comme pour le perfection game, le but n’est pas d’aller au bout du travail de réécriture. L’important est d’identifier les parti-pris qui sont communs à tous ainsi que les idées qui sont propres à chacun.

Tour de table

On clôt la séance par un tour de table où chacun donne son “conseil” pour bien écrire une spécification par l’exemple.

Cet atelier a été vraiment bénéfique :

• De véritables consensus  ont été trouvés
• Le développement et le fonctionnel ont communiqué et partagé leurs points de vue
• Les axes d’amélioration ont été trouvés collectivement.
• Tout le monde s’est exprimé

Le format de cette session est fortement inspiré de l’approche pédagogique que Gojko Adzic utilise lors de sa formation. Je conseil vivement cette formation à tous ceux que le sujet intéresse.

Donner un axe d’amélioration

The post Un atelier “spécification par l’exemple” appeared first on Agilité, Architecture, C++ "in the mix".

Reinventing software quality. La key note de Gojko Adzic est à la hauteur des deux jours de formation « Specification by example » : concise, imagée et humoristique. Voici ce que j’en retiens dans les grandes lignes :

• « The value of a metric is the value of the descision it helps ».
• « All models are wrong : some are usefull »
• Les métriques de développement n’ont pas forcément de sens pour les business guys. Il faudrait un google translate pour transformer la qualité logicielle en coût !
• La philosophie de la pyramide de Maslow appliqué à la qualité.

Séance des développeurs anonymes. Par Rémi Salanville et Johan Martinson. Je code mal, tu code mal…. entrainons nous avec les objets callisthéniques. Ne sous estimons pas l’impact de ces petites règles simples qui nous font réfléchir sur l’approche objet !

Mon binôme m’a tué. Par Emanuel Gaillot et Jonathan Perret de UT7. Superbe farce sur le binômage. On se croirait dans un cauchemar…dans lequel on se projette facilement. Le trait est fortement exagéré et pas de « recette » à la fin. Cependant, cela fait réfléchir sur l’attitude de chacun. En conclusion : malgré les difficultés les deux parties souhaitent continuer à binômer. Quelques perles :

• Pour le pilote : coder sans rien dire dès que l’autre ouvre la bouche dire : « à je sais… »
• Pour le copilote : soupirer, dicter tous les raccourcis clavier, glisser des erreurs dans le co-pilotage, lire ce qui est écrit, corriger tout de suite toutes les fautes de frappe, etc…

Sweet rupture. La key note de  Laurent Sarrazin nous raconte son épopée dans la conversion de la Société Générale vers l’agilité. On y trouve plusieurs de concepts dont :

• la puissance de la banane
• les bocaux à c.. (Attention : comment sortir du bocal du voisin ? Et si les bocaux sont pleins, il faut se remettre en question).
• la mise en place d’une salle de jeux (agiles)
• des références à plusieurs blogs I don’t care about agile,  safari agile, agilitrix.com, etc…

XP Games. Par Cédric Joseph, Julie Boichot-Castagne et Bruno Pommier. Dans cette session on gonfle des ballons et on compte des cartes à jouer. La problématique de l’estimation est étonnamment réaliste : comment comparer la difficulté entre « Gonfler 6 ballons » et « Construire un château de carte » ? C’est souvent ce grand écart que l’on doit effectuer en planification. Par contre je m’attendais à ce que d’autres aspects d’eXtrem Programming soient abordés : le binômage, l’intégration continue, le pilotage par les tests… Je ne connais d’ailleurs aucun jeu illustrant ces pratiques.

TDD : du mythe à la réalité. J’aurais aimé plus de monde pour notre session.  Mais étant la dernière nous avons eu un bel échange à la fin malgré l’apéritif dans la grande salle . Nous avons partagé entre autre sur :

• La problématique de ne plus arriver à écrire de tests rouges
• L’utilisation des patterns Abstract factory et Single Responsability Principle.
• Quand ce n’est plus testable : utilisation du pattern Adapter, injection de classes métier etc…
• Le piège de ne pas écouter les tests et continuer dans la complexité

Au ROTI  50% de j’adore / 50% de c’est correct.
A refaire donc !
Les slides sont sous http://prezi.com/4uw2xeukk5pu/tdd-du-mythe-a-la-realite, et le code source sous https://github.com/mathieucans/TDDice

Merci aux organisateurs CARA et sponsors de rendre ce genre d’évènement possible.

Merci à ceux qui écrivent sur le sujet : Agilex, Xavier, Agilarium, L’Agilitateur, Alexis Monville, Atelier Logiciel…

The post Agile Grenoble 2012 – Rétrospective appeared first on Agilité, Architecture, C++ "in the mix".

En ouverture, je vais commencer la matinée par “Changer pour mieux coder” et les objets calisthéniques. Mon deuxième choix sera pour “Construire une vision partagée” ou encore  “Product Owner : comment tirer toute la puissance de l’agilité”.

En deuxième séance mon premier choix est sans conteste “Mon Binôme m’a tué”, problème humain trop souvent rencontré. En deuxième choix ce serait “La fleur de lotus ou comment redynamiser vos rétrospectives”.

Pour la 3ème partie, j’hésite entre deux sessions de deux heures : REX BDD avec specflow , XP games ou encore le projet CAISSE de la boite à outil.

Pour finir, je ne pourrais pas assister à la conférence “Well-crafted software : un code maintenable avec le “principe de responsabilité unique” qui se déroule à la même heure que ma présentation.

Et vous ? Qu’est-ce qui vous fait envie dans tout ça ?

The post Agile grenoble 2012 : J-10 appeared first on Agilité, Architecture, C++ "in the mix".

Comme introduction, le jeu « Système complexe » trouve tout son intérêt. Le principe est simple et sans matériel : tous les individus se promènent dans la salle, chacun choisi pour lui même deux autres individus. Au signal, chaque individu se positionne à équidistance de ses deux élus. Le système est ainsi défini, plus on est nombreux moins il se stabilise. On débriefe sur le fait que l’équipe est un système interactif où le comportement de chacun influe sur celui des autres.

Commence ensuite la réflexion sur le vécu de chacun orientée autour de 4 axes :

• les manques / les apports
• les frustrations / les satisfactions

Il n’est pas toujours facile de distinguer les différences entre ces axes mais la réflexion est ouverte. Chacun parle à son tour de son vécu puis on fait une conclusion collective.

Le bilan de cette séance est intéressant : on dérape assez vite dans la rétrospective de projet mais les langues se délient et les idées sortent. Ce que j’en retiens est que l’équipe joue un rôle de Feedback de grande qualité quand au travail de chacun. Comme on s’y attend, pour certains, les personnes externes à l’équipe ont plutôt tendance à confondre les individualités dans une entité d’équipe.

The post Et moi dans une équipe SCRUM ? appeared first on Agilité, Architecture, C++ "in the mix".

Open key note :

Belle entrée en matière par Claire Blondel. Sa présentation sur l’éducation positive, nous pose pleins de questions sur notre éducation “à la française”, la peur de l’échec et entrepreneuriat.
Claire part du constat que toute notre éducation est centrée sur le fait qu’il est interdit de se tromper. Outre la pression générée, la “non éducation à l’erreur” nous laisse peu autonome face à l’échec. Et pourtant, tout le monde s’accorde sur le fait que l’échec permet d’avancer.
Quelques citations :

• “Je suis fatiguée d’avoir peur de me tromper”
• “En France on a l’adulte en fin de chaîne qui vérifie si le travail est bon.”
• “Interdire l’erreur c’est se condamner à l’immobilité”

L’expérience des billes rouges :

En première session, j’ai choisi d’assister à l’expérience des billes rouges présentée par Alexis Montville. Un jeu de rôle restitue le pilotage d’un projet par les indicateurs : le nombre de billes rouges dans un tirage au sort. Alexis joue le rôle du directeur d’agence, nomme un chef de projet, embauche 3 développeurs et deux auditeurs qualité. Le débriefing qui s’en suit est intéressant :

• L’analogie entre les billes rouges et les anomalies en informatique est toute trouvée
• Le projet est piloté par des indicateurs qui sont indépendant de la performance du travail fourni. On fait dire n’importe quoi à l’indicateur : “regardez : en mettant la pression on obtient plus de résultat!” … Sur un tirage au sort ?
• En tant qu’employé on voudrait se servir de l’entretien de fin d’année pour progresser. Mais un entretien par an est ridicule comme boucle de feedback. Une phrase à ce propos : “L’entretien individuel est l’effet tunnel du management traditionnel“

Les échanges en fin de session étaient intéressants, dommage qu’on ai pas eu le temps de détailler les points de W.E. Deming.

Lean startup, l’entreprenariat agile :

 Je suis ensuite allé voir la session de Emmanuel Levi-Valensi de la société PIA. “L’approche lean startup est une méthode rigoureuse pour augmenter le succès des stratups”. Emmanuel nous propose sa lecture du livre d’Eric Ries, qui incite à appliquer le (Plan, Do, Check, Act) du lean :

• Se concentrer sur la satisfaction client
• Etre une entreprise innovante
• Aller voir avec ses yeux
• Accepter de se montrer

Les concepts de pivot, de Business Canvas Model de MVP sont abordés. Tout un paragraphe est consacrés au biais cognitifs notamment le fait qu’il est plus difficile de se remettre en question quand on a pris la parole en publique.

Une remarque sur l’écoute active : lorsqu’on présente le produit, il est difficile d’être attentif à la petite phrase ou à l’attitude de 15 secondes qui va nous dire beaucoup sur le ressenti utilisateur. Ça me rappelle certaines démos SCRUM, où l’équipe identifie au préalable le démonstrateur et le rapporteur responsable de collecter un max de feedback.

Sky Castle Game :

L’après midi j’ai participé au Sky Castle Game. Animé par ses majestés : Fabrice Aimetti, Antoine Vernois et Philippe Launay. Inspirés des XP games, le jeu modélise la vie d’un projet. Le cadencement est assuré par un gong (très bruyant ) et on essaye de maîtriser le flux de production… pas facile :

• l’auto organisation sans facilitateur
• de conserver une vision d’ensemble : on se retrouve avec le toit de la tour construite avant les murs.
• de prendre une décision face à un goulot d’étranglement.

Tests automatiques les mythe du ROI :

J’ai fini ma journée sur une session de grande qualité. Gilles Mantel nous livre une autre approche pour estimer les gains des tests automatiques : l’utilisation du mécanisme des options en bourses pour estimer la non qualité.

L’approche est vraiment pertinente et il n’hésite pas à renverser la pyramide des tests dans le cadre de projet en cycle en V. J’ai trouvé la courbe de Scott Ambler sur le coût des non conformité intéressante. J’ai bien aimé aussi la pique sur l’outil Selenium : le seul élément chimique qui dissout le Mercure.

Quelques sessions que j’ai ratées :

Comme on ne peut pas tout voir, je suis un peu déçu de ne pas avoir pu assister (entre autres) aux sessions suivantes :

• Lighting talk (plusieurs présentations de 5 minutes). Heureusement j’ai pu voir certaines vidéos dont celle de Jean-Baptiste Dusseaut : La voie du programmeur. Le contenu est super et les slides avec Prezi ca jette!
• Utilisateur, mon amour, ma migraine de Sophie Freiermuth. Mais où trouve-t-on la vidéo ???

Super journée, merci aux organisateurs et aux intervenants de rendre possible un séminaire de cette qualité.

The post Mix-IT 2012 – décantation appeared first on Agilité, Architecture, C++ "in the mix".

Lorsque la paire est composée d’individus assez équivalents en terme d’approche, de compétences, de rapidité d’écriture etc.. le problème ne se pose pas : le clavier peut être monopolisé un moment pour passer très vite de l’un à l’autre. J’ai déjà vu le clavier changer à chaque ligne. La sensation de performance est grisante. C’est là qu’on sent que la paire va vraiment plus vite que deux “monômes”. La difficulté arrive avec la notion de mentor. Lorsque la paire n’est pas équilibrée. Pour des raisons de performances qui semblent louables, le plus expérimenté risque de monopoliser le clavier et de ne pas se mettre au niveau de son équipier, de ne pas lui laisser le temps de progresser.

L’analogie avec le sport est intéressante  : dans les équipes on observe parfois quelques stars du ballon qui vont droit au but sans faire de passe. Cela donne l’illusion de performance car la personne moins compétente ne progresse pas si on ne lui fait pas confiance en lui laissant la balle.

Il en va de même dans les projets informatiques : les experts doivent apprendre à être un peu moins performants pour laisser le temps à leur coéquiper de progresser. A court terme on livre moins; mais très vite, les compétences des individus montent et le projet est gagnant.

The post Pair programming : le rôle de mentor et la théorie de la passe appeared first on Agilité, Architecture, C++ "in the mix".

Le programme d’origine affiche le nombre de travaux en cours dans la sortie console. Basé sur les timers systèmes, toutes les secondes une nouvelle tâche est lancée. Chaque tâche durant 5 secondes, il y a augmentation du nombre de tâches en cours jusqu’à stabilisation du processus.

class Program
{
    static void Main(string[] args)
    {
        int workInProgress = 0;
        var workGenerator = new System.Timers.Timer();

        workGenerator.Interval = 1000;
        workGenerator.Elapsed += (o, s) =>
            {
                Console.WriteLine("begin work {0}", ++workInProgress);
                System.Threading.Thread.Sleep(5000);
                Console.WriteLine("end work {0}", --workInProgress);
            };

        workGenerator.Start();

        Console.WriteLine("Press any key to terminate");
        Console.ReadLine();

        workGenerator.Stop();
    }
}

Voici une des solutions abordée.

1 – Créer une interface IWorkGenerator pour rendre le programme indépendant de la techno utilisée

public interface IWorkGenerator
{
     double Interval { get; set; }
     event EventHandler Elapsed;
     void Start();
     void Stop();
}

2 – Utiliser le pattern adapter pour adapter le System.Timer à cette nouvelle interface

class SystemTimerAdapter : IWorkGenerator
{
    private System.Timers.Timer timer;

    private void OnTimerElapsed(object sender, System.Timers.ElapsedEventArgs e)
    {
    	if (this.Elapsed != null)
    	{
    	this.Elapsed(this, EventArgs.Empty);
    	}
    }

    public event EventHandler Elapsed;

    public double Interval
    {
    	get
    	{
    	return this.timer.Interval;
    	}
    	set
    	{
    	this.timer.Interval = value;
    	}
    }

    public void Start()
    {
    	this.timer.Start();
    }

    public void Stop()
    {
    	this.timer.Stop();
    }

    public SystemTimerAdapter(System.Timers.Timer timer)
    {
    	this.timer = timer;
    	this.timer.Elapsed += OnTimerElapsed;
    }

}

3 – Limiter le nombre de tâches en cours par l’utilisation du pattern decorator

class WorkLimiterDecorator : IWorkGenerator
{
    private IWorkGenerator decorated;
    private int workInProgress;

    private void OnDecoratedElapsed(object sender, EventArgs e)
    {
    	if (this.workInProgress++ < WorkLimit)
    	{
    	if (this.Elapsed != null)
    		this.Elapsed(this, e);
    	}
    	this.workInProgress--;
    }

    public event EventHandler Elapsed;

    public int WorkLimit { get; set; }

    public double Interval
    {
    	get { return this.decorated.Interval; }
    	set { this.decorated.Interval = value; }
    }

    public void Start()
    {
    	this.decorated.Start();
    }

    public void Stop()
    {
    	this.decorated.Stop();
    }

    public WorkLimiterDecorator(IWorkGenerator decorated)
    {
    	this.decorated = decorated;
    	this.decorated.Elapsed += OnDecoratedElapsed;
    	this.workInProgress = 0;
    }
}

Avantages et inconvénients de cette architecture
Avantages

• L’interface rend le programme indépendant de la rélisation du générateur de tâche
• Le pattern adapter peut s’appliquer à divers implémentation (thread, événement,…)
• Le décorateur est indépendant de la rélisation. On limite vraiment le TAF car peut appliquer la limitation à n’importe quelle implémentation de IWorkGenerator

Incovénients

• On réimplémente à chaque fois l’interface. Sur une interface compliquée celà peut être fastidieux.

Remarque
La classe WorkLimiterDecorator doit être thread safe. Une amélioration du code consiste à créer deux méthodes atomiques IncrementAndTest et Decrement.

The post Limiter son TAF avec les Design Patterns appeared first on Agilité, Architecture, C++ "in the mix".

Ce qui s’est bien passé

• Code Retreat en janvier. Superbe expérience que je conseille à tout le monde.
• Migration du blog et un nouveau nom : “agileinthemix.com”.
• Nouveau projet avec près de 70% de couverture par les tests et une équipe en constante progression.
• Des architectures plus SOLID
• Mise en place d’un “Learnig (half) day“.
• Agile Grenoble 2011 : vraiment enrichissant, je mets en application ce que j’y ai appris.
• Quelques articles qui m’ont marqués cette année :
  • I Interface
  • Three pillars of Unit Tests
  • Anonymous Methods – Behind the Scenes
  • Dangers et pièges des systèmes de suivi des références

Ce qui s’est moins bien passé

• Je n’ai pas écrit d’article sur Agile innovation 2011. C’est dommage, l’expérience était vraiment enrichissante. Si j’ai le temps, je ferais peut être un court billet sur le sujet courant février.
• Participation aux Coding Dojos du CARA. Je n’y suis allé qu’une fois. Le sujet était le “open/close principle”. Super intéressant, mais pas facile de traverser la ville entre midi et deux pour y aller plus souvent.

Les indicateurs

Bilan très positif donc, espérons que 2012 soit aussi riche. Merci à : Yann, Alex, Claude, Carl et Aline pour leurs commentaires.

The post Rétrospective 2011 appeared first on Agilité, Architecture, C++ "in the mix".

Keynote “Starting An Agile Transition with Why”
par Karl Scotland
Introduit comme une personne qui fait du Lean même quand il fait son jardin, la conférence de Karl recentre la réflexion sur le Why. D’après lui c’est en répondant clairement à cette question que l’on est plus efficace car on a plus de motivation donc plus de succès. Ça m’a rappelé une conférence en 2009 de Marie-Pia Ignace sur l’approche A3. Elle nous avait alors posé la question : pourquoi faite vous de l’agilité ? … Et bien les réponses étaient loin d’être claires

Les tests intégrés sont une arnaque!
par J. B. Rainsberger
En allant à cette conférence j’avais un peu peur car je me demandais ce que j’allais y découvrir. J’en ressors rassuré : « les tests unitaires sont bons car ils mettent la pression sur le design ». Et j’utilise les Mock correctement en validant d’un coté les « expectation » et de l’autre le contrat.
Par contre, J. B. nous explique que les tests intégrés (c’est à dire ceux qui testent plusieurs entités logicielles) nous font rentrer dans une boucle infernale.
Je rentre aussi avec une belle astuce : les tests abstraits pour factoriser le code. Merci!

Démonstration / Kata BDD sur un logiciel pilotant un instrument
Par Matthieu Gironnet et Johanny Bergeron
Belle démonstration de Behaviour Driven Developpement pour la validation d’un driver d’un banc de test chimique. Matthieu joue le rôle du PO et Johanny nous montre comment il implémente les tests à l’aide du framework specflow.

Key note “How to Change the World”
Par Jurgen Appelo
Dans sa keynote Jurgen nous explique que les différents facteurs dans une transition vers l’agilité sont : le système, les individus, les connexions et l’environnement. Ça m’a rappelé quelques bons souvenirs et aussi quelques instants de sudation intense. J’en retiens qu’en tant que vecteur du changement, il ne faut pas partir trop tôt sinon les derniers réfractaires reprennent le pouvoir.

Rétrospectives’lab: décantation
Par Emilie Franchomme
Très belle présentation disponible ici avec beaucoup d’informations. Ça donne envie de lire le livre Agile Retrospective de E. Derby et D. Larsen. Nous n’avons eu droit qu’à une seule question en fin de séance : « En recherchant ainsi constamment le consensus, comment faites-vous lorsqu’il y a clairement besoin de rupture ? ». Pour moi la solution est dans le rôle du facilitateur, qui doit amener l’équipe à réfléchir sur les vrais problèmes… pas facile !

Comment rendre nos entreprises Agile ?
Par Frédéric Dufau-Joël
Fréderic nous explique comment faire des brainstormings géants avec le café découverte ainsi qu’une définition de HOLACRATIE. Ce qui m’a plut c’est la façon dont on pouvais poser des questions (le fishbowl) : l’orateur avait mit 5 chaises en rond au centre de la salle et pour poser une question il fallait venir s’assoir. Ce qui est intéressant c’est qu’on oublie qu’il y a 40 personnes autour qui écoutent : du coup l’échange est beaucoup plus spontané.
Liens : http://www.integralvision.fr, http://www.inandco.com/, http://www.osphere.fr

Conclusion
Cette année les conférences étaient vraiment de très bonne qualité. Il y a juste l’Atelier Neuro Agile de Laurent Bossavit auquel je n’ai pas pu assister. C’est dommage que les conférences ne soient pas filmées : ca permettrait de profiter un peu des sessions que l’on ne peut pas voir.
Merci encore à toute l’équipe d’organisation et aux sponsors pour ce bel évènement !

The post Agile Grenoble 2011 décantation appeared first on Agilité, Architecture, C++ "in the mix".