L’agilité, une question de feedback

J’avais évoqué, lors d’une présentation en 2012, la question du feedback et son rôle majeur en tant que moteur de l’émergence.

J’aimerais revenir sur ce sujet qui me tient à coeur et le développer plus avant ici. Je vais aussi tenter de lui donner, modestement, un petit éclairage historique.

Les boucles du feedback

Pourquoi focaliser sur le feedback ? En fait, nous pouvons interpréter une grande partie des pratiques d’ingénierie et de projets agiles sous forme de boucles de feedback imbriquées. c’est ce que j’avais fait lors de mon lightning talk sur l’émergence. En voici l’illustration.

La Boucle de feedback

Nous reviendrons sur cette illustration un peu plus tard. Car on peut aussi présenter ces boucles  de feedback autrement. Elles ne sont pas le fruit de ces 10 dernières années. L’émergence progressive de ces boucles de feedback a commencé il y a bien longtemps. Longtemps avant que l’on parle d’agilité.

Un regard historique sur les boucles de feedback

Compilation interactive

La plupart d’entre-vous n’avez pas connu cette époque, mais vous savez certainement qu’il fut un temps on l’on saisissait les programmes sur ceci

Punch Card

Chaque carte représente une ligne de code, plus exactement 80 colonnes de texte. Le processus est le suivant :

  • On écrit son programme sur papier.
  • Dès qu’on l’a rédigé (et vérifié, croyez-moi, c’est mieux), on va le saisir sur un terminal produisant une carte par ligne de texte.
  • On donne la pile de cartes au centre de calcul. Ce dernier va programmer sa compilation et son exécution. Ce ne sera pas pour tout de suite, probablement dans quelques jours.
  • Quand le job est passé … on vous donne le résultat … ou pas !

Une de mes anciennes collègues m’a ainsi racontée qu’elle a reçu un jour en retour sa pile de cartes entourée d’un élastique et d’une note rageusement libellée : “fait planter la machine !”. 

Une anecdote hélas probablement pas si rare que ça…

J’ai à peine connu cette époque. mais à mes début, j’empruntais un ordinateur de poche 2 jours par semaine. Je n’avais que ce créneau à ma disposition pour saisir et tester les programmes que j’avais écrit sur papier pendant le reste de la semaine. C’est un peu le même cas de figure.

Cette période est révolue depuis longtemps. Au début des années 80 nous sommes passé de la compilation batch à la compilation interactive. Ou à peu près. On est passé de délais de feedback de quelques jours à quelques minutes (et quelques heures dans le cas de gros projets)

Coloration syntaxique

Il y a certes eu de discrets essais sur des environnement confidentiels dans les années 80 et même avant, mais comme beaucoup j’ai découvert la coloration syntaxique avec un IDE mainstream : Borland C++, au début des années 90.

Je me souviens avoir assisté à la présentation de lancement de l’IDE. Le public a littéralement réagit à la seconde où le présentateur a dévoilé la fonctionnalité.

Coloration syntaxique

C’est le feedback sur la syntaxe d’écriture du programme que cette fonctionnalité adresse. Passer de quelques minutes, c’est à dire le délai entre deux compilations, à quelques secondes est une amélioration conséquente.

Complétion de code

De la coloration à la complétion, il n’y a qu’un pas. C’est le feedback sur notre implémentation que cette fonctionnalité adresse en nous proposant les méthodes disponibles.

Code completion

Vous allez me dire qu’il ne s’agit pas de feedback ici. Vous avez raison. C’est mieux, cette fonctionnalité anticipe le feedback, le rendant inutile. Disponible assez tôt dans les environnements Smalltalk, il faudra attendre la moitié des années 90 pour voir cette fonctionnalité se démocratiser.

Compilation continue

Egalement amorcé par Smalltalk, c’est dans Visual Age Java que j’ai vu pour la première fois cette fonctionnalité faire son apparition, vers la fin des années 90. Cette fois c’est la justesse grammaticale sur laquelle le feedback passe de quelques minutes à quelques secondes.

Agilité et feedback

J’ai dit que nous reviendrions sur l’illustration des boucles de feedback. Nous allons le faire. Mais pourquoi s’intéresser au feedback, en quoi ce mécanisme est-il important et si particulier à la pensée agile.

Parce qu’en tant qu’être humain, et même en fait en tant qu’organisme vivant, c’est notre principal mécanisme d’adaptation. Et l’adaptation au changement, ça figure quelque part dans notre manifeste agile, j’en suis pratiquement sûr…

La rétrospectives

Cette pratique n’est pas à proprement parler nouvelle. les rétrospectives de projets (alors appelés post-mortems) ont probablement plusieurs décennies d’existence. En quoi est-ce différent ici ? Pourquoi faire des rétrospectives plus souvent ?

Agile retrospective

La rétrospective est le mécanisme d’adaptation de notre processus. Un post-mortem de projet sert surtout à se lamenter, la rétrospective d’itération sert à adapter notre processus et nos pratiques agiles.

Cycles itératifs

J’entends souvent les équipes parler de “lotir” les itérations. C’est ce que l’on fait dans les processus itératifs. Seulement le lotissement n’a rien à voir avec l’adaptation.

Le cycle itératif agile utilise ce que l’on a appris de l’itération qui vient de se dérouler pour réévaluer les priorités et la pertinence des items figurant dans le backlog ou comme opportunité d’émettre de nouvelles idées, d’aller plus loin dans les fonctionnalités venant d’être développées.

Acceptance tests

Nouveau venu de nos pratiques agiles, le test d’acceptance nous permet d’avoir du feedback sur l’implémentation des stories, lorsqu’ils sont exécutés. Mieux encore lorsqu’on les écrit, ces tests d’acceptance donnent du feedback sur les user stories elle-même ! Ecrire des tests d’acceptance, c’est instancier les spécifications, lever les ambiguïtés, se décider sur les cas aux limites, générer de nouvelles questions.

Integration continue

Il y a un temps pas si lointain où l’intégration représentait une phase majeure, longue et risquée des projets. Le feedback sur le fonctionnement conjoint des différentes briques se faisait alors sur des cycles allant de 3 mois à deux ans.

C’est avec émotions que nous repensons parfois à ces périodes particulières des projets qui occupaient nos soirées et nos week-ends avec enthousiasme, au lieu de manger des chips et boire de la bière devant un match de foot…

Late integration

Avoir la température, non seulement sur l’intégration, mais sur la qualité du code et la couverture de test, cela fait aujourd’hui partie de notre quotidien. Next !

Tests unitaires

En parlant de quotidien, en voilà un sur lequel je ne vais pas non plus m’attarder : les tests unitaires nous donnent du feedback sur le fonctionnement du code : fait-il ce à quoi nous nous attendons qu’il fasse ? C’est aussi de l’acquis : next again !

Pair programming

On pense souvent au pair programming comme à une technique de collaboration. C’est vrai. Mais c’est aussi et surtout une technique de peer review en temps réel et en continue. Un feedback sur l’écriture de code et les choix de conception fait en temps réel.

Mais aussi …

Le feedback des pratiques agiles ne s’arrête pas là. Après tout, toutes ces techniques sont plus ou moins déjà identifiées comme des techniques de feedback.

Management visuel

Les projets agiles aiment s’afficher. C’est aussi une forme de feedback

  • De la part de chaque membre de l’équipe envers tous les autres.
  • De la part de l’équipe vers tous ceux qui souhaitent savoir ce qu’il s’y passe.
obeya

Lean startup et le validated learning

A plus grande échelle, le cycle agile peut servir à donner du feedback, non plus à l’échelle du projet, mais à celle du business. Lean Startup étend la portée des cycles de feedback au-delà du déploiement, jusqu’à l’usage du produit afin de vérifier les hypothèses produit : persévérer ou pivoter.

De la seconde à l’entreprise

L’agilité fonctionne en harmonie avec le feedback. Mieux, elle guide chaque action par cette simple interrogation : comment vais-je évaluer que je suis satisfait du résultat ? C’est la mise en oeuvre du PDCA de Deming depuis les cycles les plus courts jusqu’aux décisions les plus impactantes.

A la conquête du Story Mapping

Il n’y a pas (encore) d’ouvrages traitant du Story Mapping, un technique développée par Jeff Patton. Elle comble une lacune de l’approche fonctionnelle agile basée sur les User Stories qui proposent une manière de cartographier ceux-ci sur des axes orthogonaux : le processus et la réalisation incrémentale.
Pour moi, il s’agit d’un outil supplémentaire à embarquer dans ma besace de pratiques agiles. Je ne vais pas les considérer comme un passage obligé des projets agiles, tout comme je ne suis pas prêt à accepter l’idée que les User Stories sont le moyen unique d’exprimer un besoin utilisateur (ce qui nous conduit par ailleurs à la notion de “story technique” que je rejette purement et simplement).
Le Story Mapping se situe au même niveau d’usage que les Cas d’Utilisation, une technique écartée par la plupart des agilistes, mais pas par moi (je reste en bonne compagnie sur ce point). Cette technique présente certains avantages par rapport aux cas d’utilisation, et ces derniers exhibent d’autres atouts. Nous reviendrons peut-être un autre jour là-dessus : Jean-Claude Grosjean et moi-même avions même évoqué l’idée de faire une présentation commune sur ce sujet un jour !
Pour le story mapping :

  • Structuration bottom-up des user stories.
  • Agencement des stories dans un processus (quand celui-ci reste simple)
  • Agencement par itération visible dans la map.
  • Un processus de travail collectif.

Pour les cas d’utilisation :

  • Une structuration “divide and conquer” top-down du besoin fonctionnel.
  • Une bonne structuration par unité fonctionnelle cohérente en lien avec des acteurs.
  • Un bonne structuration fonctionnelle intrinsèque avec l’articulation des scénarios.
  • Un niveau de structuration fonctionnel qui peut servir de charnière avec de nombreuses activités : UX, acceptante testing, etc…

A défaut d’avoir la référence ultime, j’ai essayé de collecter ici des ressources sur le sujet. Notons d’ailleurs au passage que la 3ème édition du livre de Claude Aubry évoque cette technique.

L’article de référence de Jeff Patton

Il décrit les étapes de la technique. Il n’a pas simplement un “intérêt historique”. Il reste tout à fait pertinent. En fait, je conseille de commencer par lire cet article !

Jeff Patton présente également son approche sur son site.

Pour ceux qui préfèrent le format “slides”, c’est juste ici:

La présentation de Steve Rogalsky

C’est un peu le “Story Mapping from the Trenches” : une présentation très visuelle sur la façon de faire du story mapping, où le présentateur montre comment lui-même opère concrètement. Une bonne illustration de l’article de Jeff Patton !

Par ailleurs, Steve Rogalsky a développé la matière de cette présentation via une série de posts :

Laurence Hanot : construisez votre produit en racontant des histoires !

J’avais assisté à la présentation de Laurence à Agile France, c’est une occasion de mettre en avant sa présentation qui est une introduction à la technique

De l’impact mapping au Story Mapping

Cette présentation m’a été indiquée par Gojko Adzic. A voir et revoir car elle fait le lien avec l’impact Mapping

Autres ressources

Post #500

Il me semble qu’il n’y a pourtant pas si longtemps que j’ai marqué d’une pierre blanche la première année de mon blog. Oui, c’était il y a à peine plus d’un an. Mon rythme est donc disons… honorable ! Revoyons tout cela en chiffres !

Mon blog en chiffres !

Il y a un an, je me réjouissais de mes 221 posts. Un an et deux semaines plus tard, ce sont donc 279 nouvelles entrées qui s’y sont ajoutées.
Au niveau rythme, après un petit creux de début d’année, je tourne à une moyenne d’un peu plus de 20 posts par mois. Considérez quand même qu’un post sur trois est une citation et cela rend la chose moins démente.

Histogramme posts tumblr

Plus intéressant à mon goût : l’évolution des Notes de lectures si je les compare aux autres billets (en excluant les citations). Sur les 12 derniers mois, la tendance s’est inversée par rapport à l’année précédente. Les billets dépassent en nombre les notes de lecture, parfois de beaucoup.

Stats billets vs Note de lecture

La fréquentation

Elle semble en augmentation !

Statistique de fréquentation 2012-2013

En fait, il faut la rapprocher de celle de l’année précédente. Toutefois comme je n’ai mis en place les analytics qu’en Mars 2012, il me faut “normaliser” les données sur les deux années. J’ai donc multiplié les données de la première année par 1,5 ; ce n’est pas tout à fait juste, mais disons que c’est une approximation acceptable.

Stats 1ère année vs 2nd année

Les chiffres font apparaitre une augmentation substantielle des visites, ou plutôt des visiteurs uniques (le chiffre que je préfère suivre). 

Les rebonds paraissent important (en baisse insignifiante), mais c’est plus probablement lié au fait que la plupart des visites viennent des liens Twitter. Malgré tout, deux chiffres me surprennent : la diminution très sensible des pages vues par visite : de 2,72 à 1,7 ! Cela se traduit de manière naturelle par une diminution du temps passé à chaque visite : de 2,72 mn à 1,77 mn. Normalisé à une page, cela fait 57 sec par page sur la première année et 1,13 min par page sur cette dernière année.
Qu’en est-il des browsers ? C’est assez stable, avec un poil de perte de terrain de Firefox et un poil de regain côté Safari, mais pas de gros changements à part ça…

Stats browsers 2nd année

See you next time

Déjà 500 posts. Peut-être devrais-je réduire le rythme ? Hélas, j’ai encore quelques sujets sur la pile. La prochaine synthèse est prévue pour mon millième post. Espérons que ce soit dans un bout de temps !

Google moves from MySQL to MariaDB

nosql:

Jack Clark for TheRegister quoting Google senior systems engineer, Jeremy Cole’s talk at VLDB:

“Were running primarily on [MySQL] 5.1 which is a little outdated, and so we’re moving to MariaDB 10.0 at the moment,”

I’m wondering how much of this decision is technical and how much is political. While Jack Clark’s points to the previous “disagreements” between Google and Oracle, when I say political decisions I mean more than this: access to the various bits of the code (e.g. tests, security issues), control over the future of the product, etc.

Original title and link: Google moves from MySQL to MariaDB (NoSQL database©myNoSQL)

J’avais déjà évoqué la chose précédemment, aujourd’hui le mouvement est clairement enclenché : c’est la totalité des instances MySQL qui passent sur MariaDB !

Les raisons qui conduisant à ce changement n’ont probablement pas la limpidité de la déclaration officielle. Le “vieillissant” MySQL est certainement l’un des facteurs, cela m’étonnerait que ce soit le principal. Pour ma part j’évoquerais en priorité :

  • Une dépendance à Oracle qui gêne le géant de Mountain View
  • Un manque pratiquement total de possibilité d’agir sur la base de code, les tests n’étant plus accessibles.

En contrepoint, le fait de travailler avec un petit éditeur qui a besoin d’une solide référence et qui est donc prêt à se plier au désidérata du géant de l’Internet a un intérêt évident…

Google moves from MySQL to MariaDB

Moving on…

Il n’est pas dans mes habitudes de parler de moi dans ce blog. Je vais le faire aujourd’hui, ce qui fait de ce post un texte un peu particulier.

Parler de soi n’est pas s’apitoyer. Pas nécessairement, en tout cas pas ici. Si je compte bien, c’est la première fois que je me livre à l’exercice. Un post vraiment spécial pour moi, donc.

Je suis venu te dire que je m’en vais

J’ai passé 5 ans au bureau du Scrum User Group, un peu plus, même. J’y étais depuis sa création par Luc Legardeur, jusqu’à aujourd’hui sans interruption. Cela faisait de moi l’ancien du groupe.

Et cela se termine aujourd’hui.

Etre l’ancien ne me confère aucun statut particulier, et c’est tant mieux. Par contre il n’a jamais été concevable pour moi de figurer au bureau de l’association et de rester inactif. Je vois cela comme une forme d’escroquerie : “voyez, je suis au bureau du SUG, d’ailleurs je l’ai mis dans mon profil LinkedIn (ce que je n’ai jamais fait, d’ailleurs)”. Si c’est pour ne pas contribuer aux actions de l’association…

No empty Space

Quitter un engagement de si long terme me donne une petite impression de vide, d’inconfort. Même si je suis convaincu d’avoir pris la bonne décision, lâcher cette situation réconfortante ne s’est pas fait aisément. Je sais, vous allez me dire que ce n’est pas comme si j’avais quitté mon boulot. C’est vrai, mais quand même…

Là où cela me laisse perplexe, c’est que ce changement qui semble normal avec un regard d’agiliste, a exigé de me faire violence. La stabilité, j’aime bien. Mon petit confort, j’aime bien aussi. Aller vers l’inconnu, confronter une situation nouvelle : pas trop. Oh, une fois que c’est passé, que j’ai réussi de nouvelles chose, accompli une action dont je suis fier ou pris un râteau sans trop de dommages, ça va. Je suis même fier en fonction des cas (ou raisonnablement pas trop honteux).

Bref, suis-je vraiment un agiliste au fond de moi ? Est-ce le “moi conscient” qui a pris la barre, sachant que la démarche agile est la bonne, mais heurte le “moi inconscient” qui lui est bien frileux ? Je vais arrêter ici ma psychologie à 2 balles, je vous ai probablement perdu. En fait je me suis perdu moi-même.

Pourquoi ?

C’est le moment que vous attendez : celui où je vais cracher mon venin ! Cela ne va pas arriver. Non seulement cela ne serait pas correct, mais il n’y a pas lieu de le faire. Nous avons fait de nombreuses choses en 5 ans, et je suis fier d’y avoir participé. Il suffit de regarder le Meetup pour s’en rendre compte ! Que vais-je mettre spécialement au crédit de cette période ?

  • Les personnes que j’ai pu côtoyer au bureau. Plus spécialement, certaines dont j’étais plus proche. Mais je ne vais pas citer de noms.
  • Les rencontres. A l’occasion des soirées, des Scrum Day ou des Scrum Beers. Notre communauté est riche de personnes avides de connaissances et de réflexions.

Je garde un excellent souvenir non seulement des rencontres lors des évènements, mais aussi des échanges avec les orateurs lors des préparations. On m’a régulièrement remercié pour avoir géré les appels à orateurs. La vérité, c’est que ce fut chaque fois un plaisir !

Alors, pourquoi quitter ?

Pour des raisons purement égoïstes ! Oui, faire partie d’un groupe et s’entraider sont des valeurs importantes. Mais cela ne doit pas se faire au détriment de nos motivations personnelles. Surtout quand il s’agit de bénévolat. Pour moi, il s’agit de prendre du plaisir à faire ce que je fais, d’avoir envie d’abattre le travail qui est devant moi. C’est aussi comme cela que j’arrive à donner le meilleur de moi-même.

Pour diverses raisons, ce n’est plus le cas. Les choses ne vont pas mal, ni pour moi ni pour l’association. Mais cela ne corresponds pas à mes aspirations actuelles.

La page est donc tournée.

Moving on…

Mon départ du SUG ne va rien changer à l’association. Ce n’est pas un regret, mais une source de satisfaction. Bien faire son boulot, c’est apporter une contribution utile sans se rendre incontournable. Montrez-moi une personne dont l’absence met un groupe en péril, je vous présenterais une personne qui ne fait pas son boulot jusqu’au bout. Dans certains cas, c’est même de la malhonnêteté.

Pour peu qu’il y ait quelqu’un pour reprendre le harnais, tout continuera comme avant. Je l’escompte bien, car j’ai bien l’intention de me rendre aux évènements que l’association organisera !

Très bien, mais quelles sont mes prochaines étapes ?

Pour l’instant, je reste sur mes projets actuels :

  • Deux conférences à préparer, à Bruxelles très bientôt et fin Novembre à Grenoble. Deux sujets différents que j’inaugurerai. Ca fait du boulot.
  • L’adaptation Française de The People Scrum.

Tout cela sans compter ce Blog va bien m’occuper au moins jusqu’en Décembre. Et après ? Je ne sais pas. Je sais simplement qu’il est temps d’aller de l’avant.

Snoopy moving on

Web RTC

“RTC” comme “Real Time Communication” !

Cette présentation faite sur Prezi par Enrico Marocco nous expose les principe d’architecture Peer to peer du Web RTC.

Web RTC, comment en savoir plus ?

Le consortium Web RTC est soutenu par Google et Mozilla, entre autres, avec le but avoué de supporter cela dans leurs browsers respectifs. C’est également un groupe de travail à l’IETF ainsi qu’au W3C.

Voir aussi l’excellente présentation faite par Google lors du Google IO 2013 ; la vidéo de cette présentation est incluse dans les slides. La présentation faite lors du Google IO de l’année précédente mérite aussi que l’on s’y arrête.

En pratique…

Dans la pratique, il s’agit de 3 ensembles d’API :

  • MediaStream API : Elle permet d’échanger vidéo et son, nottament.
  • RTCPeerConnexion : qui permet de maintenir des connexions pair à pair entre machines pour échanger des streams. Cette connexion peut être obtenue avec ou sans serveur intermédiaire en fonction du protocole retenu. Hadopi aura peut-être quelque chose à dire là-dessus…
Web RTC connexion API diagram
  • RTCDataChannel : pour les échanges d’autres types de données, par exemple pour les jeux.

MariaDB, plus fort que MySQL

On ne peut pas dire qu’Oracle se soit attiré la réputation d’une société ayant bien compris le modèle Open-Source. Parmi d’autres, MySQL en est une bonne illustration.

Ayant acquis la base Open Source par le biais de l’acquisition de Sun Microsystems, il me parait que le géant de la base de données a cherché avant tout à en faire un produit, plutôt qu’un projet open source. 3 éléments me confortent dans cette opinion :

  • Oracle seul décide de la roadmap MySQL
  • MySQL est positionné par l’éditeur en alternative à Microsoft SQL Server. Une stratégie perdante, car les produits ont un positionnement très différent.
  • Oracle verrouille les développements (patch ou fork) en ne releasant plus les cas de tests depuis plus d’un an !

La fondation MariaDB

Dès le rachat de Sun, le créateur de MySQL Michael “Monty” Widenius a créé le projet MariaDB. Comme il l’explique son but à l’origine était de conserver la communauté historique des développeurs du noyau MySQL, noyau qui était en passe de disparaitre.

J’avoue que bien que ce fork ait maintenant plus de 3 ans, il a échappé à mon radar. Pas seulement au mien visiblement, car il semble que son existence fut jusqu’à une date récente assez discrète. Il aura fallu la création de la fondation MariaDB pour booster sa visibilité.

Aujourd’hui MariaDB offre une alternative à MySQL

  • Compatible au niveau binaire
  • Offrant de nouvelles fonctionnalités marquantes.
  • Plus active que la base historique sur le volet des bus fixes.

MySQL semble avoir un peu perdu de vue sa nature première : non pas une base de données, mais un conteneur de moteur de bases de données. Tandis que MySQL vogue avec ses vieillissants MyISAM et Innodb, MariaDB nous propose de nouveaux engines: Aria, XTraDB (une évolution d’InnoDB), FederatedX (un engins utilisant d’autres SGBD en back-end), OQGRAPH (un moteur optimisé pour gérer les hiérarchies et les graphes) et SphinxSE.

Google à la rescousse

La communauté open source n’est pas la seule à s’inquiéter de la mainmise d’Oracle sur MySQL. Des sociétés de taille respectables pour lesquelles MySQL est une brique importante ont eu la même démarche.

L’annonce la plus marquante est sans aucun doute celle de Google annonçant un support au projet. Concrètement il s’agit d’y consacrer un développeur. Par rapport aux moyens dont dispose le géant du Web et l’importance structurelle de MySQL dans ses infrastructures, cela parait anecdotique, mais le message est là. D’après Widemius, d’autres société sont prêtes à aller dans le même sens, mais on n’a pas de noms…

Une alternative encore verte

Pour assoir une emprise sur le marché, il faut un packaging de bonne qualité. La fondation MariaDB propose des packaging prêts à l’emploi pour les plateformes Linux (Red Hat, Fedora, Debian, Ubuntu…) et Windows.

Mais point de distribution Mac ! Il faut passer par Homebrew avec compilation des sources et quelques petites manipulations … Ca ne va pas tout seul, autant le dire. Bref, ça va en rebuter quelques un. La fondation MariaDB explique que cette absence est due à leurs moyens limités.

Autre point faible : la documentation. Bon, elle existe, toutefois. Mais elle n’est pas vraiment au niveau. Pas de vrai autorail et les informations d’installations et de configurations sont assez éparses. Dans l’ensemble, les informations sont rassemblées sur le site ask monty. Bref, il y a encore à faire.

Côté bouquins, j’ai trouvé 2 titres sur MariaDB. Rien à voir avec la pléthore de livres sur MySQL.

Y aller ou pas ?

Aujourd’hui, je ne conseillerais à personne d’aller volontairement vers du MySQL, à moins que ce choix soit subordonné à un autre. Nombreux sont en effet les projets pour lesquels MySQL est sinon le choix par défaut, du moins un choix “pré-packagé”.

D’un autre côté, des distributions Linux commencent à venir avec MariaDB comme base par défaut en lieu et place de MySQL. De plus, il y a la “compatibilité binaire” revendiquée par MariaDB. Mais celle-ci doit encore se vérifier de contexte en contexte.

Côté Java, à priori MariaDB est toujours compatible avec le connecteur JDBC de MySQL. Mais il existe aussi un connecteur JDBC natif Maria DB.

La situation pour les autres langages est moins claire. Il existe bien un connecteur C dans ce qui est produit par la fondation, mais pour Python, Perl, etc… Il faut à priori utiliser les utilitaires gravitant autour de MySQL et faire des essais. Si l’on va faire un tour du côté de Stackoverflow, on voit que les choses ne sont pas si simples.

La tendance actuelle est un passage vers PostgreSQL (). Cette base est mieux qu’une alternative et est de plus en plus privilégiée à MySQL, non comme solution de replis mais en tant que solution techniquement meilleure.

Il me semble cependant qu’au vu de la roadmap déjà réalisée par MariaDB et de celle à venir, que cette alternative mérite considération, malgré les faiblesses dont il est fait mention.

Résultats du sondage : comment traduiriez-vous « The People’s Scrum » ?

Tout d’abord un grand merci à tous ceux qui se sont livrés à l’exercice !
Au total, j’ai eu 24 réponses. On peut dire que c’est peu, mais je ne comptais de toute façon pas sur des centaines de réponses, sans compter que nous sommes au milieu de l’été… De toute façon, ce n’est pas la quantité, mais la qualité qui compte !

Une mention spéciale à Julien Tort qui a d’abord lu une partie du livre avant de faire une proposition !

Voici les résultats bruts

Résultat du sondage

C’est à dessein que je n’avais pas laissé visible les résultats, même temporaires afin de n’influencer personne. Cela a peut-être eu un effet sur l’affluence… tant pis !

J’en tire temporairement 3 conclusions :

  • Une des propositions n’a pas du tout retenu l’attention : “Scrum et le peuple” n’était de toute manière pas une très bonne proposition. La 5ème proposition apparait aussi avec un total de zéro, mais c’est une erreur due à une mauvaise utilisation de polldady de ma part !
  • “Le Scrum du peuple” est largement en tête ! Il faut aussi dire que c’est la traduction la plus littérale. Donc, cela ne veut pas dire que je retiendrais ce résultat, mais je ne peux non plus l’ignorer.
  • Il y a un grand nombre de propositions alternatives, elles représentent presque 60% des réponses.

Justement, ces propositions alternatives, quelles sont-elles ? En voici le détail

  • Scrum: (Quand) le peuple s’en mêle
  • Scrum pour le peuple
  • Gens mêlés
  • Scrum pour tous (c’est la proposition de Julien Tort que j’avais évoqué précédemment)
  • Le Scrum des masses
  • Le Scrum populiste
  • Scrum pour les individus
  • Le peuple du/de Scrum (2 réponses)
  • Le Scrum des gens / Scrum sur le terrain / Démocratisation de Scrum ; ces 3 propositions m’ont été faites par une même personne.
  • Le Scrum pratiqué par les gens
  • Les agilistes
  • Scrum : des gens, un mouvement
  • Le Scrum des gens

Depuis, j’ai même encore eu une idée carrément différente : Notre Scrum. Reste maintenant à choisir. On en reparle donc plus tard !

En finir avec la démo ?

Après nous être occupé dernièrement du Scrum Master, j’aimerais maintenant retourner vers les éléments, cérémonies et artéfacts, constitutifs de Scrum. Vous vous rappelez peut-être à cet égard que nous avions abordé le product backlog l’an dernier ?

La démo, puisqu’il le faut…

La démo ? C’est bien !

Crowd waving

La démo, c’est vraiment bien !

La démo, c’est du feedback. Et le feedback c’est le nerfs de la guerre des projets agiles.

Alors, si c’est tellement bien, pourquoi ne fait-on cela qu’une fois par itération ? On devrait faire ça tout le temps !

Mais ce n’est pas le cas.

En fait, comme nous le rappellent Emilie Franchomme et Caroline Damour-Nobi, on ne parle pas de démo, mais de revue de Sprint. Ou plutôt, la démo est (ou est sensée être) juste une partie de la revue de Sprint.

Un anthropologue qui butinerait d’équipe Scrum en équipe Scrum rencontrerait 2 types de populations :

  • Ceux qui sont heureux d’aller à la démo.
  • Ceux qui appréhendent la démo.

En fait, dans les deux cas nous avons un problème. Commençons par le premier, même s’il vous parait probablement curieux d’identifier une équipe heureuse d’aller en démo comme un problème potentiel. Mais ce cas va nous permettre de répondre au point que nous avons laissé en suspens.

La démo c’est cool, on va pouvoir montrer ce que l’on a fait !

Oui, c’est parfois (même souvent) ainsi que l’on aborde la démo : on va dévoiler ce qu’on a réalisé.

Voilà une grave erreur. Nous sommes déjà au coeur du problème. Et ce problème s’appelle “définition of done” !

J’avais abordé il y a quelques temps la question de la définition de terminé. Je vais reprendre ce point de manière légèrement différente :

L’objectif de la démo est de montrer ce qui a été terminé durant l’itération, n’est-ce pas ?

Ce qui est considéré comme terminé doit correspondre à la “définition of done”.

Donc si les utilisateurs (et à fortiori le Product Owner) découvrent en démo les fonctionnalités implémentées, nous avons un problème !

Et ce problème, c’est que la définition de terminé ignore le feedback des personnes utilisant réellement le système. Oh, bien sûr on peut toujours se dire que le trait que nous traçons dans le sable pour délimiter notre responsabilité, c’est l’implémentation du backlog, pas la valeur perçue par les utilisateurs. Ou en tout cas que l’écart de cette valeur perçue sera traité plus tard, à l’itération suivante au mieux.

Bonjour, je voudrais voir mon burndown chart

Bref, si notre objectif c’est de délivrer de la valeur et non du code correspondant à des spécifications nous avons un problème.

Illustrons cela par un bon vieux burndown chart.

Burndown Chart de la démo

Donc, si vous avez tranquillement exclus le feedback utilisateur de la définition de terminé, votre burndown ressemble à la droite en vert. Le petit détail c’est que votre définition de terminé corresponds à de la livraison de fonctionnalité, mais pas nécessairement à de la livraison de valeur.

Si la livraison de valeur est votre focus, justement, alors votre définition de terminé doit inclure ce feedback et à ce moment là votre burndown a l’allure de la courbe en rouge. C’est tout de suite moins classe.

En fait, il y a bien un processus de développement qui met à disposition l’ensemble de produit en fin de cycle de développement : le cycle en cascade !

Grâce à la démo, retrouves le charme oublié du “cycle en V” !

En stigmatisant la démo en fin d’itération, Scrum nous ouvre une brèche pour retomber dans nos vieux démons du cycle en cascade. Oh, bien sûr, telle n’est pas l’intention des géniteurs de Scrum.

En fait, la définition de terminé permet de remettre un poids du bon côté de la balance. Mais la cérémonie de la revue de sprint étant très structurante elle tend à occulter le premier.

La revue de Sprint, en fixant un point de rendez-vous en fin de sprint nous laisse penser que nous pouvons avoir un produit “en chantier” durant l’itération. Traduisez : un produit qui n’est pas stable. Une impression qui est accentuée par l’idée qu’il faut laisser l’équipe tranquille pendant l’itération. On ferme les portes, ce qui se passe pendant cette durée de Sprint ne regarde pas les autres !

Cette pente glissante se traduit par deux symptômes étroitement liés:

  • Une difficulté à pouvoir montrer un produit stable à la démo. Un paradoxe !
  • Un choix de l’équipe d’établir une “période de freeze” avant la démo pour corriger le tir. C’est parfois quelques heures, le plus souvent une demi-journée, voir une journée. Parfois même on augmente la dose.

Ce n’est pas une bonne façon de faire, ce ne sont pas les bonnes mesures préventives. On a juste transformé le Sprint en mini cycle en V ! Et c’est la démo qui nous a tranquillement amené là.

Continuous integration

Oubliez la démo ! Le produit doit être stable tout le temps. Scrum nous dit de faire remonter les problèmes à la surface : supprimez la période de freeze. La démo suivante sera calamiteuse. Travaillez alors la stabilité du produit, non pas une fois par sprint, mais tout le temps.

Nous nous sommes occupé de ceux qui sont heureux d’aller en démo. Que pouvons-nous dire de ceux pour qui c’est la hantise ? Bien sûr, c’est pire !

Direction le tribunal

Parfois, la revue de Sprint, cela ressemble à ça :

Cours de justice

Dans ces moments-là, la revue de sprint n’est plus seulement le moment les utilisateurs découvrent ce qui a été fait mais jugent et statuent sur ce qui ne va pas. Je ne parle pas ici de feedback, c’est à dire d’une dynamique où les invités de la revue de sprint aident à identifier les apports positifs et les points sur lesquels il faudra concentrer l’effort, mais d’un simulacre de revue de sprint où les utilisateurs, les consommateurs devrais-je dire, viennent noter ce qui a été réalisé.

Dans les cas extrêmes, certains des invités sont là dans le but de “prendre l’équipe en faute” ! Vous pensez que j’exagère ? Hélas non.

On ne saurait reprocher à Scrum des perversions qui ne viennent pas du framework, mais des personnes qui sont impliquées. Cela pose plusieurs questions :

  • Lorsqu’une dynamique des personnes impliquées dans la définition du produit ne fonctionne pas, qui doit corriger le tir ? Le Scrum Master ou le Product Owner (car on est côté définition du produit…) ?
  • Le Scrum Master doit-il fixer des protocoles plus cadrés lors de la revue de sprint si elle ne fonctionne pas correctement ?
  • Est-ce une option valable de ne plus inviter une partie prenante si elle affiche sciemment une position négative ?

De temps en temps aussi, le biais ne vient pas des invités de la revue de sprint, mais de l’équipe.

Revue de sprint ou réunion de spécification

“dites-nous ce que vous voulez”. C’est ainsi qu’un Scrum Master a ainsi conclut la partie démo d’une revue de Sprint où les invités avaient été particulièrement silencieux.

Ca part d’une bonne intention. Et effectivement il faut à un moment poser la question, même s’il s’agit plus de comprendre ce dont ils ont besoin plus que ce qu’ils veulent.

Hélas cette simple phrase va changer la nature de la revue de sprint en une seconde. On n’y évoque plus ce qui a été fait, mais ce qui aurait pu être fait. C’est parfois, assez souvent même, intéressant. Cela aurait d’avantage sa place dans un atelier du type “design thinking”. Parfois ce travail d’exploration n’a pas été correctement fait et la revue de sprint en est le symptôme. Mais la revue de sprint n’est le lieu, ni pour collecter les spécifications, ni pour refaire le monde.

Micro-démo

Nous avons vu ce que nous ne devons pas faire, et pourquoi la démo de fin de sprint qui donne une odeur de cycle en V me gêne terriblement. Il est temps de voir ce qu’on peut faire.

N’attendez pas pour avoir du feedback sur les fonctionnalités, la démo de fin de sprint. La “définition of done” doit figurer le feedback sur l’utilisation de la story (que ce soit par le PO ou par les utilisateurs), pas seulement les acceptante tests. Pour cela on organise une petite démonstration impromptue dès que la story est achevée et les acceptante test sont passés. C’est ce qu’on appelle parfois la “micro démo”.

Voici la recette dans les grandes lignes:

  • La micro-démo s’organise “à la volée” dès la story terminée. Pas le lendemain ou dans 2 jours, mais le jour même et si possible dans l’heure qui suit l’achèvement de la story. Avant que le développeur ou le binôme se soit replongé dans la story suivante…
  • Pas de setup particulier: on fait ça sur le poste du développeur, on ne perd pas de temps à mettre des choses en place dans une salle de réunion.
  • On va vite, on limite le temps imparti à 10 minutes environ. Pas de bla-bla. On exécute le scénario sur lequel on s’est mis d’accord en début de sprint. On réponds aux questions précises s’il y en a.
  • S’il y a des ajustements à faire qui apportent de la valeur, l’équipe discute avec le PO de la pertinence de les prendre en compte (cela remet-il en cause le contenu de l’itération…). Si cela est pertinent, on prends ces modifications en compte et cela donnera lieu à une autre micro-démo.
  • Un public limité : développeur, P.O., Scrum Master, testeur, et un ou deux utilisateurs clés s’il y a lieu. Pas plus. De toute façon la place autour du poste du développeur est limitée.

Grâce à la micro-démo, on valide non seulement le fonctionnement de la story (acceptante test), mais son utilisation. Il n’y a plus de surprise lors de la démo.

Mais alors, a-t-on encore besoin de la démo ?

La substantifique moelle de la revue de sprint

La revue de sprint, ce n’est pas seulement la démo. C’est aussi :

  • Exposer la vélocité de l’équipe [Aubry12], p. 125
  • Demander formellement l’acceptation du produit de l’itération [Lacey12], p. 186 ; franchement, c’est moins difficile si l’on est passé par des micro-démo avant !
  • Montrer le produit à des personnes non impliquées dans la définition du produit mais qui ont besoin de constater que celui-ci progresse.

Certes, il n’y a pas que la démo dans la revue de sprint, mais quand même… Cela a-t-il toujours un sens de faire une démo dans la revue de sprint si l’on pratique les micro-démo ?

En fait, oui !

Tout d’abord c’est l’occasion de montrer le produit à des personnes que l’on ne peut toucher qu’occasionnellement, ou qui ne sont pas directement impliquées dans le produit. Ensuite, si la micro-démo permet de voir les fonctionnalités indépendamment, la démo de fin de sprint permet de mettre les pièces du puzzle ensemble et de faire des démonstrations de scénarios plus larges.

Une question de boucle de feedback

En développement agile, tout peut être ramené au niveau de la boucle de feedback. L’achèvement d’une story ne se termine pas avec la boucle de feedback des tests d’acceptance, elle doit inclure celle sur l’utilisation de cette story. Différer ce feedback à la fin d’itération, c’est créer un stock pour la fin d’itération sur lequel on risque de devoir revenir.

Les équipes travaillant en mode Kanban ou en mode mixte Kanban / Scrum tendent à mettre plus d’emphase sur le bouclage des stories, car il y a moins (ou pas) de poids sur ce qui se passe en fin d’itération. En fait, les cérémonies de fin et début d’itération traitent les éléments de travail par lots (un lot étant ce que contiendra le sprint), tandis que le Kanban travaille par flux. Et il est naturellement difficile de combiner travail par flux et travail en lots.

Alors, la démo, c’est mal ?

La démo, ou plutôt la revue de sprint s’avère une bonne chose. Elle permet :

  • De montrer l’avancement du produit à un public large.
  • De collecter du feedback global sur l’itération et l’état du produit.
  • De mettre les pièces du puzzle ensemble

Mais il ne doit pas être l’outil qui transforme le sprint en mini cycle en V. Ne remettez pas le feedback des stories à plus tard, il doit faire partie de la “définition of done” !

Références

[Aubry12] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3

[Lacey12] : The Scrum Field Guide, practical advice for your first year – Mitch Lacey – Addison Wesley 2012 : ISBN : 978-0-321-55415-4