Situation professionnelle

Freelance
Ouvert aux opportunités

Présentation

Passionné par l'édition logiciel, je souhaite concilier réalisations exceptionnelles, satisfactions des utilisateurs, qualité et plaisir de produire, grâce aux possibilités offertes par les nouvelles technologies, le tout dans un contexte agile.

Visitez mon blog et mes profils, et surtout, n'hésitez pas à me contacter !

A bientôt ...

Xavier blogue un peu ...

Agilité et ingénierie agile - Développement logiciel

https://xnopre.blogspot.com/
Screen Cast #7 : Mise en oeuvre de Mockito en TDD
15 mai 2018
Après avoir vu, dans la précédent vidéo, les utilisations possibles de Mockito pour créer et manipuler des mocks, voici un exemple de mise en oeuvre, en reprenant l'exemple du Driver et du Connector vu dans les précédents épisodes.


Les sources sont sur Github.

N'oubliez pas de réagir, commenter ou questionner !

Merci :-)
Voir l'article
Screen Cast #6 : Mockito, créer et utiliser un mock
03 mai 2018
Dans ce screencast, je vous présente rapidement la librairie Mockito, et je vous montre comment créer un mock, quels sont ses comportements par défaut, comment lui donner des comportements spécifiques, comment vérifier les interactions qui ont eu lieu avec ce mock et comment lui faire déclencher des exceptions.




Les sources sont sur Github.

N'oubliez pas de réagir, commenter ou questionner !

Merci :-)
Voir l'article
Screen Cast #5 : Inversion de contrôle et Injection de dépendance
26 avr. 2018
Dans cet épisode, je vous montre en quoi l'inversion de contrôle (IoC = Inversion of Control) et l'injection de dépendance (DI = Dependency injection) sont indispensables pour avoir une architecture testable, et en comparant avec l'approche "test after", je vous montre comment le TDD nous pousse naturellement vers ce type d'architecture et donc vers du code testable.


Les sources sont sur Github.

N'oubliez pas de réagir, commenter ou questionner !

Merci :-)
Voir l'article
Screen Cast #4 : premier tests unitaires "after" et "TDD"
19 avr. 2018
Dans cet épisode, je vais insister sur un point important qui consiste à partir de l'usage, c'est-à-dire écrire directement commet on aimerait utiliser la classe qui n'existe pas encore.



Précisions :
  • Dans ce screencast, je montre 2 implémentations possibles pour l'API fluent que j'aimerai avoir sur ma classe. A noter que la première solution a d'autres inconvénients, notamment en usage multi-thread, ou si on veut partager la même instance à plusieurs endroits dans le code (et notamment si on utilise une librairie d'injection de dépendances). 
  • A noter également qu'il y a d'autres implémentations possibles que la 2e solution présentée, tout dépend du contexte et des besoins fonctionnels

N'oubliez pas de réagir, commenter ou questionner !

Les sources sont sur Github.

Merci :-)
Voir l'article
Screen Cast #3 : premier tests unitaires "after" et "TDD"
12 avr. 2018
Dans cet épisode, je vous montre un premier exemple de test unitaire "after", c'est-à-dire écrit après le code de production, et le même résultat, ou presque, en approche TDD.


Les sources sont sur Github.

N'oubliez pas de réagir, commenter ou questionner !

Merci :-)

Voir l'article
Human Talks - 10/04/2018 - Tests unitaires et TDD
10 avr. 2018
Ce soir, à la soirée " Human Talks Grenoble ", j'ai proposé une introduction aux tests unitaires et au TDD, voici le diaporama :



Voir l'article
Screen Cast #2 : installation Intellij IDEA et environnement de tests
09 avr. 2018
Dans le précédent article, j'ai montré comment installer Eclipse et un environnement minimal pour écrire et jouer des tests unitaires. Aujourd'hui, je vous propose une nouvelle vidéo pour installer Intellij IDEA et là encore, le configurer pour avoir tout ce qu'il faut pour écrire et jouer des tests unitaires.

Pour l'instant, l'objectif est de permettre aux personnes intéressées par les prochaines vidéos d'avoir un environnement adapté et opérationnel.


N'oubliez pas de réagir, commenter ou questionner !

Merci :-)
Voir l'article
Screen Cast #1 : installation Eclipse et environnement de tests
04 avr. 2018
Je vais essayer de proposer une série de petites vidéos autour du développement logiciel, en abordant des thèmes qui me passionnent comme les tests unitaires, le TDD, le clean code, etc... et qui ne sont pas forcément facile à appréhender et mettre en oeuvre au quotidien dans notre métier.



Le point de départ étant d'avoir un environnement opérationnel, notamment pour écrire et jouer des tests unitaires, je vous propose cette première vidéo pour installer Eclipse et le configurer rapidement pour avoir tout ce qu'il faut pour écrire et jouer des tests unitaires.


La prochaine vidéo présentera l'installation et la configuration d'IntelliJ IDEA, un autre IDE pour avoir le choix, puis nous pourrons aborder les tests unitaires et le TDD !

Mon souhait serait d'avoir quelque chose d'interactif, avec notamment l'opportunité de répondre simplement et précisément à vos questions par de courtes vidéos sur des thèmes ou sujets précis. Alors je compte sur vous pour me laisser vos réactions, suggestions et questions, qui alimenteront le programme des prochains screen-cast !

Merci :-)

[Complément suites aux retours] L'objectif de cette vidéo est de permettre à toutes les personnes intéressées par mes prochaines vidéos d'avoir un environnement minimaliste notamment pour écrire des tests unitaires et les exécuter. Bien sûr, je reviendrai en détails sur chaque dépendance utilisée, et notamment celles indiquées dans cette vidéo !
Voir l'article
Architectures, technos et langages : les choix et leurs conséquences
20 mars 2018
En mission de coaching technique auprès d'une équipe pour les aider à choisir et mettre en place une nouvelle stack complète (back, front, micro-services, base de données, etc...), j'ai été amené à mettre en avant, auprès de cette équipe, les conséquences de nos choix. Je partage mon REX.



La théorie


En théorie, un principe de base et d'être capable de remplacer, dans l'architecture du produit, n'importe quelle brique à n'importe quel moment. On va donc choisir chaque brique de manière à ce qu'elle ait un lien le plus faible possible avec le reste de l'architecture. Comme cela, le jour où cette brique ne fait plus l'affaire, ou qu'on en découvre une meilleure, hop, on remplace ! Cool !

Et comme ce choix n'est pas toujours évident, un autre principe important est de repousser au maximum le moment du choix. Exemple : nous choisirons la base de donnée au moment où nous en aurons besoin. Re-cool !

Quelques constats


Sans détour, autant tout de suite avouer que pour moi, le 1er principe ci-dessus est rarement applicable. Il reste cependant intéressant, et il est donc important de l'avoir en tête, pour repousser la limite le plus loin possible.

Pour donner quelques exemples, il est illusoire d'imaginer :

  • Remplacer sa base SQL par une base No-SQL 
  • Changer le langage de son backend
  • Remplacer son framework de Front par un autre, par exemple Angular par ReactJs
  • etc...

Mon approche : réalisme & pragmatisme


J'essaie d'estimer les contraintes et les implications d'un choix selon 3 niveaux :

  1. La brique pourra être facilement remplacée, à moindre cout, et sans trop d'impact sur le reste de l'architecture, du produit, des utilisateurs, et de l'équipe
  2. La brique pourra ou pourrait être remplacée, avec un cout non négligeable, et peut-être des impacts sur le reste, donc à gérer
  3. La brique ne pourra objectivement pas être remplacée, ou alors avec un cout très important (= ré-écriture d'une partie de l'application), probablement des impacts et risques sur le produit
Quelques exemples rencontrés récemment lors de mon coaching technique.

Backend : niveau 2

Choix : Spring boot et Java (potentiellement Kotlin par la suite)

Notre backend sera essentiellement là pour servir des données en REST, et échanger avec la base de donnée ou des micro-services. L'équipe est expérimentée en Java, peu de chance de partir sur un autre langage totalement différent (NodeJs, PHP, ...). Si nous devions remplacer cette brique, nous pourrions probablement récupérer une bonne partie du code Java, surtout s'il est bien découpée, avec une "incrustation" de Spring la plus limitée possible.

Front : niveau 3

Choix : ReactJs, Sass et ES6

Nous avons fait le choix d'une "RAI" ("Rich Application Interface"), qui n'est en passant pas forcément toujours "le" bon choix, et nous avons retenu ReactJs face à Angular ou VueJs. Il est illusoire de croire qu'on peut remplacer un framework Front facilement par un autre, et développer sa propre couche d'abstraction est une erreur ! Ici encore, il est très important de bien structurer son code JavaScript pour limiter au minimum le code fortement lié au framework. Le reste du code pourra être en grande partie repris, mais tout le code de rendu, lié au framework, devra être ré-écrit.

Concernant Sass, je ne me suis même pas posé la question, tellement son utilisation est une évidence, et tellement il n'y pas d'autres choix actuellement. Idem pour ES6 qui est une évidence, transpilé ou pas.

Base de donnée : niveau 2

Choix : repoussé

Pour l'instant, nous n'en avons pas besoin, donc le choix est repoussé. Néanmoins, ce choix sera impactant, de niveau 2 si nous restons dans la même famille (SQL par exemple).

Build du Front : niveau 1

Choix : Webpack

Builder le front consiste à transpiler le Sass, éventuellement le code ES6, optimiser les images, concaténer et réduire les sources CSS et JS, jouer les tests unitaires, regrouper le tout dans 1 ou quelques fichiers, etc... Ces opérations sont classiques. A ce jour, je ne suis pas un fan de WebPack, un peu trop "boite noire" a mon gout. Par contre, nous étions contraints par le temps, et c'était très rapide à mettre en place pour faire le job. Et décider un jour de ne plus utiliser Webpack a très peu d'impact sur ce que nous aurons produit, il faudra "juste" composer notre usinage plus manuellement et à notre gout.

Tests unitaires du Front : niveau 2

Choix : Jest et Cypher

Le choix de la techno pour les tests unitaires du Front, Javascript et éventuellement les composants, est assez déterminant notamment au niveau de la syntaxe d'écriture des tests, voire des mocks. Par exemple, une série de tests basés sur Mocha+Chai+Sinon nécessite une ré-écriture important, voir totale, pour passer à Jest.

Micro-service : niveau 1

Choix : repoussé

Tout comme la base de donnée, nous n'en avons pas encore besoin, donc le choix technique est repoussé. Quoi qu'il en soit, je le met au niveau 1 car l'idée même d'un micro-service est d'être petit, avec un rôle fonctionnel très précis et limité. Changer de techno pour un micro-service n'est pas un problème car il faudra ré-écrire le micro-service, et ce n'est pas un problème !

Conclusions


  • Même s'il est en partie illusoire, gardez en tête le 1er principe qui permet de faire de meilleurs choix
  • Repoussez les choix au maximum, attendez d'en avoir l'usage et donc une meilleure visibilité sur les contraintes et vos besoins réels
  • Posez-vous la question du "ticket d'entrée" pour tel ou tel choix, quel cout pour l'équipe pour la mise en place et la montée en compétence
  • Découpez correctement votre architecture à tous les niveaux : backend / front / micro-services, mais également au sein de votre code pour isoler les codes liés aux frameworks choisis, et ainsi limiter l'impact d'un éventuellement changement
  • Pour les choix de niveaux 2 et 3, prenez le temps de bien estimer vos besoins et les réponses à ces besoins par telle ou telle solution, en imaginant ne plus jamais pouvoir en changer



Voir l'article
Agile Grenoble 2017
28 nov. 2017

C'est dans mes habitudes, donc cette année encore, j'étais à Agile Grenoble. Mais pour la 10e édition, le format avait changé pour 3 jours "classiques" de conférences et 2 soirées : sacré cuvée !


J'ai eu la chance de présenter 2 sessions. La première, mercredi début d'après-midi, sur le #TDD. Une introduction sur les bases et pourquoi cette pratique, indispensable, est incontournable pour avoir du code testable et testé (1). Ce sujet me tient particulièrement à coeur, car malgré les années, le TDD et les tests unitaires sont encore trop peu répandus ! Et le pire, c'est que c'est souvent par manque de connaissances et compétences, qui peuvent pourtant être assez facilement acquises, à condition de savoir comment s'y prendre et être un peu accompagné, au moins pour bien démarrer... Et évidemment, un peu de live-coding pour montrer le TDD en action, j'adore !


Vendredi matin, j'ai présenté un REX sur mes missions aux startups d'état au SGMAP et à Pôle Emploi. Ce type de REX m'avait souvent été demandé, et effectivement, cela semble intéresser pas mal de monde. Et comme c'est l'agilité qui permet à ces startups de produire des résultats, c'est intéressant d'en parler ! (2)


Plus largement, sur Agile Grenoble, je n'ai pas trop aimé :

  • Le format sur 3 jours, et surtout, la disparition des journées "Université" (mercredi) et "Forum ouvert" (vendredi)
  • Les mots de certains sponsors qui, probablement, pour faire différemment et se faire remarquer (?) font, à mon goût, n'importe quoi... :-(
  • Et quelques autres bricoles...


Mais par contre, j'ai aimé :

  • La keynote de Aurélien MORVANT : "Etes vous prêt pour le grand saut ?" avec de bonnes réflexions autour du changement, du droit au changement, des réticences, etc...
  • La keynote de Stéphane BIGEARD : "Succès - Echec : Ce que je regarde se développe" qui m'a fortement interpellé par son approche par la valorisation des points forts (en tant que parents, managers, équipiers, ...)
  • La "Sensibilisation au Software Craftsmanshift" de Nastasia Saby 
  • L'excellent session "Bug Free, By Design" de Johan Martinsson, toujours aussi enrichissant avec une salle plus que pleine !
  • Les soirées (propices aux ateliers et jeux) même si j'ai zappé la première 
  • Les Shifumis ("Pierre-papier-ciseaux") géants vu d'en haut
  • Rater plein de sessions pour discuter avec des copains ou de nouvelles connaissances
  • Et plein d'autres choses !...
Un grand merci aux organisateurs, aux femmes et aux hommes en rouge !



(1) TDD : les slides et les sources
(2) Startups d'état : les slides

Voir l'article
Agile Grenoble 2015 : atelier l'agilité de l'intérieur
23 nov. 2015

Ce jeudi 19 novembre avait lieu Agile Grenoble 2015. Avec Laurent Tardif et quelques autres personnes, nous avons animé toute la journée un atelier "L'agilité de l’intérieur". Voici sur mon retour sur cette expérimentation !

Historique


Le 8 octobre 2015, je vois passer un tweet de Laurent :


Passionné par le développement, le craftman, et l'agilité, je prends tout de suite contact avec Laurent. Il m'en dit un peu plus, le projet est effectivement un peu fou, mais je suis très motivé par cette expérience, alors je m'implique immédiatement, nous n'avons que quelques semaines pour préparer l'atelier !

L'idée


L'idée est simple : pendant Agile Grenoble, tout au long de la journée, développer un projet en mode Agile/Scrum pour permettre aux participants de la conférence (plus de 540 personnes) de voir comment se déroule un projet agile.

Le sujet


Laurent est fan de nouvelles technos, de devops et de bigdata. Il a donc une idée : aspirer les tweets #AG15 avec Flink, et générer un nuage de mots dans une page Web.

Objectif(s)


D'après moi, le piège d'un tel atelier est d'avoir trop d'objectifs : montrer l'agilité en action, faire participer les gens, et notamment les développeurs présents à la conf, avoir des feedbacks de tous les participants à la conférence, montrer des technos modernes et sympas, montrer les bonnes pratiques et l'excellence technique, etc...

J'ai partagé avec Laurent mon retour d'expérience sur un atelier similaire que j'avais vu à Mix-IT, et qui à mon avis n'avait pas trop marché, en tout cas, en tant que développeur, j'étais passé 5' voir les gars et je n'avais pas osé ou trouvé le moyen de contribuer.

Nous nous sommes donc donné comme principal objectif de montrer l'agilité, en espérant que du monde vienne voir, observer, et poser des questions. Nous savions que le Product Owner et le Scrum Master serait probablement moins occupés que les développeurs, et qu'ils pourraient donc assurer l'accueil des visiteurs et réponses à leurs questions.

Nous avons tout mis en oeuvre pour permettre l'intégration de développeurs motivés, mais sans compter dessus, donc en s'assurant d'avoir un minimum de ressources dans la journée (merci les copains !).

Quelques biais


L'atelier est expérimental, l'objectif est ambitieux, nous devons prendre quelques biais, et faire quelques concession. Les cérémonies doivent être rapides et animées oralement, pas le temps de mettre en oeuvre des atelier ou supports, par exemple pour les rétrospectives. Le produit est un POC (Proof Of Concept), tout comme l'atelier d'ailleurs, et le produit sera éphémère et jeté le soir même, la qualité et notamment les tests automatisés ne sont pas prioritaires. Et côté outillage et devops, nous faisons au plus facile (différent du plus "simple") : le serveur BackEnd sera celui de développement présent sur l'atelier, et l'application sera déployée par un simple "rsync" entre mon poste et le serveur Web.

Déroulement


Arrivés dès 8h, nous avons installé notre atelier dans le coin qu'on nous avait réservé dans l'Atrium, le grand hall principal de la conférence : tables en ilot pour développer, 1 poste pour vidéo-projeter le résultat, 1 poste pour développer le BackEnd, 1 ou 2 postes pour développer le FrontEnd, 1 tableau blanc avec post-its pour les retours utilisateurs, le backlog et ses "User stories", etc... L'installation prend du temps, mais nous sommes prêts à accueillir les visiteurs à l'heure des premières sessions après la keynote.




Itération 1 : les premiers pas


Nous expliquons le contexte et le projet aux personnes présentes. Le product Owner nous présente les histoires qu'il a imaginé et nous échangeons. Nous en retenons 2 pour commencer :

  • BackEnd : aspirer les tweets (nous avons déjà une base) et générer un fichier avec les noms des twittos
  • FrontEnd : afficher un nuage de points "en dur"

C'est parti, nous avons 30' pour livrer quelque chose pour les prochains changements de sessions de la conférence. C'est très court, nous rencontrons évidemment des problèmes techniques, mais heureusement, nous avions quelques billes de côté et nous pouvons livrer un premier nuage de mots pas très beau, codé en PHP, et basé sur un fichier texte en dur.

Itération 2 : pression


Comme prévu, nous commençons par une rétrospective qui fait ressortir que tout le monde est content, satisfait, s'amuse, mais... que ça va très très vite et qu'il faut vraiment travailler en "baby baby steps" ! Donc des histoires vraiment très petites et progressives !

Pour l'itération 2, nous nous engageons donc pour un affichage plus joli du nuage de mots, basé sur l'exploitation d'un fichier généré par le BackEnd, contenant les noms des twittos avec un poids en fonction de leurs nombres de tweets, quitte à pousser manuellement ce fichier sur le serveur Web. Malgré de nouvelles difficultés techniques, ainsi que des perturbations importantes subies par l'équipe, l'objectif est atteint de justesse, et nous finissions la matinée avec le résultat attendu :-)



Pause déjeuner : plaisir


Nous commençons tout juste à bien rentrer dans le projet, à produire quelque chose de sympa, l'excitation est telle que le repas est rapidement avalé et qu'on se remet à coder en "off" :-), comme cela peut arriver dans la vraie vie, lorsqu'on arrive à composer une équipe soudée et motivée sur un chouette projet ! ....

Itération 3 : pression toujours...


Nous attaquons le "sprint planning" (réunion de planification de l'itération à venir) par une nouvelle info des Product Owner : vers 13h30, nous aurons un créneau de 5' pour présenter notre atelier et notre produit en amphi, aux 540 participants ! Ouch....... La pression monte, mais l'excitation également : GO GO !!

Pour cette itération, les Product Owner nous demandent de peaufiner l'affichage et d'ajouter en haut de page le nombre de tweets collectés. Objectif raisonnable, on s'engage, et 3/4h plus tard, nous sommes sur l'estrade de l'amphi pour la présentation, yeah ! :


Pour l'anecdote, la présentation des mots est aléatoire (position, inclinaison), donc le résultat est différent d'un affichage à l'autre. De plus, juste avant de livrer cette version, j'ai pas mal tweeté pour tester. D'où la présence de mon nom bien visible sur le nuage présenté en amphi, je ne m'en suis pas rendu compte sur le coup, et ça n'était pas truqué, mais nous sommes des devs qui testons notre appli ! ;-)

Itération 4 : on s'éclate !


Après l'euphorie de notre présentation en amphi qui s'est bien déroulée, nous attaquons une nouvelle itération. Nouvelles demandes des Product Owner : alterner l'affichage entre les noms des twittos et les mots les plus twittés. Encore une fois, l'objectif sera atteint, mais avec un résultat logique mais que personne n'avait anticipé : nous obtenons un nuage avec des dizaines de mots, écrits tout petits et illisibles, sauf 1 qui est en gros au milieu du nuage..... #AG15 !! Evidemment, c'est le mot le plus twitté ! Nous en tirons les conséquence pour l'itération suivante : il faut filtrer ce mot, ainsi que d'autres non significatifs.

Itération 5 : encore du plaisir !


Nous finissions la journée avec une 5e itération en mode beaucoup plus cool, le plaisir prend le dessus sur la pression, tout le monde sent que l'objectif est atteint, aussi bien celui de l'application qui tourne bien et est visible en grand sur le mur, mais également l'objectif de l'atelier !


Conclusion sur l'atelier


Au final, après une journée très intense, mais riche en rencontres et en découvertes, l'objectif est atteint. Sur la journée, nous estimons avoir eu environ 50 personnes qui sont passées nous voir, et qui ont participé en posant des questions ou en donnant un coup de main pour coder une itération.

Nous avons eu tous les profils (Product Owner, Scrum Master, développeuses et développeurs, managers, ...) et tous les niveaux (grands débutants, pratiquants, ...).

Quelques moments m'ont particulièrement marqué et m'ont amené à me dire qu'un tel atelier avait sa place :

  • A la première itération, en plus de notre Product Owner de départ, nous en avions 7 autres : 7 personnes venues voir en quoi consiste le rôle de PO, comment se déroule un projet agile, une itération, une planification d'itération, les échanges entre PO et devs pour être sûr de bien se comprendre, comment tester et voir ce que ça donne sans trop anticiper, etc... Et toutes ces personnes ont pu profiter du déroulement des itérations pour tranquillement échanger et questionner notre PO et notre SM, qui du coup ont été moins disponibles pour l'équipe ;-)
  • Deux personnes sont arrivées pour la 2e itération, elles sortaient de la session "L'agilité pour les nuls" et dans les échanges que j'ai pu avoir avec elles, je me suis rendu compte à quel point c'était un excellent enchainement dans leur programme pour découvrir l'agilité
  • A l'itération 4, nous avons implémenté le nuage des mots les plus twittés, et tout le monde a été surpris, mais finalement pas étonné, de voir sortir en gros "#AG15" : l'agilité est également là, essayer, tester, voir ce que ça donne, ne pas anticiper, et être capable de rapidement s'adapter
  • ...


Certains choses ont peu ou pas marché :

  • A mon avis, l'application en ligne a été beaucoup moins visitée que nous le pensions
  • Le tableau de feedbacks des utilisateurs n'a reçu aucun post-its
  • Le "concours" du meilleur twittos a peu fonctionné, à part pour certains, ils se reconnaitront... ;-)

Mais globalement, cet atelier s'est très bien déroulé, probablement mieux que je ne m'y attendais, et ce fut un grand succès. En plus, nous avons pu noter plein de points d'améliorations pour que cet atelier soit encore plus performant, accueillant, didactique, etc... Que demander de plus ? :-)

Conclusion sur mon Agile Grenoble 2015


Depuis des années, je participe à Agile Grenoble, en tant qu'orateur, ou en tant que simple visiteur. Cette année, j'ai vu la conférence sous un autre angle, très différent des 2 premiers. J'ai passé ma journée à l'atelier, je n'ai vu aucune keynote et quasiment aucune "surprise" (si quelqu'un a filmé l'impro et les post-its, je suis preneur !!!), j'ai fini la journée épuisé, mais quel plaisir, quel bonheur, aussi bien de coder en live une application tout de même bien sympa en si peu de temps, de faire du pair-programming avec des bons copains ou des inconnus, de renseigner les visiteurs sur l'agilité, Scrum, l'état d'esprit agile, l'organisation, les façons de faire, etc...

Une grand merci à Laurent pour son initiative, aux personnes impliquées dans la préparation de cet atelier, à l'équipe d'orga qui nous a permis de tenter cette expérience, et bien sûr, à toutes celles et ceux qui sont passés nous voir, nous questionner, nous aider, nous perturber, nous encourager, ... MERCI !!


Crédits photo : Alex, Fred, Franck et moi
Voir l'article
Un proto d'appli Web en moins de 2 jours grâce à AngularJS
18 nov. 2015

Retour d'expérience et pourquoi j'ai pu réaliser un prototype d'application Web en 2 jours grâce à AngularJS et un peu d'outillage.

Le code source "exemple" (légèrement remanié et simplifié par rapport à l'original) est en ligne :
https://github.com/xnopre/proto-with-angular

Contexte

Début octobre, j'ai attaqué une nouvelle mission au sein d'une startup d'état au SGMAP à Paris. Je dois développer une application Web pour fournir aux personnes qui vont partir en retraite, une liste planifiée des démarches qu'elles doivent effectuer. L'application doit se composer d'une succession de 4-5 écrans permettant à l'utilisateur de saisir quelques informations, de répondre à quelques questions, puis de consulter la liste des démarches à effectuer.

Le groupe de travail du projet se regroupe toutes les 2 semaines, et il fallait rapidement leur montrer un prototype de l'application Web pour qu'ils puissent mieux se rendre compte de ce à quoi l'application pourrait ressembler.

J'avais donc 3 jours pour produire un prototype !

Les besoins, les contraintes et les concessions

J'ai commencé par recenser les besoins, et notamment de montrer au groupe de travail comment pourraient se passer les points suivants :

  • Enchainements des différents écrans
  • Saisie de données de l'utilisateur (étape 1) 
  • Poser des questions simples comme le choix du régime (étape 2)
  • Afficher certaines questions selon les réponses à d'autres questions (étape 4)
  • Présentation des résultats de la dernière étape, avec un découpage en chapitre ayant chacun un numéro, un titre, une échéance, et la possibilité "d'ouvrir" le chapitre pour consulter son contenu

J'ai rapidement évalué que je n'avais pas forcément besoin d'un véritable serveur (au sens applicatif, comme par exemple Play! ou NodeJS), ni d'une base de données. Les données des différentes écrans pouvaient être en dur, et le proto jetable.

Solution initiale : des pages statiques

La première solution retenue était de faire des pages statiques, avec textes et liens en dur. Mais finalement, très rapidement les contraintes sont apparues, et instinctivement, je me suis dis que je gagnerai du temps en faisant une "Single Page Application" (SPA) avec AngularJS.

Solution finale : AngularJS

Je vais essayer de synthétiser en quoi AngularJS m'a fait gagner du temps.

Pas besoin de serveur d'application

Avec Grunt, et la commande "Grunt serve", un serveur NodeJS est lancé sur le port 9100, la page de mon application est automatiquement ouverte dans mon navigateur, et puisque je suis en "live reload", dès que j'enregistre des changements dans mon éditeur (j'aime bien Brackets pour les applis JavaScript et Angular), la page en cours est rechargée automatiquement dans le navigateur : très productif !

A noter également que l'opération "grunt serve" (tout comme un "grunt build", non configuré dans le proto), grâce à la tâche "injector", permet d'injecter automatiquement dans le fichier "index.html" tous les fichiers CSS et JS, issues dans dépendances Bower, mais également créées dans l'architecture de l'application. Ainsi, les sections suivantes (entre les "injector" et "endinjector") sont automatiquement remplies et mises à jour :

<!doctype html>
<html lang="fr">

<head>

...

<!-- injector:bowercss -->
<link rel="stylesheet" href="lib/bootstrap-css-only/css/bootstrap.css">
<link rel="stylesheet" href="lib/textAngular/src/textAngular.css">
<!-- endinjector -->

<!-- injector:css -->
<link rel="stylesheet" href="css/main.css">
<!-- endinjector -->
</head>

<body ng-app="Proto" >

...

<!-- injector:bowerjs -->
<script src="lib/jquery/dist/jquery.js"></script>
<script src="lib/bootstrap/dist/js/bootstrap.js"></script>
<script src="lib/angular/angular.js"></script>
<script src="lib/angular-resource/angular-resource.js"></script>
<script src="lib/angular-cookies/angular-cookies.js"></script>
<script src="lib/angular-animate/angular-animate.js"></script>
<script src="lib/angular-touch/angular-touch.js"></script>
<script src="lib/angular-sanitize/angular-sanitize.js"></script>
<script src="lib/angular-bootstrap/ui-bootstrap-tpls.js"></script>
<script src="lib/angular-ui-utils/ui-utils.js"></script>
<script src="lib/angular-ui-router/release/angular-ui-router.js"></script>
<script src="lib/rangy/rangy-core.js"></script>
<script src="lib/rangy/rangy-classapplier.js"></script>
<script src="lib/rangy/rangy-highlighter.js"></script>
<script src="lib/rangy/rangy-selectionsaverestore.js"></script>
<script src="lib/rangy/rangy-serializer.js"></script>
<script src="lib/rangy/rangy-textrange.js"></script>
<script src="lib/textAngular/src/textAngular.js"></script>
<script src="lib/textAngular/src/textAngular-sanitize.js"></script>
<script src="lib/textAngular/src/textAngularSetup.js"></script>
<script src="lib/angular-mocks/angular-mocks.js"></script>
<!-- endinjector -->

<!-- injector:js -->
<script src="js/app.js"></script>
<script src="js/app.module.config.js"></script>
<script src="js/main-controller.js"></script>
<!-- endinjector -->

</body>
</html>


Et la configuration de la tâche "injector" pour Grunt est la suivante :

        injector: {
options: {
addRootSlash: false,
ignorePath: 'app/',
bowerPrefix: 'bower',
},
localDependencies: {
files: {
'app/index.html': [
'app/js/**/*.js',
'app/css/{,*/}*.css'
]
}
},
bowerDependencies: {
files: {
'app/index.html': ['bower.json'],
}
}
},

Moins d'HTML

Avec une SPA, j'ai simplement besoin d'un fichier index.html pour le cadre général, puis de petits morceaux d'HTML pour chaque page ("templates").

Le module 'Proto'

La déclaration du module applicatif Angular est très simple :
'use strict';

angular.module('Proto', [
'ui.bootstrap',
'ui.router',
'ngSanitize'
]);

Il faut alors indiquer avec l'attribut "ng-app" dans la page principale index.html qu'on veut utiliser ce module :

    <body ng-app="Proto">


Et toujours dans cette page, indiquer avec "ui-view" l'endroit où doivent être insérés les templates de chaque vue :

    <div class="container">
<div ui-view="">
</div>
</div>


Le routage

Pour le routage avec AngularJS, j'aime bien ui-router qui permet de travailler avec des "états". Pour mon proto, je déclare donc 5 états avec pour chacun : son nom, son URL, son template HTML, et le même controller pour tous les états, je ne fais pas comme cela dans la "vraie vie", mais dans le cas présent, ça me suffit et me simplifie le code :

'use strict';

angular.module('Proto').config(function ($urlRouterProvider, $stateProvider) {

$urlRouterProvider
.otherwise("/step1");

$stateProvider
.state ('step1', {
url:'/step1',
templateUrl: 'views/step1.html',
controller: 'MainCtrl'
})
.state ('step2', {
url:'/step2',
templateUrl: 'views/step2.html',
controller: 'MainCtrl'
})
.state ('step3', {
url:'/step3',
templateUrl: 'views/step3.html',
controller: 'MainCtrl'
})
.state ('step4', {
url:'/step4',
templateUrl: 'views/step4.html',
controller: 'MainCtrl'
})
.state ('step5', {
url:'/step5',
templateUrl: 'views/step5.html',
controller: 'MainCtrl'
});

});


Enchainement des écrans

Dans chaque écran (step1.html, step2.html, ...), je mets un formulaire "form", avec en bas, un bouton "Etape suivante" de type "submit", et j'indique à AngularJS que lors de la soumission du formulaire, je veux exécuter la fonction "nextStep()" :

<form ng-submit="nextStep()">

...

<input class="btn btn-success" type="submit" value="Etape suivante" />

</form>

Comme je suis fainéant, et que les états se suivent (1, 2, 3...), j'ajoute le numéro de "step" dans chaque état du routage :

    $stateProvider
.state ('step1', {
url:'/step1',
step: 1,
templateUrl: 'views/step1.html',
controller: 'MainCtrl'
})
.state ('step2', {
url:'/step2',
step: 2,
templateUrl: 'views/step2.html',
controller: 'MainCtrl'
})
...
});

Il suffit alors d'ajouter la fonction "nextStep()" dans le $scope du controller, cette fonction récupère l'état courant (ex : step2), ajoute 1 à son numéro, et demande au routeur de naviguer vers le nouvel état (ex : step3) :

'use strict';

angular.module('Proto').controller('MainCtrl', function ($scope, $state) {

...

$scope.nextStep = function() {
var currentStep = $state.current;
$state.go('step'+(currentStep.step+1));
};

...

});

Par la suite, j'ai facilement ajouté des boutons "Etape précédente" en appelant une fonction "prevStep()" qui exécute la navigation vers "step - 1".

Données pour chaque écran

Dans les étapes 1 et 3, j'ai des listes déroulantes pour choisir des dates (jour, mois, année). Toujours comme je suis fainéant, et pour ne pas copier-coller des tas de ligne "<option>", je remplis ces listes dans le contrôleur :

    $scope.listeAnneesNaissance = [];
for(var i = 1945; i < 2015; i++) {
$scope.listeAnneesNaissance.push(i);
}

$scope.listeAnneesDepart = [];
for(var i = 0; i < 10; i++) {
$scope.listeAnneesDepart.push(2015+i);
}

$scope.listeMois =['Janvier','Février','Mars','Avril','Mai','Juin','Juillet','Août','Septembre','Octobre','Novembre','Décembre'];


et je les utilise dans les pages avec des "ng-repeat" sur les "option" :

            <select name='naissance.mois' class='form-control proto-select' required >
<option ng-repeat='mois in listeMois'>{{mois}}</option>
</select>
<select name='naissance.annee' class='form-control proto-select' required >
<option ng-repeat='annee in listeAnneesNaissance'>{{annee}}</option>
</select>

De même, j'avais besoin de liste de régimes ("caisses") pour l'étape 2, et d'une checklist et son contenu à afficher à l'étape 5. J'ai donc créé des structures de données dans le contrôleur :

    $scope.caisses = [
{
nom: "MSA",
description: "Exploitants et salariés agricoles"
},{
nom: "CNAV",
description: "Régime général",
details: [
"Salariés de l'industrie, du commerce et des services",
"Agents non titulaires de l'Etat et des collectivités publiques",
"Artistes et auteurs d'oeuvres originales"
]
},{
nom: "Je ne sais pas"
}
];

$scope.checkList = [
{
titre: "Je reconstitue ma carrière",
delai: "Dès aujourd'hui",
infos: "Avez-vous déjà vérifié que les données de votre relevé de situation individuelle sont exactes et complètes ? Si oui, passez à l’étape suivante. Sinon, suivez les étapes ci-dessous",
actions: [
"Je crée mon espace privé sur le site Internet de ma caisse MSA pour avoir accès aux services en ligne personnalisés ICI.",
"Dans mon espace privé « Mon compte », je choisis « Internet » comme préférence de mode de réception des documents et des informations de mon dossier personnel.",
"Dans mon espace privé, je consulte mon relevé de situation individuelle.",
"Je vérifie que les données de mon relevé de situation individuelle sont exactes et complètes.",
"Si j’identifie des périodes manquantes ou informations erronées, je demande une régularisation de ma carrière en envoyant par courrier ou en déposant à mon agence les pièces justificatives correspondantes."
],
precisions: [
"Je peux à tout moment adresser mes questions par mail à mon conseiller depuis mon espace privé."
]
},{
titre: "Je contacte mon / mes régime(s) complémentaire(s)",
delai: "Dès que possible",
infos: "Nous avons détecté que vous dépendez pour votre retraite complémentaire de [XXX] . Vous devez effectuer une demande distincte auprès de ce régime.",
actions: [
"Je prends contact avec mon/mes régimes de retraite complémentaire ICI afficher les coordonnées des régimes concernés telles qu’extraites de l’annuaire retraite.",
"Je note ci-dessous les démarches à effectuer pour obtenir ma retraite complémentaire."
]
},{
...


Ensuite, j'utilise simplement ces données dans chaque page, avec là encore des "ng-repeat" sur différents éléments HTML imbriqués.

J'avais pressenti que pendant ces 2-3 jours de préparation du proto avec le Product Owner, ces données allaient changer, mais également les façons de les présenter. Ca n'a pas raté, et j'étais bien content de ne pas avoir dupliqué des paquets de "div" HTML, mais d'avoir un "ng-repeat" sur un "div", et donc de n'avoir que ce "div" à modifier... :-)

Les animations

A l'étape 4, on pose quelques questions complémentaires à l'utilisateur, et certaines questions doivent apparaitre selon les réponses à la question précédent.

Pour cela, avec AngularJS, c'est très simple sans code. Les boutons radio pour les réponses sont classiques, et j'utilise "ng-model" pour stocker "false" ou "true" dans la variable "inactivite" qui sera automatiquement créée dans le scope (pas besoin de la déclarer explicitement) :

    ...
<input ng-model="inactivite" type="radio" value="false" name="inactivite" />
    ...
<input ng-model="inactivite" type="radio" value="true" name="inactivite" />
    ...


Et ensuite, le "div" suivant est complété avec un attribut "ng-show" pour afficher le "div" si la variable "inactivite" a la valeur "true" :

    ...
<div ng-show="inactivite === 'true'">
...

Aussi simple que cela !

Conclusion

Après moins de 2 jours de travail, y compris un peu de CSS non mentionné ici, je disposais d'un prototype qui répondait aux attentes, qui présentait l'enchainement des écrans, des données fictives et quelques animations. Ce prototype a permis un premier travail d'échanges avec le Product Owner, qui a demandé quelques changements. Et dès le lendemain, nous avons pu le présenter au groupe de travail qui a tout de suite pu se projeter plus concrètement dans l'outil imaginé depuis plusieurs réunions de préparation du projet.

C'est après ces 3-4 jours de prototypage et démonstration, et avec un peu de recul, que je me suis vraiment rendu compte que c'est grâce à AngularJS que j'avais pû produire un tel résultat en si peu de temps, et je voulais partager ce retour d'expérience.

A noter que dans les semaines qui ont suivi, ce prototype a fait émerger l'idée de développer un BackOffice pour permettre au Product Owner et aux personnes du métier de configurer en ligne les règles métier de l'application et ses contenus. Et ce BackOffice a été développé avec AngularJS.

Par contre, en parallèle, les développements ont également avancé sur l'application destinée aux usagers, le FrontOffice, mais finalement (pour d'autres raisons, notamment de tests) en mode "classique", avec des pages HTML servies par un serveur Play Framework, et donc sans AngularJS...
Voir l'article
Laissez l'équipe faire ses choix techniques !
16 mars 2015

Introduction


Ce que j'aime bien dans l'agilité, c'est le côté "bons sens" et pragmatique. Et ce que j'aime particulièrement dans Scrum, c'est le nombre limité de rôles, et la précision du périmètre de responsabilité pour chacun de ces rôles. Voir mon précédent article "Scrum : quel est le rôle le plus important ?".

Pour un projet de développement logiciel, les équipiers sont essentiellement des développeurs. Tout comme le Product Owner a la responsabilité de la partie fonctionnelle (quelles fonctionnalités et pour quand ?), les équipiers ont la responsabilité de tout ce qui est technique : choix des technologies, choix de l'architecture de l'application, règles communes de codage, qualités, innovation, etc ...



Qu'est-ce que j'entends par "Innovation" ?


Nous sommes dans un métier d'artisanat, nous faisons rarement 2 fois la même chose, et l'éco-système bouge très vite, il y a très souvent des nouvelles technos intéressantes, de nouveaux langages, de nouvelles méthodes ou façon de développer, etc ... 

Donc par "innovation", j'entends tout ce qui va permettre de faire du développement moderne, non pas pour être à la mode, mais pour mieux répondre aux besoins en profitant au mieux des nouveautés. Il y a donc bien sûr les nouveaux outils et les nouveaux frameworks. Mais il y a également les changements (nouveautés ou remises en questions) sur la façon d'écrire le code, le commenter ou pas, le présenter, l'organiser, l'architecturer, etc ... Cela porte donc sur des choix structurant pour l'ensemble du projet (choix d'architecture par exemple), mais également sur les choix quotidiens du développeur pour écrire son code, comme par exemple mettre en place une API fluent parce que le code sera plus lisible et bien plus facile à utiliser pour les successeurs !

Innover ou pas ? 


J'observe que la question est souvent posée, et parmi les réfractaires, on peut trouver des managers et des développeurs.

De mon point de vue, les managers devraient pousser plus à l'innovation. Mais il y a malheureusement plusieurs raisons pour qu'ils ne le fassent pas. Par exemple, ils peuvent avoir peur que cette innovation soit excessive par rapport aux besoins et aux contraintes du projet. Ou encore, ils ont un manque de compétences pour en juger.

Et d'un autre côté, certains développeurs sont eux aussi septiques par rapport à l'innovation, mais c'est souvent par peur de l'inconnu en sortant de leur zone de confort.

Pour ma part, c'est évident, il faut innover en permanence. Nous sommes dans un métier qui bouge en permanence, tant du point de vue outils que méthodes, il est important que les développeurs suivent un minimum les évolutions, à la fois pour produire des logiciels modernes, et également pour entretenir leur employabilité !

Mais bien sûr, cette innovation doit être dosée et maitrisée. Il ne faut pas être excessif et se jeter en permanence sur les nouvelles technos à la mode. De même, il me semble très dangereux de faire cohabiter, au sein d'un même produit, plusieurs librairies qui rendent le même service. Idéalement, l'architecture doit permettre, si besoin, de remplacer une librairie par une autre, s'il y a réellement un intérêt.

Une erreur : l'innovation par certains !


Parmi les erreurs que j'ai pu observer ou vivre, il y a la solution de confier l'innovation à une personne (ou un groupe de personnes). Pour un manager, c'est rassurant, certes. Mais les effets négatifs sont nombreux.

Déjà, cette solution est très frustrante et démotivante pour l'ensemble de l'équipe. Bon nombre de développeurs sont intéressés pour chercher et tester de nouvelles technos. Et s'ils ne le sont pas, il faut les y inciter, car cela fait partie de notre métier.

Par ailleurs, cette approche limite l'innovation, puisqu'elle est confiée aux idées et aux visions d'une seule personne.

Et enfin, cette façon de faire limite énormément l'implication de l'équipe pour l'intégration de ces nouvelles technologies, induisant prise de distance et démotivation.

Une autre erreur : la validation par tous !


Parmi les profils de développeurs, il y a ceux qui sont plus dans "la production" et ceux qui sont plus dans "l'apprentissage" (j'essaierai de publier un article à ce sujet). Je ne suis pas sûr que ces profils puissent travailler ensemble au sein d'une même équipe "projet" (i.e. travaillant ensemble sur un projet). Mais ces profils cohabitent au sein de tout service développement logiciel, et cela peut être une réelle et importante difficulté à gérer pour les managers.

Mais pour revenir à l'innovation, une erreur me semble-t-il, est de faire valider toutes les innovations par l'ensemble des développeurs d'un même service. En faisant cela, on met en dualité les 2 types de profils précédent, pour lesquels il ne peut pas y avoir de consensus. Soumettre l'adoption d'une innovation à l'approbation générale a comme seule issue de limiter cette innovation, puisque les profils les plus "conservateurs" ou "craintifs", refuseront toutes innovations.

Le premier effet est donc une innovation extrêmement limitée.

Le second est un désengagement et un découragement de ceux qui sont dans "l'apprentissage" et qui pourraient pousser ces innovations indispensables. Le service de développement logiciel n'évolue pas, et en quelques années, il est dépassé et produit des logiciels d'un autre temps. Dommage...

Conclusion


Chaque développeur est un artisan, qui doit être passionné par son métier, et qui a la responsabilité d'innover régulièrement.

Et chaque manager doit avoir conscience de cette nécessité, de l'aspect indispensable de l'innovation, sans excès et maitrisée, il doit donc laisser une marge de manoeuvre aux développeurs pour cette innovation, il doit leur faire confiance pour les choix d'innovation qu'ils feront pour le projet en cours, il doit inciter tous les membres de l'équipe vers cette innovation, et il doit accompagner les "conservateurs" pour que ces derniers puissent comprendre les enjeux, dépasser leurs craintes et sortir de leur zone de confort.






Voir l'article
Scrum : quel est le rôle le plus important ?
19 janv. 2015

Introduction


Pour l'organisation agile d’un projet de développement logiciel, Scrum propose un cadre simple et précis, avec notamment 3 rôles, ni plus ni moins :

  • Scrum Master
  • Product Owner
  • Equipier

Ces derniers mois, à plusieurs reprises, je me suis posé la question de savoir lequel de ces rôles était le plus important, voici mes éléments de reflexion.


Le « ScrumMaster » est le rôle le plus important


Je pratique l’agilité depuis des années, et quasiment depuis le début, j’ai estimé que le rôle du ScrumMaster était le plus important. En effet, c’est grâce à ce « facilitateur », ni fonctionnel, ni technique, que l’approche agile peut être bien mise en place et garantir le succès de l’agilité.

Le ScrumMaster a un rôle primordial en s’assurant que chacun des acteurs respecte bien le sien, en protégeant l’équipe des interférences extérieures, en la guidant dans ces choix de priorités, d’optimisation de la valeur produite, de solutions techniques et d’architecture, etc …

Mais le ScrumMaster a également un rôle très important, et souvent difficile, sur les aspects humains, pour fédérer l’équipe, en l’aidant à exprimer ses difficultés et trouver les meilleures solutions, pour atteindre l’efficacité maximum.

Le rôle de ScrumMaster est donc très important pour garantir la bonne mise en oeuvre de l’agilité et sa réussite.

« ProductOwner », un rôle encore plus important ?


Dans mon cheminement de découverte de l’agilité, par la suite, j’ai mieux compris le rôle du Product Owner, le « responsable du produit ». Cet acteur maitrise le métier, les besoins des utilisateurs, leurs attentes, et comment y répondre au mieux. Il a une vision d’ensemble sur le projet, le planning, les étapes clés, les contraintes, et les contextes (vision d’entreprise, budget, autres projets, …).

Il n’a pas de compétences techniques, idéalement, il a des notions pour comprendre certains choix ou contexte, en oubliant le reste. Il se polarise donc entièrement sur le fonctionnel, pour optimiser la valeur produite par l’équipe, en priorisant les histoires du backlog, et en les rédigeant au mieux (précisions, exemples, critères d’acceptation).

Il est en contact avec l’extérieur de l’équipe (clients, utilisateurs, managers, autres équipes, …). Il s’assure de bien capturer les besoins des utilisateurs, de présenter au mieux le contexte à l’équipe, et il est en charge de transmettre les informations relatives au projet : avancement, difficultés éventuels, planning prévisionnel remis à jour régulièrement, etc …

Le rôle du Product Owner est donc très important pour garantir de faire le bon produit, avec le meilleur budget, et dans les meilleurs délais possibles.

Mais finalement, le rôle d’ « Equipier » est primordial !?


Je trouve que les équipiers sont souvent négligés, ou sous-estimés, voire dénigrés. Et pourtant, ce sont eux les « faiseurs ». Sans cette force vive de réalisation, le produit n’existerait pas. Ils sont donc au coeur du projet, au service du produit, mais à la servitude de personne.

Pour un projet de développement logiciel, les équipiers sont le plus souvent des développeurs qui doivent avoir toute latitude dans leur organisation et leurs choix technique, l’équipe est auto-organisée.

Pour une itération, l’équipe prend un engagement sur un ensemble de fonctionnalités qu’elle va implémenter au cours de cette itération. Elle est donc engagée sur le « quoi », et fait les choix qui lui semble bons sur le « comment », du moment qu’elle atteint son objectif.

Personne en dehors de l’équipe ne peut juger ou commenter les choix suivants dont seuls les équipiers ont la responsabilité :

  • traiter les histoires dans l’ordre du backlog ou pas, 
  • faire du pair-programming ou du dojo à plusieurs, 
  • investir du temps pour refactorer des parties du logiciel ou innover (tant que c’est au service du produit), 
  • etc …

En contre-partie, les développeurs ont la charge et la responsabilité de la qualité, sous tous ses aspects : logiciel sans défaut et maintenable, architecture évolutive, code propre et lisible, outillage performant, etc …

Le rôle d’Equipier est donc très important pour que le logiciel soit produit, et qu’il soit bien réalisé, en toute qualité.

Conclusion


Vous l’avez compris, finalement, chacun des rôles proposé par Scrum a son importance, et il est primordial que chaque rôle soit bien compris et bien respecté.

En résumé, le Product Owner est en charge de tous les aspects fonctionnels (le « quoi »), les équipiers sont en charge de tous les aspects techniques (le « comment »), et le Scrum Master est là pour que « tout roule », pour que l’équipe soit efficace, productive, créative et en permanente amélioration continue.

Personnellement, dans une époque du « no-ceci », « no-cela », je me rapproche de plus en plus des fondamentaux de l’agilité, et dans la mise en oeuvre précise de Scrum.

Et vous ? Quel est votre vision sur les rôles de Scrum ?
Voir l'article
Calendrier niko-niko : l’équipe surveille son moral !
23 oct. 2014

C’est quoi ? Quel est l’objectif ?


Le "niko-niko" est un calendrier, mis en œuvre par l’équipe et pour l’équipe, sur lequel chaque membre de l’équipe reporte à la fin de chaque journée son ressenti avec une pastille de couleur.

Par "équipe", j’entends bien entendu l’ensemble des équipiers, le Product Owner s’il est bien impliqué au quotidien, et le Scrum Master (sauf peut-être s’il est uniquement un animateur ou facilitateur). En fait, il me semble intéressant que toutes les personnes participant tous les jours au stand-up, contribuent à cet indicateur !



L’objectif du "niko-niko" est d’avoir un suivi le plus visuel possible du moral général de l’équipe. Il permet à l’équipe de déceler au plus tôt une tendance à la baisse de ce moral général, et d’y réagir le plus vite possible. La présence d’une pastille rouge (ou de plusieurs) permet également de déceler une difficulté pour un ou plusieurs membres de l’équipe, de l’évoquer lors du stand-up dès le lendemain matin, et si besoin, de prendre un temps d’échange et de réflexion pour trouver une solution et tout de suite désamorcer un poids pour la suite de l’itération.

Lorsque je suis Scrum Master (ou coach), mon objectif est que le calendrier soit le plus vert possible …

Mise en œuvre

Pour moi, l’idéal est de faire, sur une simple feuille de papier, un tableau représentant les jours et semaines pour l’itération à venir (voir image), avec des cases suffisamment grandes pour que tous les membres de l’équipe puissent y coller une pastille.

Ce calendrier est à positionner dans la pièce où travaille l’équipe, de façon à ce qu’il soit très facile d’accès, idéalement près du "Scrum board" pour l’avoir sous les yeux lors des stand-up du matin, et pas loin de la sortie de la pièce pour que chacun pense à mettre sa pastille le soir avant de partir.

Les pastilles sont disponibles en 3 couleurs pour répondre à la question "Comment as-tu ressenti ta journée ?" :

  • Vert J : la journée a été bonne
  • Bleu (ou jaune ou autre) : K : journée moyenne, ni bonne, ni mauvaise
  • Rouge L : la journée a été mauvaise

Il est important d’échanger au sein de l’équipe sur l’échelle d’évaluation, et donc sur ce qu’est une "bonne" journée, une "mauvaise" journée, ou une journée "moyenne". Certains auront facilement tendance à mettre un "vert", et d’autres le garderont pour une journée plutôt "exceptionnelle". Moi, je propose "vert" si on sort avec la banane J, et "rouge" si on repart le soir en fronçant les sourcils ou en bougonnant L, et "bleu" sinon.

Lors d’un projet, nous nous étions posé la question : faut-il évaluer ma journée par rapport à mon avancement, ou si j’ai apprécié ce que j’ai fait. Certaines journées, on n'avance pas trop mais on est content de soi. Ou inversement. Nous avons donc testé, le temps d’une itération, un double calendrier pour ces 2 critères. Au final, cela nous a semblé compliqué à maintenir, mais également à exploiter. Nous sommes donc revenus à un seul calendrier.

Une autre question portait sur l’anonymat. Il arrive assez souvent que des membres de l’équipe oublient de mettre leur pastille le soir en partant. Sans initiales (et sans nom), difficile de savoir qui a oublié. De plus, lorsqu’il y avait une pastille rouge, il pouvait être intéressant de demander des précisions à la personne concernée pour comprendre le pourquoi du "rouge", et essayer, ensemble, de trouver une solution. Nous avons, là encore, essayé en mettant nos initiales sur nos pastilles. Pour différentes raisons, nous sommes revenus à l’anonymat, qui finalement, n'est pas réel au sein d'une petite équipe soudée, et les échanges lors du stand-up permettent de trouver les causes puis les solutions. Par contre, vis-à-vis de l'extérieur (management), l'indicateur est bien anonyme ...

Pièges ou erreurs 

Avant tout, il faut que le "niko-niko" soit utile. Lors d’une de mes premières expérimentations, il y avait un maximum de "rouges", ça nous confirmait bien le fait que le projet s’annonçait mal (planning irréaliste et grosses difficultés techniques), mais objectivement, l’indicateur ne servait pas à grand-chose, et surtout, nous n’en avons pas fait grand-chose. Il faut donc veiller à ce que ce soit utile, renseigné, surveillé, et utilisé pour l’amélioration de l’équipe.

Comme dit en introduction, c’est une indicateur mis en place "par" l’équipe et "pour" l’équipe. Une erreur constatée est une utilisation de cet indicateur par le management dans une approche plus "commande-contrôle" que "management agile". Je ne dis pas que cet indicateur ne doit pas être visible pour les managers, au contraire, ça peut leur être utile pour avoir discrètement et rapidement une évaluation du moral de l’équipe, mais c’est à l’équipe de l’utiliser pour réagir et s’améliorer.

Une autre erreur, qui limite la représentativité de l’indicateur, et la non participation de certains acteurs du projet, par exemple le Product Owner, parce qu’il est dans une autre pièce, alors qu’il est tous les jours au stand-up du matin, et en collaboration quotidienne avec l’équipe. Pourtant, s’il passe une mauvaise journée, il est probablement intéressant pour le reste de l’équipe de le savoir, et de réagir si elle y est pour quelque chose.

Conclusion

Le "niko-niko" est un indicateur très facile à mettre en place, et à mon avis, très intéressant dans un fonctionnement agile et d’amélioration continue. Le principe de base est simple, mais vous pouvez l’adapter à votre contexte, l’important étant d’essayer, en évaluant objectivement des essais, et de rester simple ! Sans oublier d’être vigilant aux pièges ou dérives, comme ceux mentionnés ici ou d’autres, pour que cet outil garde tout son intérêt et son apport à l’équipe.

Alors n’hésitez plus, lancez-vous, testez-le, et faites-moi part de vos retours d’expériences !

Voir l'article
On parle de TDD autour d’une bière …
28 avr. 2014
Il y a quelques temps, j’ai eu des échanges très intéressants avec un copain qui m’interrogeait sur ma vision et ma pratique du TDD. Voici une retranscription un peu arrangée de nos échanges ...

Lui : Récemment, je me suis intéressé à des librairies Open Source Java, accompagnées de plus ou moins de tests. Le TDD permet-il de garantir que le code est bien testé ?

Moi : Il faut bien distinguer le TDD et les tests unitaires. Le TDD est une “pratique”,
une façon d’écrire le code et ses tests unitaires. Lorsque tu récupères du code, par exemple une librairie Open Source, ce que tu y trouves, ce sont des “tests unitaires”, écrit ou non en TDD, à priori tu ne le sais pas. Et pour répondre à ta question, la présence de tests unitaires ne garantit pas que le code est bien testé, ni que tout le code est testé. Mais, si le développeur a bien fait son boulot, normalement le code fourni est de bonne qualité, du moins de meilleure qualité que sans tests. Les tests unitaires présent garantissent un certain fonctionnement du code, et permettront plus facilement de corriger le code, voire le faire évoluer.

On dit que le TDD permet de mieux documenter le code, par l’exemple. Tu en penses quoi ? 

Là encore, ce n’est pas le TDD qui fera office de documentation, mais les tests unitaires, puisque c’est bien ce code qui est disponible et que tu peux relire. Je me répète, mais le TDD est une “pratique”, ça n’est pas un résultat qu’on peut ensuite consulter. Par contre, pour l’aspect “documentation”, je ne crois pas que le TDD garantisse une “bonne” documentation du code. Qu’ils soient écrits en TDD ou pas, si des tests unitaires sont mal écrits, s’ils ne sont pas simples, faciles à relire, ils n’aideront pas le relecteur à comprendre ce que le code fait. En revanche, une bonne pratique du TDD peut guider le développeur vers de meilleures tests, donc un gain sur cet aspect documentation.

Dans ton cas, est-ce que tu produis de la documentation, autre que les tests ? 

Déjà, concernant les tests unitaires, je m’efforce de les rendre les plus lisibles et explicites possible, je n’hésite pas à mettre en place un DSL (“Domain Specific Langage”) spécifique au contexte métier et fonctionnel de mes développements, avec une API la plus “fluent” possible. Mon objectif est que mes tests puissent se lire comme des phrases, comme un texte qui raconte une histoire. Ensuite, concernant les commentaires, je n’en mets pas. Tout comme Oncle Bob dans son livre “Clean Code” (que je recommande encore et encore ….), je considère les commentaires comme un échec de nommage et de présentation de mon code. J’ai une exception : je mets éventuellement de la JavaDoc pour une librairie “externe” qui sera utilisée par d’autres personnes, mais attention, le maitre mot pour une documentation : elle doit être utile et tout le temps à jour ! Et pour compléter le tableau de la documentation, je préconise quelques notes d’architectures, non pas rédigées avant les développements, mais rédigées pendant et après les développements, et surtout, maintenues à jour, pour présenter les grands principes d’architecture retenus pour le produit développé.

Et justement, question architecture, on dit que le design doit émerger grâce au TDD, qu’en penses-tu ?

Pour moi, il y a une mésentente sur le fait que l’architecture doit émerger grâce au TDD. Je suis convaincu qu’on ne peut pas développer une application de taille moyenne ou grosse, en partant d’un test et d’une seule classe, avec l’architecture de l’ensemble de l’application qui émerger petit à petit. A mon avis, de cette manière, on arrive à une architecture “spaghetti”. Ou alors, le développeur est très fort, ou plus probable, a en fait en tête l’architecture vers laquelle il veut aller.

En développement agile, on parle bien de “vision”. Il faut avoir une “vision” du produit qu’on veut développer, aussi bien au niveau fonctionnel (savoir dans les grandes lignes ce que devra faire le produit), mais également au niveau architectural, qui consiste à prévoir à grande échelle le découpage en modules ou librairies. Au démarrage d’un projet, je conseille aux équipes de réfléchir et définir cette “vision” de l’architecture à grande échelle du produit. Par contre, hors de question de définir, avant de coder, le design interne d’un module ou d’un package. Là, c’est bien le TDD qui va nous aider à faire émerger l’architecture, en partant des besoins fonctionnels, et des besoins en code testable. 

OK mais de quoi pars-tu dans ce cas ? 

Prenons le cas d’un package en Java. C’est un ensemble qui a une cohérence fonctionnelle, qui va donc répondre à un ensemble de besoins, cohérents entre eux. Cela va s’exprimer, par exemple, par la mise en place d’une API proposée par une classe du package, ce sera le “point d’entrée” du package. En TDD, on va donc pouvoir partir de cette classe et de son API pour commencer par écrire des tests, probablement en “mocking”, approche dite “London school”, en utilisant des mocks pour les 3 ou 4 collaborateurs de cette classe. Une fois que ces tests passent avec succès, on va pouvoir s’attaquer à chaque collaborateur qui vient d’être mocké pour écrire les tests de ce collaborateur et son implémentation, peut-être là encore avec l’usage de mocks. Et ainsi de suite, jusqu’aux “classes terminales”, celles qui n’ont pas de collaborateurs (les “feuilles” de l'arborescence des classes), et pour lesquels on écrit des tests unitaires “purs” (sans mocks). Pour moi, elle est là l’émergence du design par le TDD !

Est-ce que pour toi il y a un lien entre TDD et code propre ? 

Oui, bien sûr ! Lorsque j’interviens auprès d’une équipe, avec par exemple une formation “Tests unitaires et TDD” sur 2-3 jours, je leur parle de tests unitaires et de TDD, bien sûr, mais ces journées sont également le moyen pour moi de les interpeller sur pleins d’autres aspects du développement : le “Code Propre” (ou “Clean Code”), la présentation du code, sa lisibilité, sa simplicité et son expressivité, les commentaires (ou pas ...), les bonnes pratiques d’équipes, la maîtrise de son outil (IDE), les erreurs d’architectures, comme par exemple les problèmes liés à l’héritage, etc … Tous ces thèmes sont étroitement en relation et nécessitent d’être tous mis en oeuvre pour aller vers le succès, et le code propre est une des premières pierres !

A quel problèmes d’héritage fais-tu allusion et pourquoi ?

En programmation objet, on fait souvent un mauvais usage de l’héritage. Moi le premier, pendant des années, j’étais le “maître” en la matière, je produisais des architectures avec des héritages de folie ! Jusqu’à ce qu’un jour, un jeune collègue, plus jeune que moi (comment est-ce possible ? … ;-) ..) est venu m’expliquer que c’était mal … J’ai mis du temps à le comprendre et à l’accepter, mais il avait raison. 

Trop souvent, on utilise l’héritage pour apporter des fonctionnalités à un objet, c’est pratique. Mais c’est une erreur, car ces apports de fonctionnalités sont une facilité mais ne caractérisent pas réellement ce qu’est cet objet. C’est de “l’héritage technique”. La bonne solution n’est pas l’héritage mais l’aggrégation, c’est-à-dire fournir à l’objet un collaborateur qui va pouvoir l’aider dans ses tâches en venant avec ses propres fonctionnalités. 

Et concernant les tests unitaires, l’héritage est un véritable fléau et posent bon nombre de problèmes. Par exemple, pour tester une fonctionnalité héritée, dois-je le faire dans la classe fille ? Ça n'est pas logique et ça démultiplie mes tests, et pourquoi le faire plus dans cette classe fille là plutôt que dans une autre. OK, alors je teste la classe mère. Oui, mais elle est (souvent) abstraite avec plein de fonctions virtuelles … Voilà pourquoi lors de mes formations, je suis obligé d’aborder plein de sujets connexes aux tests !

L’héritage doit être utilisé à bon escient, avec modération, et beaucoup moins souvent que ce qu’on a l’habitude de voir. Lors de mes formations, je propose souvent aux équipes une architecture qui distingue les objets de traitement des objets de données (voir mon article "Développement et conception : mon approche P(N)OO"). Et avec cette approche, je ne fais jamais d’héritage sur les objets de traitement, et les héritages sur les objets de données doivent toujours respecter la règle “est un(e)”, ces objets de données ayant peu ou pas de traitement.

Pour en revenir au TDD, son but, c’est bien de tester le code, non ? 

En développement agile, l’approche consiste à ne pas anticiper sur les développements de l’itération suivante. Mais lorsque j’en serais à la prochaine itération, je devrais ajouter des fonctionnalités à mon produit, et mon code n’est pas forcément adapté. Pour ajouter ces nouvelles fonctionnalités, je vais donc devoir “refactorer” (remanier) mon code. Pour pouvoir faire cela en tout tranquillité, mon code doit être testé. Le meilleur moyen d’avoir du code testable et donc testé, c’est d’écrire d’abord les tests, le fameux TDD.

OK, donc le TDD, c’est du code testé et une émergence du design à moyenne échelle ?

Oui, mais pas seulement. Commencer par écrire les tests, c’est se focaliser sur ce que doit faire le code, sur le “quoi”. Sans le TDD, le développeur se plonge dans le code, dans le cambouis, il se polarise tout de suite sur le “comment”, et souvent, il fixe son attention sur les points qui vont être difficile à coder. Et finalement, il ne se pose pas vraiment, en profondeur, la question de ce qu’il doit développer, de ce que son code doit réellement faire. Moi le premier, j’étais comme ça. Se mettre au TDD implique un gros changement d’état d’esprit, cela nécessite des efforts, mais ensuite, tout parait plus simple, plus logique et tellement plus plaisant !

En conclusion, pour moi, le TDD est la meilleure pratique pour obtenir du code testé, évolutif et qui fait ce qu’il faut !


Merci à ce copain, qui préfère garder l’anonymat, pour ces échanges et pour sa collaboration à la rédaction de cet article. A noter que son niveau de connaissances (tests unitaires, TDD, architecture) est bien supérieur à ce que les questions ci-dessus peuvent laisser penser … ;-)

Voir l'article
Mon retour sur Devoxx France 2014
21 avr. 2014

Cette année, pour la première fois, je me suis payé Devoxx France. Voici mon retour sur ces 2 journées intenses et riches.

Ce que j'ai particulièrement apprécié :

  • La qualité générale de la conférence et le choix dans les sessions et quickies
  • La restauration, avec notamment un bon accueil petit-déjeuner, et du café ou des sodas à disposition toute la journée
  • Un moment et un espace propice aux nombreuses rencontres et échanges
  • Les différents formats de sessions, notamment les quickies (excellents pour certains) et les BOF (je n'ai finalement pu en faire qu'un seul, mais c'était très sympa)
  • L'application Android Devoox France (je ne sais d'ailleurs pas si c'est "l'officielle") où j'ai particulièrement apprécié de pouvoir marquer en favoris les sessions qui m'intéressaient, et les retrouver directement dans le planning
  • Le programme papier, pratique pour consulter le programme en détail et faire ses choix
  • La "boite à vote" à la sortie des salles, même si le système présente des inconvénients, et si je n'ai pas trouvé où consulter les résultats des votes ...

    

    Ce que j'ai moins apprécié :

    • Le repas de midi (organisation compliquée, du monde, du bruit)
    • Certaines sessions vraiment pas terribles : je ne sais pas vraiment pourquoi, peut-être le prix, mais je m'attendais à avoir un niveau minimum de qualité pour toutes les sessions, mais je sais bien que pour l'organisation, il est difficile de faire le tri et le choix dans les sessions, et qu'il est possible de se tromper
    • Le nombre de personnes par sessions : toutes les sessions auxquelles j'ai assisté étaient bien remplies, voire pleines, voire même archi-pleine, et même parfois inaccessibles (tellement y'avait de monde) : je me suis donc demandé si certaines autres sessions étaient moins remplies, ou s'il y avait un problème de logistique au regard du nombre total de participants ...
    • Les buzzwords font fureur dans les titres des sessions qui, au final, pour certaines, sont vraiment décevantes !
    • Je suis toujours déçu par les sessions techniques sans code (voir live coding), et je ne supporte plus les XML dans les diaporama (c'est illisible et ch....)
    • Le prix, tout de même pas vraiment donné pour un indépendant ...

      Ce qui va me servir prochainement :

      • RESTX
        • RESTX devrait m'aider pour 2 projets RESTful à venir, je vais regarder ça de plus près, merci Xavier Hanin, qui fait pour moi partie de ces quelques "super développeurs" !
      • git-deliver
      • DbSetup
        • "Le bon testeur il teste.... et le mauvais testeur il teste aussi..." : un bon titre, plein d'humour, pour une excellente session animée par Agnès Crepet et Guillaume Ehret, j'étais content d'entendre un discours similaire au mien (code de test propre et lisible, bon usage des mocks, etc ...), et j'ai découvert DbSetup, une bonne alternative à DBUnit, que j'irai voir plus en détails sans traîner ! Sans compter le petit message final d'Agnès, que je porte également dès que je le peux: la qualité est notre problème et notre responsabilité, à nous les développeurs, donc à nous de la défendre et de la promouvoir !

          

        Ce que j'ai vu et retenu :

        • Keynotes : on parle de plus en plus du statut et de la reconnaissance des développeurs, c'est pas encore ça, pas sûr que ceux qui ont parlé changent vraiment quelque chose, mais au moins, ça va dans un sens que je trouve bon, et plus on en parle, plus ça bougera ... espérons ...
        • Cédric Champeau m'a donné envie d'aller voir de plus près Gradle, et point appréciable, il n'a pas tapé bêtement sur Maven ;-)
        • J'ai apprécié les "Promesses et Yield" de JavaScript dans le Quicky de Florent Le Gall, ça va nous simplifier le code, mais va falloir changer nos approches et s'adapter !
        • Puppet ou Chef, ça a l'air génial d'après François le Droff et Romain Pelisse (qui est très énergique parle un peu trop vite), mais je suis vraiment loin de ce monde-là (mais faut savoir être curieux !)
        • Samuel le Berrigaud m'a fait découvrir le principe de "développer en mode kick-ass" ("qui déchire") qui pour moi est totalement compatible avec ma vision de l'agilité (qui n'est donc pas mort !)
        • Au BOF BrownBagLunch, nous avons partagé sur 1 an d’existence de cette approche qui mériterait d'être plus connue ...
        • Nous sommes à l'aube des "objets connectés", et Jean-Philippe Encausse nous a montré le framework SARAH qui se propose en passerelle dans un monde de protocoles (pour l'instant) hétérogènes
        • Florent DUVEAU a fait un très bon Quicky pour présenter Sinon.JS, j'avais déjà aperçu de loin ce framework, y'a de bonnes choses, mais sur le fond, ça ne m'apporte toujours rien pour ma recherche de "bonnes" solutions pour "bien" tester mon JavaScript ....
        • Au delà des lambdas, des streams et des Collectors, j'ai découvert plein de nouveautés sympa de Java 8 grâce à José Paumard qui est un excellent orateur et a fait salle plus que comble !
        • Pour ma dernière session, je n'ai pas pu m'empêcher d'aller à la session "Extremist Programming : l'art de s'amuser avec du code" excellemment animée par Eric Lefevre-Ardant et Cyrille Martraire, qui nous présente des approches débiles ou absurdes (mais pas toujours tant que ça) autour du code, et qui lancent le compte @weirddev à suivre pour recevoir régulièrement des idées bizarres pour s'amuser avec son code ! 
        • Et pour finir la journée, je suis allé à l'enregistrement live de la 100e (101e au final) du podcast Les Cast Codeurs, avec un retour sur Devoxx 2014 dans une super ambiance !
            

        Petite précision : je ne reviens que sur le positif, je me mentionne donc pas les sessions qui m'ont déçu, en sachant qu'à 2 reprises, j'ai quitté la salle en cours de session, ce que je ne fais pourtant jamais ...

          Conclusion

          Effectivement, ce qu'on dit est vraiment : Devoox France, c'est super ! J'ai passé 2 journées intenses et fatigantes, mais j'ai vu plein de choses intéressantes, je repars avec des idées à mettre en oeuvre rapidement, et merci à tous ceux que j'ai croisé ou rencontré et avec qui j'ai pu avoir de beaux échanges !

          PS : quelques ajouts le 21/04 : application Android, programme papier, boite à votes
          Voir l'article
          Scrum Tower Game
          23 mars 2014
          Le "Jeu de la tour Scrum", ou comment découvrir les concepts de base de l'agilité et de Scrum en s'amusant ...

          Introduction


          Il y a quelques années, sollicité par une entreprise pour sa transition vers l'agilité (merci à eux), j'ai mis au point un jeu permettant de découvrir quelques aspects de l'agilité, et les concepts de base de Scrum. Baptisé depuis "Scrum Tower Game", j'ai déjà déroulé plusieurs fois cet atelier, qui tient ses objectifs à chaque fois.

          Après en avoir parlé au détour d'une bière, je l'ai fait jouer lors d'une soirée agile du CARA à Grenoble, avec des retours intéressants des personnes présentes. 

          Lors de la dernière session de Agile Game France, je n'ai pas osé l'amener dans mes valises, mais certaines personnes me l'ont fait regretter, et m'ont motivé à diffuser cet article pour le présenter (1).

          La Genèse 


          Mon client de l'époque avait insisté pour intercaler un jeu dans le déroulement de la journée de formation. C'est d'ailleurs une bonne idée, ça permet de casser le rythme d'une journée intense. 

          L'idée était donc de proposer un jeu permettant de découvrir les concepts de base de Scrum, après une grosse matinée d'introduction à l'agilité, et de présentation des principes de base de Scrum. 

          Il y a pas mal d'années, lors d'une formation "Scrum Master", j'avais participé à un atelier qui m'avait pas mal déplu notamment pour un point : le "temps accéléré". Dans cet atelier, nous faisions des itérations "accélérées", de plusieurs minutes. Mais prenons le cas d'une rétrospective : on peut raccourcir le temps pour faire une rétro de 2', mais on ne parle pas plus vite pour autant (à la manière d'un 78 tours, pour les anciens ...). Je voulais donc absolument éviter ce "temps accéléré".

          Par ailleurs, je ne suis pas forcément "créatif", surtout lorsque je participe à une formation. Je souhaitais donc éviter de polariser l'attention des participants sur ce qu'ils doivent produire, pour leur permettre de se concentrer sur les rôles, les règles, les principes, etc ...

          Et bien sûr, il fallait un côté jeu, un côté plaisant : j'ai ressorti les "Duplo" basiques de mes enfants.

          C'est ainsi qu'est né ce jeu, à base de "légo", à une époque où on en parlait pas du tout dans la communauté agile ....

          Un jeu "cadré", oui mais ...


          Le déroulement de ce jeu est assez contrôlé et guidé, mais cet aspect n'est normalement pas trop ressenti par les participants, et surtout, le fait que ce soit calculé et dimensionné, me permet de faire apparaître des "problèmes", des situations particulières, qui sont alors des occasions pour présenter certains particularités importantes de l'agilité : re-découpage, frustration, renoncement, ...

          Rôles 


          Les rôles sont répartis parmi les participants, éventuellement en collant aux futurs rôles de chacun pour le projet à venir :
          • 1 animateur (rôle que j'assume à chaque fois) : l'idée est de veiller au bon déroulement du jeu, en m'arrangeant pour amener l'équipe dans des situations particulières, et en insistant tout au long du jeu sur les particularités liées à l'agilité
          • 1 ScrumMaster (SM) : je lui fournis des feuilles A3 prêtes pour tracer les "Burndown Charts", il prépare le "Scrum Board", et devra s'assurer de l’enchaînement des différentes étapes et cérémonies. Ce rôle est assez léger, en général les personnes sont trop novices, je les assiste pas mal
          • 1 Product Owner (PO) : je lui fourni une feuille avec des illustrations de ce qui doit être produit. Je l'incite à répondre aux questions de l'équipe, sans trop en dire ni devancer les informations à fournir. Je lui explique notamment 2 points qui seront importants : la nécessité de redécouper une histoire, et en fin de jeu, le renoncement à la totalité de la tour
          • 4 équipiers : ils devront fournir les estimations, en questionnant le PO, puis produire le résultat attendu
          • les autres participants sont observateurs et participeront à la rétrospective de l'atelier

          On voit / On ne voit pas ...


          Ce jeu permet d'appréhender :

          • les rôles de Scrum
          • la production itérative
          • le rythme de Scrum et ses cérémonies
          • certaines situations inattendues que l'agilité permet de gérer

          Par contre, on ne peut pas tout mettre en oeuvre, et notamment :

          • la notion de terminé (du moins très réduite ici)
          • l'initiative technique et les choix par l'équipe
          • la gestion "humaine" d'une équipe sur le moyen et long terme
          • ...

          Objectif pour l'équipe


          L'objectif pour l'équipe est de produire une tour en légo comme celle-ci :



          Les équipiers ont à leur disposition le matériel suivant, avec des Pièces Grandes (PG), des Pièces Moyennes (PM) et des Pièces Petites (PP)  :


          La tour est composée de fondations, de 3 étages de couleurs différentes, et d'un sommet:



          Le bloc de fondations est composé de 3 PG et 3 PM :


          Chaque étage est composé de 6 PM de même couleur (1 couleur par étage) :


          Le sommet est composé de 7 PP (dont "l’œil") :


          Déroulement


          Logistique

          On s'organise pour avoir de l'espace devant le Scrum Board et pouvoir y faire les stands-up de chaque jour. L'équipe s'installe sur une table qui servira d'espace de travail "quotidien", et on prévoit un autre espace dit "d'intégration" ou seront déposés les éléments complets.

          Démarrage

          Le jeu se déroulera en 3 itérations de 3 jours. Il comme donc par la réunion de planification de la première itération, cumulant un peu un "sprint 0". L'équipe découvre l'objectif présenté par le PO, le matériel, et les règles.

          Le PO présente les "Histoires" ("'Stories" (2)) initiales du "Carnet de produit" ("Product Backlog") et demande aux équipiers de lui donner des estimations. Pour simplifier le jeu, 1 jour de production pour 1 équipier = 1 pièce de légo posée = 1 point.

          Après un échange de questions-réponses entre l'équipe et le PO, on aboutit à ces estimations :
          • Fondations : 6 points
          • Étages (une seule histoire initialement) : 18 points (3 x 6)
          • Sommet : 7 points
          Le SM demande alors à l'équipe d'estimer sa vélocité, donc sa capacité de production pour 1 itération. Donc 3 jours à 4 équipiers = 12 points.

          L'équipe et le PO doivent alors décider ce qui sera réalisé pendant la première itération. Le premier "problème" apparaît : l'histoire pour les "3 étages" est trop grosse !

          Redécoupage

          Le SM demande alors au PO s'il serait possible de découper cette histoire. On obtient alors 3 histoires différentes estimées chacune à 6 points : "étage 1", "étage 2", "étage 3".

          L'équipe peut alors s'engager pour la première itération sur : les fondations pour 6 points et l'étage 1 pour 6 points, puisque sa vélocité estimée est de 12 points.

          On peut alors préparer le Scrum Board avec les post-its pour les histoires, pour chaque tâches (1 tâches = 1 pièce de légo), le Burndown Chart, etc ...

          Oui mais .... les aléas ....

          C'est alors que j'introduis une élément supplémentaire, une règle "oubliée" : avant de fournir sa production quotidienne, chaque joueur doit lancer ce dé "spécial" :


          Et s'il tombe sur la face rouge, la journée ne s'est pas passée comme prévue, il passe son tour et ne produit rien.

          Multi-tâches (multi-histoires) ?

          Et pour "gagner du temps" (enfin ....), j'incite fortement l'équipe à se répartir le travail en "binôme" pour attaquer en même temps les fondations et l'étage.

          Itération 1 : Aïe !

          On déroule alors l'itération de façon "classique", en s'appuyant sur les cérémonies de Scrum. Chaque journée commence par un stand-up devant le Scrum Board qui est mis à jour ne fonction de ce qui s'est passé la veille, et de ce qui est prévu pour la journée à venir.

          Durant cette itération, je m'assure que chaque "binôme" a au moins un "obstacle" avec le dé, sinon, j'interviens pour forcer la face "rouge" [NDLA : en général, cette intervention néfaste est tout de même bien acceptée par l'équipe qui comprend qu'il y a un objectif pédagogique].

          En fin d'itération, si tout s'est déroulé comme prévu (du moins pour moi), aucune des histoires n'est terminée, l'équipe n'a donc rien à montrer .... Je lui laisse donc le soin de faire venir le PO pour le lui dire ... A ce moment-là, souvent, des équipiers essaient de trouver une solution pour tout de même montrer quelque chose, mais la règle est claire : on montre ce qui est terminé ! Donc rien à ce stade du jeu ...

          On enchaîne alors sur la rétrospective pour évoquer ce qui s'est passé, et évidemment, le fait que d'attaquer plusieurs histoires en parallèle n'est pas un bon choix. L'équipe devrait alors décider, pour l'itération suivante, de mettre les efforts pour finir les histoires commencées, puis de travailler plus collectivement sur les histoires suivantes.

          On fait également le bilan concernant la vélocité qui est en générale mesurée à 9 ou 10, et souvent revue à la baisse à 10.

          En général, l'équipe attaque cette première itération dans une certaine euphorie ludique, mais la finit dans une ambiance plus morose ...

          Itération 2 : Yeah !

          Avant de lancer la deuxième itération, on commence évidemment par une réunion de planification. On est alors dans une situation particulière. L'équipe voit bien qu'elle peut s'engager à terminer les fondations et le première étage, et qu'elle peut également s'engager sur le deuxième étage. Mais il reste quelques points de vélocité ...

          Avec mon approche pragmatique, je leur propose de voir avec le PO sur quelle histoire ils pourraient avancer si tout se passe bien, mais sans "engagement" sur cette histoire supplémentaire qui ne sera pas terminée.

          La deuxième itération se déroule mieux. Les participants ont compris les règles, ils commencent à intégrer tout doucement le cycle des itérations, et surtout, en 1 tour de jeu ou 2, ils finissent les 2 premières histoires, et ressentent le plaisir de produire (enfin) quelque chose de terminé.

          Au cours de cette itération, je m'arrange pour que les "aléas" du dé "à face rouge" ne permette pas à l'équipe de commencer une nouvelle histoire, tout en finissant celles prévues (j'interviens donc dans un sens ou dans l'autre sur le dé).

          On peut également tomber sur une autre situation particulière, à savoir qu'un équipier risque de ne pas terminer sa tâche s'il a un obstacle alors qu'un autre a un peu d'avance et pourrait attaquer l'histoire "bonus". J'accompagne alors l'équipe pour qu'elle s'organise au mieux, notamment dans l'ordre des tours de jeu, pour assurer l'engagement pris, quitte à ce qu'un équipier change de tâche au dernier moment, pour ne pas attaquer l'histoire bonus mais vienne en aide à un équipier en difficulté.

          L'itération se termine donc mieux que la précédent, avec notamment une démonstration au PO de ce qui est produit : les fondations et 2 étages. Si le temps le permet, on peut faire une rétrospective, sans qu'il y ait (pour cet exercice) de points particuliers à décider à ce stade du jeu.

          Itération 3 : oups !

          Comme précédemment, on attaque la troisième itération par la réunion de planification. Un constat apparaît tout de suite : l'équipe ne pourra pas tout faire : avec une vélocité à 9 ou 10, on ne peut pas faire le troisième étage (6 points) et le sommet (7 points). 

          Je laisse donc l'équipe et le PO échanger librement, en observant ce qui se passe, puis en intervenant pour pointer les bons ou mauvais réflexes. Souvent, des équipiers proposent, voire prennent des initiatives pour choisir ce qui sera fait, voir découper des histoires. J'insiste alors sur le fait que c'est au PO de trancher, fonctionnellement, et le PO, précédemment briefé, choisit alors de renoncer au 3e étage mais insiste pour avoir le sommet.

          Il y a donc un "surplus" de vélocité qui amène souvent des questions, mais je présente souvent cette dernière itération comme la fin du projet, le temps restant permettant, dans la vraie vie, de fignoler certaines parties, de finir la documentation, etc ...

          Le déroulement de la 3e itération est souvent accéléré, le sommet est rapidement réalisé, on n'oublie pas la démo finale, sans se priver de faire une photo de toute l'équipe (PO et SM compris) autour de la tour produite !

          Synthèse

          • Matériel : Duplo (en nombre suffisant), 1 dé "spécial", tableau blanc, post-its, feutres
          • Nombre de participants : 6 + 1 animateur + observateurs
          • Durée : environ 1h30
          • Objectif : Scrum, ses rôles, son rythme, ...

            Conclusion


            Plus intéressant à dérouler qu'à expliquer (longuement) dans un article, ce jeu me donne à chaque fois entière satisfaction, il répond vraiment à mes attentes, dans un contexte de formation d'introduction à l'agilité et à Scrum. 

            Outre le fait de permettre aux participants de mettre en oeuvre certains rôles, certains supports, le rythme de Scrum, etc ..., ce jeu me permet également tout au long de son déroulement de pointer et insister sur certaines particularités de l'agilité. 

            Il pourra également me servir de référence lorsque, par la suite, j'accompagnerai l'équipe dans sa transition agile, nous pourrons alors nous remémorer certaines scènes du jeu.

            N'hésitez pas à me laisser des commentaires pour me faire part de vos réactions et interrogations. Bien sûr, vous pouvez me laisser vos question, ou me contacter pour plus de détails, ou si ce jeu (et la formation dans laquelle il s'intègre) peuvent vous intéresser pour votre entreprise, pour votre équipe !

            Merci !



            (1) Remerciements et dédicace à D. ... ;-)
            (2) Lorsque je parle de Scrum, j'aime bien utiliser du vocabulaire Français, dans la mesure du possible
            Voir l'article
            Un bon titre pour une bonne session TDD et coding-dojo
            10 févr. 2014

            Introduction

            Je me permets de solliciter la(les) communauté(s) pour recueillir des avis et propositions pour un titre de session.

            La session

            A l'automne, j'ai animé une session "L'apprentissage du TDD en Coding-dojo" lors des conférences agiles de Marseille, Montpellier et Grenoble. Cet atelier d'environ 2h me permet de présenter un peu de théorie sur les tests unitaires et le TDD, puis de faire une rapide démo live avant d’enchaîner sur un coding-dojo de type randori (donc sur un seul poste vidéo-projeté) pour permettre à une partie des participants de s'essayer, en pair-programming, au TDD pendant 5-6', sur un sujet simple, avec mes conseils, mes remarques et le soutien de l'assistance.


            Objectifs

            Cet atelier me permet de présenter le TDD (indispensable à un développement agile, mais vraiment pas assez répandu) mais également le coding-dojo, qui n'est finalement pas si connu que ça, et qui est un format que j'apprécie énormément, soit lors de mes interventions en entreprises, soit à mettre en place régulièrement au sein d'une équipe.

            Public visé

            Cette session s'adresse aussi bien à des développeurs, ayant plus ou moins de connaissances sur les tests unitaires et le TDD, mais également aux managers ou décideurs pour les sensibiliser à la nécessité d'accompagner leurs équipes vers cette pratique, et de leur apporter formations et accompagnements.

            La question du jour 

            Devant le succès et les nombreux retours que j'ai eu suite aux sessions de l'automne, j'ai proposé cette session pour Agile France 2014, et je prévois de la proposer pour Mix-IT 2014. Mais j'ai récemment eu quelques retours sur mon titre qui n'est pas assez accrocheur pour attirer du monde. Soit !

            Je me permets donc de vous solliciter aujourd'hui pour m'aider à trouver un meilleur titre. Alors n'hésitez pas à me laisser un petit commentaire avec vos avis, vos propositions, vos suggestions ....

            Merci !

            Voir l'article
            Développeur : un métier de passion !
            16 déc. 2013
            Pour faire suite à mon article Développeur : une passion et un métier, sinon rien !, et conforme à ma motivation du moment pour diffuser ce point de vue, mardi dernier (10 décembre), j'ai proposé d'aborder ce sujet lors des Human Talks Grenoble.

            Ma session de 10' a été filmée, vous pouvez donc la consulter ici (la qualité d'image n'est pas géniale, mais le son et les slides y sont, c'est l'essentiel) :



            Un grand merci à l'équipe @HTGrenoble pour l'organisation de ces soirées bien sympa, à Victor pour la vidéo et aux participants pour les nombreux échanges très intéressants !





            Voir l'article
            Agile Grenoble et Agile Innovation cuvée 2013
            27 nov. 2013
            Les 21 et 22 novembre dernier, j'ai assisté à Agile Grenoble 2013 et Agile Innovation 2013. En voici quelques éléments de retour.


            Qualité :

            • Il n'y aurait pas "la" qualité mais "les" qualités ?
            • Du moins, il y a plusieurs éléments de qualité, selon qu'on regarde le code, la stabilité de l'application, sa réponse au besoin, son utilisabilité, etc ...
            • Mais pour commencer, l'important est déjà de se poser des questions, quelques soient les critères d’évaluation : quelle est la qualité attendue ? quelle est la qualité de l'application actuelle ?

            #NoXxx :

            • Le courant des NoXxx peut être source de discussions nombreuses et variées ! 
            • Il n’est pas forcément question de supprimer (sauf pour les commentaires …), mais bien souvent de remplacer : NoSQL, NoEstimate, NoFramework, NoSprint (les "sprints" de Scrum), etc … 
            • Et tout cela dépend du contexte, le "No" n’est pas un objectif en soi. Une base de données NoSQL est préférable dans certains cas, alors qu’une base relationnelle SQL le restera dans d’autres. 
            • De même, Scrum n’est pas forcément une étape de passage, avec Kanban l’objectif final : 
              • Une approche en flux peut être adoptée dès le début de la migration à l’agilité (pas de passage obligé par Scrum), ou lorsque l’équipe a acquis une certaine maturité et que le contexte s’y prête
              • Mais une organisation de type Scrum peut rester la meilleure dans certains cas, avec respect strict des règles de base de Scrum, règles simples mais essentielles


            Divers :

            • Animer une session lors d’une conférence en fait zapper une bonne partie (1 matinée pour moi)
            • Mais j’ai vraiment de plus en plus de plaisir à partager et échanger sur des points techniques de dév
            • La loi des 2 pieds proposée pour les rencontres de type "espace ouvert" ("open space") est également valable si on n'est pas trop bien dans son boulot actuel (un peu ce que je disais )
            • Le TDD rend-il heureux ? Moi, oui ! Mais pas seulement sa phase "verte", c'est lorsque je peux mettre en oeuvre une approche TDD que je suis content, et donc lorsque je n'ai pas de tests unitaires que je suis malheureux. Et plus largement, le travail bien fait (le code propre, qui fait ce qu'il faut, etc ...) me rend heureux, tout comme l'apprentissage et le partage
            • Le jeu "La crevasse" est vraiment excellent pour pointer la confiance envers l’autre, la confiance en soi, l’engagement, etc ...
            • La sociocratie peut apporter des pistes intéressantes pour les échanges au sein d’un groupe, et pour les choix et les prises de décisions (prise de décision par consentement)


            Et pour finir, et revenir à l’agilité :

            • Par rapport aux années passées, j’ai moins entendu d’agilistes qui cherchent à aller au-delà de l’agilité, au-delà de Scrum, donnant l’impression que eux, plus que d’autres, auraient vraiment compris les choses pour passer à un stade "supérieur" : personnellement, j’ai l’impression de plutôt revenir de plus en plus aux fondamentaux, au manifest et ses valeurs, à Scrum et ses règles simples mais précises …
            • J’ai beaucoup plus entendu parler des développeurs, de leur bonheur, de leur plaisir au travail, aux tâches bien faites, au code propre, etc … De plus en plus de personnes semblent comprendre ce que j’essayais de dire l’an dernier (session "N’oubliez pas les développeurs") : dans l’édition logicielle, les développeurs sont bel et bien au cœur du système, et ils ne peuvent pas faire de développement agile sans faire évoluer leurs outils et leurs pratiques. Ce n’est pas inné, et cela peut nécessiter formation et accompagnement


            Conclusion :


            J’ai donc passé 2 journées vraiment excellentes et très riches de rencontres et d’échanges, un grand merci à tous ceux (impossible de tous les nommer) que j’ai pu croiser lors de ces journées et qui m’ont apporté par leurs questions, leurs points de vue, leurs oppositions : Merci !

            Voir l'article
            Développeur : une passion et un métier, sinon rien !
            18 nov. 2013

            Introduction


            Dans le développement logiciel depuis plus de 20 ans, je réalise depuis 2 ans (seulement mais réellement), et de plus en plus, à quel point le métier de développeur doit être une passion !

            C'est un métier d'artisanat, où l'on fait rarement 2 fois la même chose, où il faut innover tous les jours. L'éco-système bouge très vite, les langages existants évoluent (pas très vite, mais tout de même), de nouveaux langages voient le jour (sont-ils adaptés à mon besoin ou pas ?), de nouvelles librairies sortent régulièrement, une techno révolutionnaire aujourd'hui sera remplacée par une autre encore mieux dans 3 ou 6 mois. Sans compter les bonnes pratiques que je vois évoluer et s'affiner sans cesse ...

            Le métier de développeur est difficile ...


            Evolution du développeur : chef de projet !?


            NON ! Ca n'est pas le même métier, ça n'a rien à voir !

            Et pourtant, cette "logique" a la vie dure, portée par l'industrie du développement logiciel depuis des années et les grosses sociétés de service. Mais pas seulement ! Il y a 2 semaines, j'ai animé une journée "Tests unitaires et TDD" à l'université, auprès d'élèves en master, en commençant par sonder les élèves : 1/3 seulement se projette dans le métier de développeur, et tous m'ont confirmé qu'on leur explique qu'ils feront développeur pendant 5 ans, jusqu'à être sénior et expert, avant de passer chef de projet ... Il faut que le système scolaire se mette au gout du jour !

            Heureusement, d'autres voix s'élèvent et se font entendre, permettant peut-être à chaque développeur de sortir de cette fausse logique, de reconnaître ce qu'il aime faire et de se positionner ... (1)

            Mais que faire ?

            Je suis développeur et ça me passionne !


            Et bien tant mieux, ne lâche pas l'affaire, et assume : tu n'es pas le seul !

            Par contre, une passion ça s'alimente, ça se nourrit. Et si ça n'est pas le cas dans ton quotidien au boulot, tu dois te prendre en main, personne ne s'occupera de ta carrière à part toi (2).

            Cela veut dire qu'il te faut lire des livres, lires des articles de blog, te créer un compte Github, participer (au moins un peu) à des projets, voire créer les tiens, participer à CodeStory, blogger, aller à des rencontres près de chez toi, à des JUG, des coding-dojo, faire des talks aux Human Talks, voire même faire des sessions dans des conférences, etc...

            Et tout cela bien sûr, probablement en dehors de tes heures de boulot, car la passion ne s'arrête pas à 18h ;-)

            Je fais du développement mais ça ne me passionne pas ...


            A vrai dire, il y a alors 2 possibilités.

            La première est que le développement te passionne, mais tu ne le sais pas. Du moins, tu es dans un contexte qui ne te permet pas de le savoir : ton environnement est dans la "logique" citée précédemment, ton job ne te permet pas de t'éclater ou d'innover, ton patron ne veut pas entendre parler tests unitaires, TDD et qualité, et pourtant au fond de toi, ça te titille, tu en as parlé mais tu t'es fait remballer. Alors là, c'est simple : casse-toi ! (3) Et oui, n'aies pas peur du changement, qu'est-ce que tu risques ? Trouve toi une bonne boite ou tu pourras prendre conscience de ta passion, l'assumer et l'assouvir.

            La deuxième solution est que, vraiment, le développement ne te passionne pas et soit pour toi un travail, probablement passager. Dans ce cas, n'hésites pas à faire tout ce que tu peux pour faire rapidement autre chose, sans forcément passer par les cases "sénior" et "expert" qui ne sont pas indispensables pour ton évolution.

            Je suis manager


            Commence par reconnaître tes développeurs à leur juste valeur, individuellement et collectivement. Tu es dans l'édition logicielle : le boulot est fait grâce à eux, ne l'oublie pas !

            Ensuite, comprend que c'est un métier difficile, qu'il faut se former tout le temps, et si possible, pas sur le code de production : libère du temps R&D pour tes développeurs, laisse-leur du temps libre (en rapport avec le boulot) leur permettant de faire de la veille techno, de s'essayer au TDD, de recoder mieux une partie de l'appli, de tester de nouvelles solutions ou ergonomies, etc... Incite les à organiser régulièrement, au sein de l'entreprise, des coding-dojo qui seront des lieux protégés d'entrainement, de partage, et de fédération de l'équipe.

            Et pour compléter, propose leur d'aller dans des conférences (agilité, techno WEB, conf dédiées, etc ...) voire même d'animer eux-même des sessions pour partager leur passion (et ça fera de la pub pour ta boite).

            Pour finir, laisse-les assumer leur passion du développement logiciel, laisse leur les initiatives et choix (techniques, architectures, etc...), et embauche des chefs de projet, mieux des Product Owner, au lieu de forcer des développeurs vers cette "évolution" qui n'en est pas forcément une ...

            Je suis recruteur


            Pour bien recruter, il faut connaitre et comprendre. Alors, va à la rencontre des développeurs, va dans les conférences ou les soirées, va discuter avec eux, va comprendre leur passion pour le travail bien fait, le "clean code", la qualité, les bienfaits des tests unitaires et du TDD, etc ...

            Tu pourras alors comprendre ce que tu cherches, de quoi tu parles, ce que tu écris dans ton annonce. Peut-être même que tu ne passeras plus d'annonces et que tu comprendras que les bons développeurs, tu les trouveras autrement. Et lorsque viendra l'entretien, la discussion avec le candidat, tu pourras un peu mieux comprendre à qui tu as à faire, et déceler (ou pas) la passion qui anime ton futur recruté.

            Et pour encore plus réussir ton recrutement, va rencontrer l'équipe qui devra accueillir le nouveau, va comprendre comment elle fonctionne, qui ils sont, ce qu'ils font, ce qui les anime, quelles sont leurs particularités. Et lorsque tu penses avoir trouvé l'oiseau rare, n'hésites pas à lui présenter l'équipe, à les laisser échanger et vérifier les éléments de leur adéquation.

            Je suis client


            Et tu vas me dire que tu n'y connais rien, et que ce qui t'importe c'est le résultat produit ? Non bien sûr, tu as déjà compris. Toi aussi, tu dois rencontrer et échanger avec les développeurs. Tu dois comprendre quel est leur métier, quelles sont leurs difficultés, qu'est-ce qui les passionne et les satisfait. Mais eux aussi ont tout intérêt à te connaitre, à t'avoir rencontré (pour penser à toi lorsqu'ils développeront), à comprendre ton contexte, tes attentes, tes craintes, tes rêves, et ce qui fera que tu seras content du résultat et heureux !

            Conclusion


            Développeur, c'est un "métier" et une "passion". Les développeurs doivent en prendre conscience, avec les apports qui vont avec, mais également les obligations. Mais tout le monde a un rôle à jouer, quelque soit son poste, son job, et sa proximité avec les développeurs !

            N'hésitez pas à réagir et commenter, ça me fera plaisir, et pourra être l'occasion d'échanger sur le sujet.




            (1) L'origine pour moi, cet article de Nicolas Martignole que je remercie aujourd'hui ! 
            (2) Jean-Baptiste DUSSEAUT, La voie du programmeur ici et
            (3) Antoine Vernois , Software Craftsmanship (j'espère que la vidéo sortira bientôt)
            Voir l'article
            Mon retour sur Agile Tour Montpellier 2013
            21 oct. 2013

            Le 18 octobre 2013, j'ai passé une excellente journée à l'Agile Tour Montpellier 2013, en voici quelques éléments de retour.

            Avec la longue route que j'avais à faire, je suis arrivé pendant la keynote de Pablo Pernot sur "La Horde Agile". L'ayant déjà vu à Marseille, je suis allé directement prendre un café et m'installer pour ma session.

            Et comme ça, je n'ai pas entendu "L'agilité c'est pas le code" ... ;-)


            "L'apprentissage du TDD en Coding-dojo" - Xavier Nopre

            Après l'Agile Tour Marseille, c'était la 2e fois que je jouais cette session. Pour moi, les 2h sont intenses tellement je veux partager et expliquer de choses concernant les tests unitaires et le TDD.
            Salle bien remplie : cool !
            (Photo Etienne PERRA)

            Je commence ma session par des petits sondages pour connaitre un peu le public. Cette fois, j'avais un maximum de développeurs qui, apparemment, écrivent peu de tests unitaires, galèrent pas mal, et ne font pas de TDD (ce qui est probablement lié au "tests after" et donc au TDD ...).

            Je suis surpris de constater que les tests unitaires sont encore très peu répandus. Sans s'en rendre compte, on peut se retrouver à fréquenter toujours un peu les mêmes cercles de personnes, ou de communautés, et finir par croire que l'écriture de tests unitaires, voir la pratique du TDD, sont bien répandues ... Et bien non !

            Dès le début de la session, les questions tombent, assez nombreuses. Elle révèlent un intérêt certain pour les tests unitaires et le TDD, les développeurs sentent que ça peut être intéressant, mais les questions montrent également une vraie galère, un manque de formation, et un manque d'espace d'entrainement. Et je comprends d'autant mieux toutes ces difficultés car moi-même, j'ai dû les surmonter lors de mon parcours personnel.

            Le coding-dojo, une bonne opportunité
            pour expliquer des points précis
            (Photo : @seb_fournel )

            Le positif de tout cela, est que ça me conforte dans l'envie d'animer de telles sessions, et que ça me motive pour continuer à essayer de propager le partage d'informations, de connaissances et d'expériences dans ce domaine ... Passionnant !

            "Et un carpaccio ! Un !" - Géry Derbier - @Gery7



            Après une matinée entre développeurs, et des échanges intéressants le midi sur des sujets similaires, mon programme de l'après-midi est resté en lien avec la technique ! J'assume ! ;-)


            Après une courte introduction, Géry nous propose un exercice vraiment basique (calcul de prix avec taxe et réduction), mais qu'il nous demande de découper en étapes, les plus petites possibles (d'où la notion de "carpaccio") pour pouvoir montrer quelque chose sur des cycles de quelques minutes.


            Le tour de salle pour écouter les propositions est très surprenant, les étapes proposées peuvent être encore découpées en 3 ou 4, elles sont donc déjà bien trop grosses ! Cela m'a surpris car, de mon côté, j'avais effectivement imaginé des étapes vraiment petites. Et ma binôme (désolé, j'ai oublié son nom ....), qui était à ma session TDD le matin, me fait remarquer que c'est peut-être en lien avec mon approche TDD : mais oui, bien sûr ! Le TDD impose également d'avancer par toutes petites étapes, intéressante révélation !

            Je n'en dirais pas plus pour ceux qui auraient l'occasion de pratiquer cet atelier que je recommande. Juste, que Géry nous explique, graphes à l'appui, qu'une approche classique (avec démonstration et livraison tardive) pénalise l'apprentissage (qui est quasiment nul pendant une longue durée), alors que l'approche agile, avec démonstration à court terme, favorise l'apprentissage sur différents points : la technique, l'écosystème, le produit ciblé, l'équipe, etc ... Vraiment très intéressant !

            Lien intéressant : http://alistair.cockburn.us/Design+as+Knowledge+Acquisition

            "Software Craftsmanship" - Antoine Vernois - @avernois

            Quand je vois "Software Craftsmanship", j'ai du mal à ne pas aller voir ... Et j'avais déjà croisé Antoine ici ou là, mais je ne l'avais jamais vu en conférence.

            Et bien, je n'ai pas été déçu. J'espère que cette session a été filmée et sera mise en ligne, et je recommande vivement à tout le monde de la voir, ou mieux, d'assister à cette session, si Antoine la rejoue. Même si ça trolle pas mal (bon, pour le .Net et les architectes, ça se comprend .... oups ...), Antoine enchaîne des vérités (tellement vraies mais tellement négligées) avec humour (mais pas que) et mimiques théatrales. Comme m'a dit un voisin à la fin : "ça fait du bien !".

            Quelques idées :
            • Indépendant, Antoine ne sait pas quoi mettre sur sa carte de visite puis finit par mettre "Artisan logiciel" : ben oui !
            • Le développement est une passion, assumons-le
            • Tests unitaires : pas le temps ? Ok, alors prenez le temps de faire les choses bien
            • La meilleure manière d'arriver en retard c'est d'agir en homme pressé
            • La seule manière d’aller vite c’est d’y aller en faisant les choses bien. Oncle Bob
            • "Faut que ça marche", oui, mais faut que ce soit bien fait ! 
            • Tout est dans le manifest agile (valeurs et principes) mais souvent mal perçu
            • Hé ! Développeur, on ne te responsabilise pas ? Barre toi ! Va voir ailleurs ! Toi seul est responsable de ta carrière ...  
            • Faire simple c'est pas une injure, c'est un compliment
            • Des architectes, oui, mais si ils codent !
            • etc ...
            Le code legacy selon Antoine ... ;-)

            "LE" lien à visiter : http://manifesto.softwarecraftsmanship.org/
            Une communauté "fr" : French Software Craftsmanship

            "Métier Développeur" - Brice Favre - @briceatwork

            Après la super et regonflante session d'Antoine, je ne pouvais qu'aller voir Brice qui nous proposait d'échanger sur le métier de développeur !

            Une session courte, dans une ambiance trop chaude, et des participants probablement déjà fatigués en cette fin de journée, mais des échanges intéressants sur le métier de développeur, l'âge du développeur, le lien entre le développeur et le client (ou pas), le développeur qui doit se mettre à la place des utilisateurs (ou pas), ce que l'agilité peut nous apporter, le développement comme passion (tient, encore ...), la difficulté d'être reconnu, les possibilités pour évoluer (ou pas), etc ...

            Très intéressante, cette session était pour moi un peu frustrante, j'aurais aimé en dire plus, échanger plus en détails avec certains, aller en convaincre d'autres (dans le genre "ton job ne te plait pas ? barre-toi, c'est TA carrière"), mais je suis content de voir que ce courant de pensée est de plus en plus courant, et de plus en plus visible, j'aurais aimé entendre cela il y a plusieurs années, ça m'aurait aidé ...

            Conclusion

            Une journée très riche en découvertes, en rencontres, en échanges. Je me suis volontairement fait une journée "je suis développeur, j'aime la technique et je l'assume" et ça m'a fait du bien.

            Un grand merci à tous ceux que j'ai pu croiser, voir avec qui j'ai pu discuter un peu, je ne les nommerai pas, je suis sûr d'en oublier ...

            Et un grand merci à l'équipe d'organisation pour avoir retenu ma session, et ainsi m'inciter à venir à #atmtp, et bravo pour l'organisation au top (lieu sympa, bonne logistique avant et pendant, repas sympa en extérieur, équipe super dispo pour tout et n'importe quoi, ...). Bravo et merci !


            Voir l'article
            Tests unitaires : comment en ajouter sur du code existant?
            08 oct. 2013
            Suite à cette question de Jérôme Avoustin, Nicolas Noullet pose une autre question très intéressante :
            "Comment faire avec une énorme base de code sans test ? N'en écrire que pour les bug fixes et nouvelles features ?"
            Cette question rejoint celles qui me sont souvent posées lors de mes formations en entreprises ou lors des conférences.

            Les tweets étant trop courts pour un tel sujet, je poste quelques éléments de réponses ici, en espérant en éclairer certains, et susciter des réactions ...

            Le mieux ...

            Avant tout, il faut bien avoir en tête que l'ajout de tests sur du code existant (legacy) est le plus dur !

            Un premier point important à prendre en compte est donc le niveau de maturité des développeurs en tests unitaires. S'ils sont débutants, il vaut mieux qu'ils commencent sur du code neuf, pour un nouveau projet.

            Mais la réalité du quotidien est qu'on n'attaque pas souvent un nouveau projet ...

            Une première approche

            Sur un projet existant, la solution peut consister à écrire les nouvelles fonctionnalités non pas dans des classes existantes, mais dans de nouvelles classes qui seront des "collaborateurs" de la classe existante. Le code de cette nouvelle classe sera plus facilement testable, d'autant plus s'il est écrit en TDD . Si le développeur a un niveau suffisant, et que le code existant le permet, l'inter-action entre la classe existante et la nouvelle classe peut être testée en "mockant" la nouvelle classe. La meilleure approche, mais pas du tout la plus simple, étant de commencer par là en TDD bien sûr !
            Truc : éviter le statique ! 

            Ensuite ...

            Une autre approche consiste à écrire des tests unitaires de plus haut niveau, couvrant une plus grande partie du code (mais la moins grande possible ...), "tests d'intégration" ou "tests fonctionnels", en évitant les "tests IHM" (tests par l'IHM). Une fois ces tests écrits, on peut alors se lancer dans un refactoring pour découper et découpler le code existant, pour extraire les traitements dans des classes séparées, en visant le principe "1 classe = 1 rôle", et ainsi aller vers une architecture (plus) testable.

            Attention, car pour que ces tests soient "bons" et jouent pleinement leur rôle de "filet de sécurité" pour le refactoring, il est nécessaire d'avoir déjà une bonne expérience des tests unitaires et de ce que sont les "bons" tests ...
            Truc : ciblez le code de traitements algorithmiques, plus facile à tester unitairement, et attaquez vous plus tard au code qui interagit avec une base de données ou un équipement extérieur ...

            La couverture de code

            Pour ceux qui auraient un doute, il s'agit de mesurer le % de code exécuté en jouant un test, une série de tests, ou tous les tests. Mais les outils pour cette mesure peuvent nous fournir une autre information, complémentaire et extrêmement intéressante : quel code est exécuté (en général en vert), et surtout, quel code n'est pas exécuté (en rouge), donc pas couvert par les tests.

            Dans la première approche évoquée précédemment, le code nouveau, ou extrait d'une classe, doit impérativement être bien couvert.

            Dans la seconde approche, la visualisation des lignes de code, des classes, voire des packages non couverts, peut nous aider à renforcer les tests de haut niveau pour garantir un meilleur filet de sécurité pour le refactoring à venir.

            Conclusion

            Les tests unitaires sont indispensables ! Se mettre à en écrire n'est pas facile. Le TDD est la meilleure solution, c'est une partie intégrante de la pratique de développement (et de conception), mais c'est véritablement un "état d'esprit" qu'il faut acquérir par la pratique et l'entrainement.

            Accrochez-vous, ça vaut le coup !
            Voir l'article
            Mon retour sur Agile Tour Marseille 2013
            07 oct. 2013
            Jeudi 3 octobre 2013, je suis allé passé ma journée à l'Agile Tour Marseille 2013 où j'animais une session "TDD en coding-dojo". Voici quelques éléments de retour en suivant mon programme de la journée ...

            Keynote "La horde agile" par Pablo Pernot

            Après un accueil café-madeleines, nous avons attaqué la journée avec Pablo pour une keynote digne de ce nom, du moins comme je les aime : sujet en lien avec l'agilité, mais sujet décalé par rapport à ce qu'on peut avoir dans les sessions.

            Pablo remonte le temps pré-historique pour retrouver certaines valeurs de l'agilité, et certains principes, dans les us et coutumes de nos lointains ancêtres, qui nous ont beaucoup laissé en héritage, au fond de nous, et que souvent nous oublions ou repoussons.

            Un enchaînement de réflexions intéressantes, même si je n'ai pas toujours tout capté (fatigue de la route, réveil matinal ? ....).



            "BDD appliqué" par Benoit Gantaume

            Passionné par le développement logiciel, les techniques, les outillages, et connaissant Benoit, c'est sans hésiter que je suis allé le voir nous parler de BDD.

            Benoit partage un retour d'expérience, "qui n'engage que lui", sur ses expérimentations et sa mise en oeuvre du BDD. Il nous rapporte que l'aspect "rédaction de spécifications exécutables compréhensibles par le client" est un apport très positif, mais par contre, ces spécifications exécutables ne lui servent pas du tout en phase de recette avec le client, mais lui sont bien utiles pour ses propres développements.

            Benoit travaillant souvent seul (comme moi), il nous partage la difficulté d'être alternativement "spécifieur" ou "développeur", les petites voix de chaque rôle venant s’entremêler sans cesse.

            Je pense que la présentation de Benoit en a éclairé plus d'un sur le sujet. Pour ma part, cette session a augmenté ma motivation pour dégager du temps et expérimenter par moi-même ce sujet très important pour notre métier.

            J'aurais juste aimé que Benoit nous montre l'exécution de ces spécifications, voir nous fasse une petite démonstration en live du passage de la spec rédigée dans un fichier texte, au test qui échoue (voire réussit) en passant par la création et l'écriture du "code glue".

            "Améliorez et industrialisez vos feedback produit" par Jean-Philippe Gilibert

            Après une courte introduction, Jean-Philippe passe tout de suite à la démo : une session qui attaque par une démo, c'est pas mal du tout !

            Et sa démo est claire et impressionnante ! Dans un produit "standalone" (client lourd en .Net) et autonome (travaillant à partir d'un fichier local, sur le poste utilisateur, comme un traitement de texte par exemple), assez tôt dans le projet, l'équipe a intégré un système de rapport d'erreurs, soit déclenché manuellement par l'utilisateur, soit proposé automatiquement lorsqu'il y a une exception. Pour l'utilisateur, la manip est extrêmement simple : il lui suffit de saisir un résumé du problème, puis un mail est généré, prêt à partir, avec toutes les pièces jointes nécessaires. C'est tout.

            Lorsque le développeur reçoit le mail, il peut trouver dans les pièces jointes tout le nécessaire pour reproduire immédiatement le problème, et notamment le fichier de travail de l'utilisateur et le scénario d'actions que l'utilisateur a réalisé jusqu'au problème, ce scénario est alors rejoué par l'application lancée en mode debug dans l'IDE.

            La solution est très intéressante car très simple pour tout le monde. Et ce que j'ai trouvé malin, c'est que le scénario est un ensemble de commandes à jouer, présentées sous forme de tests fonctionnels en C# .Net (c'est donc du code de test qui est généré lors du report d'erreur par l'utilisateur). Le développeur peut donc par exemple commenter ce code et l'intégrer à sa batterie de tests existants.

            Bien sûr, le cas d'une application standalone et autonome se prête plus facilement à une telle mise en oeuvre qu'une application WEB client-serveur, mais le sujet est intéressant et les idées sont à creuser.

            "Sommes-nous (tous) nés pour collaborer ?" par Romain Vignes

            Courte session pendant laquelle Romain s'est penché sur le lien entre les profils possibles pour chaque membres d'une équipe, et la communication et l'efficacité au sein de cette équipe. Il s'est un peu plus attardé sur le profil "extraverti / introverti", les difficultés qui peuvent en découler, les points d'attention, les solutions, ...

            Une des valeurs de l'agilité porte sur la communication entre les individus. Il est évident que l'aspect humain prend une place importante dans une organisation agile. S'intéresser aux profils, aux personnalités de chacun, mieux comprendre ce qui peut se passer, ce qui peut bloquer, ce qui peut marcher, est évidemment très intéressant ! Dommage du peu, cette session mériterait plus de temps ! ...

            "L'apprentissage du TDD en Coding-dojo" : ma session

            J'ai commencé l'après-midi en animant ma session avec pour objectif de montrer et faire expérimenter, à la fois le TDD, mais également le coding-dojo.

            J'ai encore et toujours un grand plaisir (peut-être de plus en plus) à partager mon expérience des tests unitaires et du TDD, et de le mettre en pratique en codant ensemble !



            La salle était bien pleine, les gens ont bien joué le jeu, et le ROTI était positif, mais toutes les personnes présentes ne se sont pas exprimées.

            Je dois juste revoir et raccourcir la partie théorie pour avoir un peu plus de temps pour la pratique ...


            Pour ceux qui pourront, RDV le 18 octobre à l'Agile Tour Montpellier, et le 21 novembre à Agile Grenoble !

            "Découvrir Scrum grâce aux LEGO®" par Romain Vignes

            Pour finir la journée en douceur, je suis allé "découvrir Scrum grâce aux Lego" avec Romain. A plusieurs reprises, j'avais entendu parler de cet atelier, et vu des photos. Je voulais l'expérimenter.

            L'atelier est très intéressant pour découvrir plusieurs notions et principes de Scrum : le Product Backlog, le Product Owner, les estimations, la vélocité, l'engagement, les itérations, le "done", etc ...

            La session était un peu courte, surtout qu'après la 2e itération, de nombreuses questions ont émergé donnant lieu à des échanges très intéressants.

            Une session que je recommande pour ceux qui veulent découvrir Scrum en s'amusant !

            Conclusion

            Une bonne journée, toujours et encore des idées ou réflexions à collecter, et de nombreuses rencontres et échanges toujours intéressants !

            Merci à toute l'équipe pour l'accueil et bravo pour l'organisation !

            Merci à Thierry pour le co-voiturage.

            Crédit photo : L'Esprit Agile : http://www.flickr.com/groups/esprit-agile/pool/

            Voir l'article