You only live once, but if you do it right, once is enough.
Agile France Open Space
Le mois de Février est généralement calme : un ou deux Meetup et bien sûr l’Agile Games France qui est pour moi l’évènement marquant de ce début d’année. Yannick Ameur a eu la bonne idée d’organiser un Open Space durant cette période calme.

Nous étions une petite vingtaine réunis pour cette soirée sous la houlette de l’association Agile France. Emmanuel Gaillot qui était des nôtres a d’ailleurs rappelé la mission de l’association.

Deux sessions au programme de cette soirée, entrecoupé d’un interlude. On y reviendra.
Comment convaincre sur la qualité du code
J’étais à l’initiative de cette première proposition. Enfin, deux autres sessions avaient lieu aussi en parallèle.
Mon problème :comment faire prendre conscience à une équipe “contente d’elle-même” de l’intérêt de chercher à s’améliorer, à perfectionner son code. Ma situation de départ : un code review où personne n’a rien à dire !
Des idées ont jailli. Je ne les essaieraient probablement pas toutes. Mais certaines méritent indiscutablement l’attention.

Mais l’échange me laisse à penser que lorsque l’on a pas encore éveillé l’intérêt, l’étincelle a bien du mal à prendre. Et il n’y a pas de solutions miracle. Seulement des choses à essayer qui marcheront peut-être, ou peut-être pas…
Interlude
Nicolas nous a gratifié d’un rapide jeux agile entre les deux sessions : le nombre secret. Il me rapelle celui sur les dates de naissances auquel nous avions joué durant le premier Agile Games France ().

Ca n’a pas trop mal marché.

Tester en agile
Pour ce second round, je me suis joins au groupe discutant des tests. Des discussions passionnées et des avis très partagés dans le groupe.
D’un côté les défenseurs de la séparation des pouvoirs : développeurs d’un côté, testeurs de l’autre. Les développeurs se limitent aux tests unitaires, les tests fonctionnels sont essentiellement exploratoires et fait par l’équipe de tests après la fin d’itération. Lorsque l’écart d’interprêtation entre développeurs et testeurs a fait son oeuvre (environ 10 secondes après que les testeurs aient reçu le système à tester), on saisie de gentilles anomalies et le tout peut retourner chez les développeurs pour une nouvelle itération. Itération au terme de laquelle on recommence le cycle. Ca booste à mort.

Autant dire que ce n’est pas ma vision des choses.
Les défenseurs de l’ATDD proposent de regrouper développeurs et testeurs au sein d’équipes pluridisciplinaires, de couvrir aussi bien que possible les items à développer de tests définis en amont (ce qui a aussi la vertu de les raffiner), et de tester “just in time” et non après la fin d’itération. Les tests exploratoires sont là seulement pour compléter les AT réalisés au début et pour, en quelque sorte, tester les tests !
Bref, deux visions inconciliables. Pour ma part, je pense que la première appartient à une époque révolue située quelque part dans le siècle précédent et n’a rien à voir avec l’agilité, ni dans son exécution, ni dans son état d’esprit. Mais cela me donne aussi une petite idée de billet, pour un de ces jours
Pendant ce temps, les sessions se déroulent dans d’autres salles

Fin de soirée
Les résultats de nos cogitations sont visible sur les murs. Ici le fruit d’une discussion sur le story mapping.

Les idées proposées pour cette soirée

Et bien sûr les inévitables discussions de fin de soirée. Peut-être le meilleur moment d’ailleurs !


La galerie de mes photos à Agile Grenoble 2013
Je vous avais infligé mon point de vue sur Agile Grenoble qui avait eu lieu fin novembre 2013 ici et ici ; Voici maintenant la galerie complète de mes prises de vue lors de cette journée
agile-grenoble2013, un album sur Flickr.
I think I should understand that better, if I had it written down: but I can’t quite follow it as you say it.
How Spotify Builds Products
J’avais posté il y a quelques temps un lien vers l’article d’Henrik Kniberg à propos du scaling chez Spotify. Cet article expose la manière “lean startup” dont les produits sont pensés et évoluent :
- Think it : on a une idée !
- Build it : on construit un MVP.
- Ship it : On le met en production.
- Tweak it : Puis on l’améliore continuellement.
C’est même un Kanban au niveau de la société qui permet de visualiser la totalité des projets et leur état d’avancement.
Think it
Lorsque quelqu’un arrive avec une nouvelle idée, il peut former une petite “squad” (typiquement 3 personnes) s’il a le feu vert de la direction afin de développer celle-ci, typiquement sous forme de prototype. Il s’agit de répondre aux questions : pourquoi devons-nous construire ce produit et pour qui ? Quel va être la mesure du succès ? Bref, une vraie démarche Lean Startup dans l’esprit !
La partie la plus importante est un narratif qui est développé avant que le produit soit développé. De nombreuses maquettes (papier ou non) sont souvent élaborés en parallèle.
Le “done” est accompli lorsque le management décide que le produit vaut le coup. Cela est fait de manière subjective, sans épauler cela de chiffres ou d’études de marché. Cela viendra plus tard, dans le “ship it” !
Build it !
C’est la construction du produit, conduit en agile (Scrum, XP, Kanban) avec un squad plus étoffé. Parfois même plusieurs squad. L’objectif est la création du MVP.
Le MVP est un équilibre délicat entre un proto qualifié d’embarrassant, en tout cas pas assez abouti pour être mis dans les mains des utilisateurs et un produit standard, bien trop coûteux pour un premier jet. Pour Spotify, MVP signifie Minimum Loveable Product, qui soit “narrative complete”, plutôt que “feature complete”.
Le “done” est atteint quand le squad et le management pensent que le produit est assez bon pour passer en production.
Ship it
Il s’agit de déployer progressivement le produit vers 100% des utilisateurs. On commence par le déployer vers un petit échantillon d’utilisateurs, et c’est là que l’on commence à vérifier nos hypothèses initiales. Le processus standard est d’effectuer des itérations pour opérer des ajustements.
Le “done” est atteint lorsque le produit est déployé vers 100% des utilisateurs.
Tweak it
C’est la phase la plus importante. Le produit peut être amélioré de nombreuses façon. Le squad opère des évolutions via de l’A/B testing et le suivi des métriques d’utilisation. A un certain point le produit atteint un optimum local et les nouvelles fonctionnalités n’ajoutent guère de valeur au produit. Soit le squad passe progressivement vers un nouveau projet, soit l’on rentre dans une phase de “re-think” pour changer dramatiquement le produit.
Le MacIntosh dévoilé : c’était il y a 30 ans !
La machine emblématique d’Apple a fêté ses 30 ans il y a peu.
La présentation officielle du MacIntosh du 25 Janvier 1984 est certainement le moment le plus connu. Mais il fut précédé d’une présentation aux actionnaires un jour avant ! C’est ce que montre cette video, hélas de très mauvaise qualité ! Vous pouvez sauter l’introduction et aller directement vers 36’30 où débute ce qui nous intéresse réellement. Sinon la video visible depuis Techland (dont vous trouverez le lien plus haut) vous donnera un support de meilleure qualité.
Patricia, mon petit… Je voudrais pas te paraître vieux jeu ni encore moins grossier. L’homme de la Pampa parfois rude reste toujours courtois mais la vérité m’oblige à te le dire : ton Antoine commence à me les briser menu !
Note de lecture : Grace Hopper and the invention of the information age, par Kurt W. Beyer
Note : 7 ; Le souffle épique allié à la rigueur académique pour cette biographie passionnante.
Une biographie d’une des figures majeures de l’informatique publiée aux MIT press : on est en droit de s’attendre à un texte plutôt aride. C’est loin d’être le cas. Nous allons voir cela ensemble. Mais commençons par le commencement.
Cette biographie compte 320 pages, mais comme il s’agit d’un format « roman », le volume de texte est moindre que l’équivalent en livre informatique. L’équivalent serait de 250 pages, je pense. Le tout est découpé en 12 chapitres.
Le premier chapitre « the myth of the amazing Grace » est aussi le plus difficile à lire. Il est un peu en marge de la biographie elle-même. L’auteur y analyse avec le recul l’impact de l’amirale sur l’histoire de l’informatique et ce qui l’a conduit à mener ce travail de recherche. Il évoque la rationalisation et la démystification de son travail. La motivation est donc là : faire un travail de reconstruction objectif documenté et argumenté. Après cette lecture (et le peu de connaissance de l’histoire de Grace Hopper que j’avais alors), je dois dire que l’effet obtenu est tout à fait l’inverse !
Le second chapitre « The rebirth of Grace Murray Hopper » débute réellement la biographie. Il passe plus que rapidement sur les premières années de sa vie pour réellement débuter avec ses études de doctorante, puis de professeure en mathématique. Ceci, c’est pour la première partie du chapitre. Elle s’articule sur la seconde : son engagement dans la Navy et sa rencontre décisive avec le commandant Howard Aiken.
« The origin of computer programming », le troisième chapitre du livre et aussi le plus long ne se résume pas en quelques mots. L’auteur nous fait revivre les instants que ont amené Grace Hopper à créer et définir le métier de programmeur et même la découverte du premier bug ! C’est aussi l’histoire des obstacles qu’il a fallu surmonter, de la façon dont Grace Hopper a gagné le respect et la confiance de son supérieur dans un environnement extrêmement militaire et misogyne.
Après le guerre, de nouveaux défis attendent Grace Hopper, d’abord comme moteur du laboratoire de calcul d’Harvard puis comme animatrice des premières communautés de développeurs. Les chapitres 4 et 5 couvrent ces périodes.
Le symposium de 1947 sera l’occasion de faire germer une idée qu’elle portera malgré l’hostilité des développeurs : la conception de langages de haut niveau et le développement d’un compilateur. C’est dans les années 60 que la carrière de Grace Hopper atteindra son point culminant en dirigeant de main de maitre le comité à l’origine du Cobol.
L’ouvrage se veut sans concession, aussi bien sur les défauts et les faiblesses de celle que l’on pourrait considérer comme l’héroïne de cette biographie, que les qualités le travail et la persévérance dont a su faire preuve Grâce Hopper. Tout en gardant la rigueur académique exigée par l’exercice, l’auteur fait passer le souffle épique d’une période particulière : celle de la naissance de l’informatique par l’une des plus grandes figures, sinon la plus grande, de cette époque.
Une lecture parfois difficile, mais souvent éclairante et passionnante qui témoigne d’une époque.

Référence complète : Grace Hopper and the invention of the information age – Kurt W. Beyer – MIT Press 2012 – ISBN : 9780262517263
Agile Game France 2014 en images (4/4)
Dernier volet de notre périple de 3 jours, ce post conclut mon retour sur l’Agile Game France dont vous retrouverez les opus précédents ici, ici et ici.
Rétrospective
Nos scribers sont réellement talentueux, voici ce à quoi ressemble désormais notre fresque

Et les voici à l’oeuvre.

Certains devant partir tôt, nous n’attendons pas le dernier moment pour nous livrer à une rétrospective de l’évènement. Elle s’effectue en 3 groupes, Jacques facilite le nôtre.

On prends très peu de temps, juste ce qu’il faut pour identifier un point d’amélioration.

La restitution se déroule tout aussi rapidement.

Tombola
Toujours dans le thème “je conclue l’Agile Games France en beauté”, il y avait une petite tombola pour gagner des polos. Il n’y en avait pas pour tout le monde ! En fait, il n’y en avait que 3 : tailles M, L et XL respectivement. Comme vous pouvez le voir de dos ici.

Et les gagnants sont : Alfred, Michel et … moi-même ! Le sort m’est généralement défavorable, c’est bien sympa que les choses ait tourné dans le bon sens justement aujourd’hui !

Et nous reste juste le temps pour 2 ateliers assez rapide.
Le jeu du Tao
Ce jeu avait été animé hier par Romain Couturier. Il avait été apprécié et une seconde session a eu lieu dans la matinée, mais animé cette fois par des participants de la session précédente. Alfred s’était tout d’abord proposé d’en animer une 3ème session, puis avait finalement décidé de remplacer cela par un retour sur ce jeu. D’abord déçu, j’ai vite compris qu’il ne se sentait pas armé pour une animation.

D’ailleurs, le jeu n’en est pas vraiment un, avec un livret qui ressemble plutôt à un annuaire et un contenu plus proche de la psychanalyse de groupe que du bon moment de détente ! Je trouve d’autant plus remarquable la prestation de Romain dont j’ai eu d’excellents echos qui se livrait à cette animation pour la première fois !

La chose mérite donc un peu de réflexion avant de s’y lancer tête la première. Tao Village propose des initiations, peut-être à essayer…
The Lean Takeoff
Alfred Almendra s’est donné un gros challenge : illustrer l’amorçage d’un cycle Lean Startup à l’aide d’un jeu ! Le jeu se focalise sur le “fit” entre le problème et la solution et tourne autour de cycles d’expérimentations. En l’état, le jeu ne me semble pas convainquant. Nous avons donné du feedback à Alfred pour lui donner des idées d’évolution.
L’exercice de construire un jeu autour de cette idée me semble vraiment très difficile. Je ne me vois pas relever le challenge. Je ne peux que souhaiter bon courage à Alfred (qui n’en manque pas par ailleurs) pour faire aboutir son idée !
Cloture
Cette 3ème édition d’Agile Game France se conclut maintenant.

Mon regret le plus important est d’avoir surtout été consommateur lors de cette édition, ce qui ne me convient guère ! Au départ je voulais présenter la version 2 du Business Value Fail que j’avais développé conjointement avec Yannick Ameur et présenté lors d’un Agile Playground. Mais j’ai été trop occupé pour mener à bien mon projet ! J’ai donc au moins deux objectifs pour l’an prochain (car oui, j’ai bien l’intention d’en être à nouveau !) :
- Proposer l’animation d’au moins 1 jeu.
- Mettre en place le Kanban des sessions que nous avons proposé lors de la rétrospective.
Un évènement comme celui-ci, c’est plutôt à la base pour les extravertis. Etant une sorte d’introvertis de compétition (si, si je vous assure), ce ne devrait pas être un lieu où je serais particulièrement à l’aise. Et poutant ! Pourtant, j’en suis ressortis gonflé à bloc avec des idées. Il faut dire que l’évènement garde son caractère bon enfant, détendu et bienveillant. Je ne peux comparer à l’an dernier, mais le lieu se prêtait plutôt bien à nos activités : 2 salles avec l’utilisation du palier, cela nous permettait 5 activités en parallèle, voir plus !
Pour terminer, je me dois de saluer la famille Siber venue au complet. Pas évident de venir avec un enfat en bas âge, mais ils l’ont fait !

Et bien entendu un grand bravo et merci aux artisans de cette évènement auto-organisé !
If it isn’t worth investing a few days to make sure that everyone is galvanized around a common vision, maybe this project isn’t worth doing.




