Chris Deniaud

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Agile Tour de Bordeaux 2019 ======

{{ wiki:bordeaux_20recadr_c3_a9.jpg?nolink&400 |}}

Cette nouvelle édition de l’Agile Tour de bordeaux vient d’avoir lieu ces 30 & 31 octobre 2019 à l’IUT Montaigne.

====== Shakeup and Speedup de Jurgen APPELO ======

Une keynote impressionnante, très riche, et à ma porté malgré mon niveau en anglais.

Par contre, pour ce qui est de ma capacité à assurer un live-tweet … je dois admettre que pour le moment, une conférence en anglais me demande encore trop de concentration pour me le permettre 😅.

Je vais donc me rattraper ici en léger différé.

{{ wiki:howtochangetheworld.jpg?nolink&400 |}}[[https://twitter.com/jurgenappelo|Jurgen]] commence par un cadeau : une version ebook de son best-seller « How to change the world ». Pour cela, il suffit de souscrire à sa mailling-list via [[https://jurgenappelo.com/free/|jurgenappelo.com/free]] (et si vous le souhaitez, il vous propose même de vous désinscrire après avoir récupéré l’ouvrage … c’est vraiment gratuit).

En se basant dans un premier temps sur l’évolution du marché de la musique, Jurgen nous invite à nous poser la question :

> Comment être toujours plus innovant ?

Tout d’abord, il faut absolument proposer rapidement quelque chose qui marche, et l’améliorer ensuite.

Mais beaucoup d’initiative autour de la créativité ont déçu par leur manque de résultat (les Innovations committee, Innovations Centers, Hackathlons, Innovations Days, etc.). Même si des idées en émergeaient, les compagnies n’en faisaient rien.

Il existe de nombreux modèles actuellement, mais aucun d’entre eu n’adresse le dilemme de l’innovation :

> Comment créer un nouveau business model, tout en innovant ?

Jurgen nous propose donc sa solution à ce dilemme.

1. Phase d’initialisation – Ne considérer son business model que comme une idée, qui aura besoin d’évoluer.

Pensez à la promesse du lancement de l’iPod : 1000 chanson dans sa poche, à une époque où nous ne pouvions en avoir qu’une douzaine.

Il y a une vraie vision produit promettant une révolution pour ses clients.

2. Phase d’expédition – Quelle est la première expérimentation possible pour valider que notre idée a du sens, et qu’elle répond à un vrai problème ?

Par exemple, les plateformes de crowdfunding sont pleines ne projets potentiels qui testent ici si elles ont un public possible (puisqu’ils sont prêt à payer pour sa concrétisation).

Cette adéquation peut être validée à travers une matrice de type « Lean Experiment » :

{{ wiki:leanexperiment.jpg?nolink&400 |}}

{{ wiki:dad_scoffeebarcommingsoon.jpg?nolink&400 |}}Rappel : un MVP (Minimum Viable Product) est conçu pour valider que l’on a un public.

3. Phase de formation – Qui va travailler sur cette idée, et comment ?

Une fois que l’idée est viable et qu’elle peut avoir un public, il est temps d’identifier :

  * qui va travailler sur le projet ?
  * quels seront les investisseurs ? / quel sera le budget ?

A ce stade, un « Lean Canvas » va permettre de valider un premier business model.

{{ wiki:leancanvas.jpg?nolink&400 |}}

4. Phase de validation – Expérimenter pour s’assurer de l’existence d’un marché

A ce stade, il est nécessaire de proposer un produit de grande qualité et opérationnel.

Si le produit fonctionne, séduit, et trouve un marché, est-il opportun de passer immédiatement à l’échelle ? Non, pas si vite.

5. Phase de stabilisation – Alignons notre business modèle au marché qu’il adresse pour préparer la suite

Dans les phases précédentes, il y a eu beaucoup de changements de directions autour de démarches empiriques (essayer, s’adapter, recommencer), afin d’identifier ce qui devait réellement être réalisé.

Il est temps de stabiliser les choses avant d’envisager de passer à l’échelle. D’autant qu’il est temps de s’adresser à une nouvelle population.

Jusqu’ici, nous nous adressions qu’à une population dite d' »innovateurs » et de « early adopters », il est temps de s’adresse à la « early majority » qui est beaucoup moins complaisante (Si elle rencontre un bug, elle ne va pas voulu le remonter, mais le partager avec tous ses amis sur Facebook).

Il y a beaucoup de choses à mettre en place pour assurer la satisfaction de cette population.

A ce stade, un « Business Model Canvas » devient approprié.

{{ wiki:businessmodelcanvas.jpg?nolink&400 |}}

Note : Cette phase de stabilisation peut durer quelques années.

Nous venons de parcourir les phases de l’enfance du projet.

6. Phase d’accelération – Il est temps de grandir

La somme d’une multitude de petites évolutions peut amener à une plus grande satisfaction et adhésion des consommateurs. Mais faut-il encore que le produit fonctionne !

7. Phase de cristallisation – Confortons le marché

Le projet rentre dans un phase adulte.

8. Phase d’expansion – Déclinaison du produit à tout va

Une chute de la créativité amène à décliner un produit sur des éléments anodin. Souvenez-vous de la déclinaison des iPods en prêt de 10 couleurs différentes …

Nous entrons dans une phase de crise dans laquelle nous n’avons plus de bonnes idées.

9. Phase de conservation – Le déclin

Le produit est maintenu en vie, mais cela ne fonctionne plus. Il n’y a plus de marché.

10. Phase de fin – Passer à autre chose

Il est temps d’enterrer le marché et de s’orienter vers d’autres produits.

Ces 10 phases représentent le « Shiftup Business Lifecycle » qui peut être parcouru en quelques années ou quelques décennies, voire siècles, selon les produits.

{{ wiki:shiftupbusinesslifecycle.jpg?nolink&400 |}}

Un support en mémo partagé par Jurgen sur une autre conférence :

A retenir : Les différentes phases d’évolution d’un produit doivent être régies par des règles différentes.

{{ wiki:familly.jpg?nolink&400 |}}

Typiquement, des métriques de type « North Star Metric » peuvent être plus appropriées que des OKR sur les 5 premières phases d’un projet.

{{ wiki:northstarmetric.jpg?nolink&400 |}}

Jurgen a combiné plusieurs modèles existants pour créer son propre modèle : Le vortex de l’innovation.

{{ wiki:innovationvortex.jpg?nolink&400 |}}
{{ wiki:innovationvortex2.jpg?nolink&400 |}}

qui s’inscrit dans un programme complet :

{{ wiki:shiftupprogram.jpg?nolink&400 |}}

====== Hackez votre cerveau avec l’intelligence collective de Jérôme URVOAS ======

[[https://twitter.com/JeromeUrvoas|Jérôme]] nous propose un atelier de 2 heures pour expérimenter des pratiques peu communes destinées à faire appel à des modes de réflexions peu exploités.

A travers un thème commun : « co-construisons l’entreprise idéale », Jérôme demande à 5 équipes de 6 membres de définir cette entreprise à travers 5 ateliers différents. Le tout, à travers une mécanique de World Cafe.

Mon équipe s’est jetée sur l’atelier « Story Board » (puisque chaque équipe doit prendre un atelier différent), ce qui n’avait finalement pas grande importance puisque l’on changeait d’atelier toutes les 10 minutes, et que nous les avons tous expérimentés.

Cet atelier a donné lieu à de belles productions :

Un story board :

{{ wiki:storyboard.jpg?nolink&400 |}}

Une fresque :

{{ wiki:fresque.jpg?nolink&400 |}}

Une offre de recrutement :
{{ wiki:offrederecrutement.jpg?nolink&400 |}}

Une lettre d’amour :

{{ wiki:lettreamour.jpg?nolink&400 |}}

Et même un pièce de théâtre :

{{ wiki:piecetheatre.jpg?nolink&400 |}}

Le tout basé sur la méthode des Six Trumps de [[https://twitter.com/sbowperson|Sharon BOWMAN]] :

  * favoriser le mouvement
  * parler plus qu’écouter (temps d’échanges et partages)
  * utiliser des images plus que des mots
  * forcer le changement pour stimuler
  * alterner des temps courts (cadencer)
  * favoriser l’écriture à la lecture

Jérôme nous rappelle que :

> « Dans les neurosciences, un modèle de plus de 2 ans est obsolète »

Pour autant, le débrief nous amène :

  * la diversité des formats permet à chaque participant de passer dans des zones de confort, et de s’expérimenter dans des zones dans lesquelles il l’est moins.
  * le rythme imposé implique de rentrer très vite dans chaque atelier, et force est de constaté que cela a été le cas.
  * la co-construction incrémentale pousse à la créativité. Il n’est pas possible de revenir sur des apports produits par des équipes précédentes, cela force à ré-ouvrir des portes que l’on avait potentiellement fermée sur d’autres ateliers.

Un très bel atelier !

====== Quel est votre véritable pouvoir ? par Alexis MONVILLE ======

C’est à présent au tour d’[[https://twitter.com/alexismonville|Alexis]] de nous proposer une keynote pour lancer l’après-midi.

{{ wiki:alexislancelakeynote.jpg?nolink&400 |}}

La salle est évidemment comble, sans compter l’amphi dans lequel une rediffusion live est proposée.

Tout commence par une histoire : l’histoire de Valérie, directrice de projet dans le domaine du luxe.

Valérie rencontre des difficultés sur un projet sur lequel, lorsqu’elle demande de l’aide, se voit invitée à ajouter des « ressources » sur le projet.
Après tout, en période de crise, quoi de mieux que d’ajouter des personnes sur un projet ?!? (car oui, le sous-entendu derrière le terme ressources est bien souvent d’ajouter des personnes …)

{{ wiki:backlogdevalerie.jpg?nolink&400 |}}Par chance, Valérie rencontre Joël, un agiliste aussi convaincu qu’expérimenté. Et Joël, armé de toute sa conviction, explique à Valérie quelques pratiques et techniques qui pourraient l’aider. Et manifestement il est bon puisque Valérie va s’emballer un peu et passer son week-end à alimenter un backlog de plus de 250 éléments attendus sur sont projet, à travers un fichier Excel.

Cette incompréhension de la part de Valérie, n’est-elle finalement pas révélatrice d’un  symptôme d’incompréhensions plus général que nous rencontrons si souvent ?
Et cette même incompréhension n’est-elle pas liée à l’histoire même de l’agilité ? Agilité qui a émergé dans les années 90 pour se cristalliser en 2001 autour d’un manifeste. Manifeste qui a lui même donné lieu à une bascule : le passage de l’agilité en phase de productisation.

Note : La productisation s’adresse à des personnes qui souhaitent changer.

Mais revenons sur les méthodes agiles, elles se reposent sur :

  * des outils
qui appuient
  * des pratiques
qui mettent en oeuvre
  * des principes
qui déclinent
  * des valeurs

{{ wiki:outilsavaleurs.jpg?nolink&400 |}}

Mais il ne faut pas oublier que ces valeurs trouvent leurs fondations dans des croyances {{ wiki:outilsacroyances.jpg?nolink&400 |}}.

Hors, c’est le changement de ses propres croyances qui permet d’évoluer.

Mais revenons sur Valérie et Joël. Comment Joël a-t-il pu réagir face à l’emballement de Valérie ?
Il l’a félicité pour son engagement dans sas propre évolution, puis il est revenu sur les bases.

Par exemple, il lui a proposé d’expérimenté un peu d’auto-organisation, puis des one-to-one pour initier de plus en plus de conversations.
Et soyons fous, pourquoi ne pas aller voir directement les clients pour générer toujours plus de conversations, et obtenir un maximum de feedbacks … ?
Puis pourquoi ne pas tenter de livrer régulièrement ? Histoire de récupérer encore plus de feedbacks. Bon, à ce stade, Valérie n’est pas encore en mesure de livrer régulièrement. Mais elle va s’engager dans cette voie.
Et cela amène très vite à la première rétrospective, qui elle même amène à chercher à visualiser l’activité à travers une visualisation du flux.
Le tout amène, petit à petit, à réellement livrer régulièrement, et donc s’enrichir de feedbacks.

Mais ce n’est pas fini, les premières livraisons amènent à identifier des insatisfactions … Insatisfactions qui répondent pourtant aux spécifications … Et cela amène Valérie à réaliser ses premières enquêtes 😉.
Cela génère des écarts entre la cible et le contrat initial. Mais la confiance avec le client se bâti sur les livraisons régulières.
Et au seins de l’équipe, il faut aussi apprendre à collaborer. Et peut-être même établir un contrat au sein de l’équipe, tout en apprenant à exceller techniquement.{{ wiki:contratequipe.jpg?nolink&400 |}}
Le tout abouti à la livraison d’un produit différent du contrat initial, qui a continué son évolution.

Une belle fin pour cette histoire.

Mais revenons en à la promesse de cette keynote. Quel pouvoir avons-nous pour faire évoluer les choses ?

Que ce soit directement à travers notre sphère d’action, ou notre sphère d’influence, voire au delà (… en étant plus patient), il y a toujours moyen d’influencer. {{ wiki:influence_26soupe.jpg?nolink&400 |}}

Mais le changement est-il possible dans votre organisation ?

Accepter l’idée que c’est impossible, c’est à peu près comme accepter l’idée qu’un docteur puisse annoncer :

> « Monsieur, vous êtes malade, donc je vais appeler vos parents pour leur dire qu’ils repartent à zéro. »

Donc la seule réponse raisonnable, c’est le changement, et le changement commence par vous !

Bref :

> Vous avez le pouvoir !

Voici typiquement le genre de conférences qui donnent une pèche terrible !

Et en prime, vous pouvez replonger dedans à travers la diffusion déjà réalisée par des équipes au taquet :

====== Les émotions dans le monde professionnel par Alice BARRALON et Vanessa HUMPHREYS ======

[[https://twitter.com/a_barralon|Alice]] et [[https://twitter.com/vhumphreys33|Vanessa]] nous proposent, devant un amphi plein, de passer en revue quelques émotions que nous pouvons rencontrer dans un environnement professionnel. Le tout à travers un ensemble de scénettes mettant en jeu dans lesquelles le Dr. Alice se penchera sur les comportements de Vanessa.

En gros, toute émotion non accueillie génère de nouvelles émotions souvent plus négative. Même une joie non accueillie peut générer de la frustration, du dégoût, voire même de la colère.

Après la joie, l’exploration se poursuit avec la tristesse, la colère, puis la peur.

Enfin, Alice et Vanessa nous proposent un retour théorique sur l’aseptisation de l’environnement professionnel. Et autant le dire, dans ce domaine Platon semble un coupable idéal. Mais Descartes ne semble pas hors du coup alors que Spinoza militait pour l’union du corps et de l’esprit.

Ainsi, si vous souhaitez vous pencher sur les théories autour des émotions, Alice et Vanessa vous propose de vous pencher sur les références suivantes :

  * Platon
  * Descartes vs Spinoza
  * Scherer
  * Scherer et Leventhal
  * Salovey et Mayer
  * Daniel Goleman
  * Daniel Chernet

{{ wiki:coacherlesemotions.jpg?nolink&400 |}}

Et pour finir, voici une compétence que nous risquons de bientôt voir dans les annonces de jobs : La flexibilité cognitive !

{{ wiki:flexibilitecognitive.jpg?nolink&400 |}}

====== L’Intelligence Artificielle va-t-elle changer l’agilité ? par Gilles ======

[[https://twitter.com/gmantel|Gilles]] nous propose, à la fois une démystification de l’IA, et les impacts qu’il rencontre dans ce contexte en tant qu’agiliste.

{{ wiki:ia_titre.jpg?nolink&400 |}}

Partie 1 : L’IA, qu’est-ce que c’est ? Comment ça marche ?

L’IA s’adresse à de nombreux domaines :

{{ wiki:ia_applications.jpg?nolink&400 |}}

Gilles nous propose ici un focus que les réseaux de neurones.

Avant tout, qu’est-ce qu’un neurone informatique ?

Un neurone ressemble à ceci : Une unité de calcul qui envoi, ou pas, un signal.{{ wiki:neurone1.jpg?nolink&400 |}}
Concrètement, un ensemble de facteurs (imaginez cela comme des potentiomètres) sont fournis en entrée, que le neurone combine pour identifier s’il transmet un signal ou pas.

{{ wiki:neurone2.jpg?nolink&400 |}}

Le tout peut être combiner au sein d’un neurone pour rendre des services vraiment complexes :

{{ wiki:reseaudeneurones.jpg?nolink&400 |}}

Avec cette spécificité peu anodine qu’un réseau de neurones est une boite noire. Il n’est pas possible de voir ce qui se passe dedans (en tout cas, ce n’est plus accessible à la compréhension humaine).

Personnellement, cela m’inspire les travaux des premiers neuroscientifiques qui essayaient de comprendre le fonctionnement du cerveau avant l’invention de l’IRM.

Ce type de réseau s’améliore à travers un mécanisme de « back-propagation » ou « descente de gradient stochastique » (c’est le terme savant de la session, mettez-le de côté pour vos soirée entre amis 😉), qui consiste à identifier les variations à expérimenter (modification des facteurs) en partant de la fin puis en remontant le réseau. Cette opération se réalise au regard du taux d’adéquation des résultats obtenus avec les résultats attendus connus.

(J’espère avoir bien compris)

{{ wiki:phaseapprentissage.jpg?nolink&400 |}}

Pour donner une idée de la problématique d’apprentissage, Gilles part d’une tâche qui peut sembler peu complexe (« sembler », j’insiste !) : la détection d’un lapin dans une image.

Le nombre de combinaison à traiter pour valider la présence de ce lapin est colossal :

{{ wiki:lapin1.jpg?nolink&400 |}}

D’où l’application d’algorithmes de « simplification » aux objets avant de les traiter :

{{ wiki:lapin2.jpg?nolink&400 |}}

Mais l’exemple ici est volontairement « simpliste » pour le rendre humainement appréhendable. Dans la réalité, la simplification appliquée à ce lapin retourne une image qui ressemble vaguement à du bruit sur une vieille télé couleur.

Cela contribue aussi à l’effet « boite noire ».

Partie 2 : Impact sur l’agilité

Ces nouvelles techniques de travail ont évidemment un impact sur nos méthodes de travail.

Pour commencer, si le travail itératif est toujours possible (et recommandé), il n’en est pas de même pour le travail incrémental 😱.

En partant d’un retour d’expérience sur un projet de détection automatique de décharges sauvages, Gilles nous explique que malheureusement, d’une itération à l’autre, il n’y a pas de capitalisation. Le mode d’apprentissage d’un réseau de neurones ne permet pas de s’assurer qu’une variation ne va pas amener de régression sur des cas qui étaient correctement gérés jusque là (et ça, ça pique).
Typiquement, les premières décharges ont été identifiées au bout de 3 mois, sans possibilité de livrer la moindre valeur avant.

Que dire du refactoring dans ce contexte ? Impossible puisqu’il s’agit d’un réapprentissage complet à chaque variation 😰.

Pour les mêmes raisons, le TDD passe à la benne 😰😰.

Et que dire de l’intégration continue, du test continu, ou encore du déploiement continu ? Oubliez les aussi tant que nous ne seront pas prêts à permettre à nos produits d’évoluer sans garder le contrôle sur leurs comportements.
Les fans de DevOps vont pleurer 😭.

En bref, il y a tant de choses à réinventer face au développement de l’IA. C’est aussi excitant qu’effrayant !

====== Les grandes boîtes sont des petits panoptiques. Les coachs agiles sont des jésuites par Romeu MOURA ======

La seconde journée est lancée par une keynote décoiffante prodiguée par [[https://twitter.com/malk_zameth|Romeu]], tournée autour de la systémie.

Pour vous donner une idée du « décoiffage », la première introduction de Romeu sur la systémie s’appui sur le mode de propagation du virus Ebola.
Dans les grandes lignes, le virus Ebola s’attrape directement par l’ingestion de viande infectée. Ce qui ne représente pas plus d’une centaine de cas depuis l’apparition l’Ebola. Mais alors comment se retrouve-t-on avec près de 40 000 cas plus ou moins recensés ?
Par contact direct, car on sait que ce virus nécessite un contact direct pour se propager. Bref, parce que nous prenons soin de nos proches malades. Si ce n’était pas le cas, pour le cas spécifique d’Ebola, il n’y aurait eu qu’une centaine de morts.

On commence à toucher du doigt que l’identification d’un problème risque d’être plus globale et donc plus complexe que ce qu’elle peut inspirer de prime abord.

Donc, re-contextualisons avec ce que nous connaissons. Si nous considérons une équipe de dev et une équipe de tests comme 2 systèmes qui interagissent. Quel est le fruit de cette interaction ?
-> La production de rapports de bug.
Etait-ce réellement la production ciblée ?

Romeu nous propose alors un petit détour sur le panoptique de Bentham. Un principe louable, initialement conçu pour pacifier les comportements entre prisonniers.

{{ wiki:panoptiqueplandemasse.jpg?nolink&400 |}}
{{ wiki:panoptique.jpg?nolink&400 |}}

Mais voilà, Foucault dévoilera pourquoi son application rend les prisonniers fous.
Avec le temps, les prisonniers finissent par justifier son état, le fait qu’ils soient en prison, et finissent tous par adopter un comportement de garde.

De la même façon (mais à une moindre échelle puisque les salariés rentrent chez eux le soir), les équipes sont transparentes avec les managers, les managers sont opaques vis-à-vis de leurs équipes, et les équipes ne se parlent pas. Au sein des équipes, chaque membre de l’équipe devient alors son propre garde, il s’impose continuellement des limites (parfois fantasmées).

Dans la même veine, offrir du coaching peut être perçu comme un conjoint qui offre 3 mois de gym à sa moitié. Évidemment, l’intention initiale est bienveillante, mais cela peut faire émerger une violence non souhaitée. Parce-que pour apprécier du coaching, il faut déjà être dans une démarche de travail sur soi.
N’oublions pas que « le but de tout système est l’auto-conservation » (homéostasie).

De même :

> « Un geste qui peut sembler individuellement anodin peut-être d’un point de vue systémique extrêmement violent. »

Le coaching peut alors être perçu comme une forme de colonialisme (d’où les jésuites) : on paye le coach pour aller changer les gens là-bas.

> « Le seul pouvoir, c’est l’influence »

Et on peut tous en avoir. Alors pour cela :

> Indignez-vous !

Et comme les équipes de l’Agile Tour de Bordeaux sont vraiment exceptionnelles, vous pouvez déjà vous replonger dans cette keynote aussi :

====== Conception émergente : l’art de coder sans savoir où l’on va ? par Olivier AZEAU ======

[[https://twitter.com/oaz|Olivier]] nous propose un éclairage sur le coût de certains choix de conception.

{{ wiki:olivier.jpg?nolink&400 |}}

C’est finalement à travers un atelier qu’il va proposer à chacun (à travers une application web de sa conception) de réaliser des choix de conception, en assumant les coûts que ces choix impliquent.

{{ wiki:atelierolivier.jpg?nolink&400 |}}

En gros, il est évident qu’un développement « générique » coûte plus cher à concevoir qu’un développement spécifique. Mais alors … à partir de quand deviendra-t-il rentable ?

C’est pour faire toucher ce dilemme du doigt que cet atelier est une merveille de pédagogie.

Ici, était-il opportun de produire un code générique dès le premier choix ?

{{ wiki:generalisation1.jpg?nolink&400 |}}

Et bien non, ce code ne sera jamais réutilisé alors qu’il a coûté plus cher 😰

Vous n’avez jamais rencontré ce symptôme ?

{{ wiki:passesmoilesel.jpg?nolink&400 |}}

Mais alors … à partir de quand produire du code générique ?

Olivier nous propose quelques clefs glanées à travers diverses sources théoriques, car s’il n’est pas une bonne chose de produire du code générique trop vite, il y a aussi un problème a attendre trop longtemps pour généraliser son code.

{{ wiki:factorisation.jpg?nolink&400 |}}

On peut donc citer :

  * Le YAGNI : You Ain’t Gonna Need It
  * Décider aussi tard que possible du Lean Software Development
{{ wiki:decidelate.jpg?nolink&400 |}}
  * [[https://twitter.com/martinfowler|Martin Fowler]] préconise de réaliser un refactoring dès la troisième occurrence
{{ wiki:martinfowler.jpg?nolink&400 |}}
  * Le « Simple Design » de XP
{{ wiki:simpledesign.jpg?nolink&400 |}}
  * Le Test Driven Development
Pour rappel : le TDD est une méthode de conception, pas une méthode de tests
{{ wiki:tdd.jpg?nolink&400 |}}
  * Le Domain Driven Design
{{ wiki:ddd.jpg?nolink&400 |}}
  * Le Language Oriented Programming comme les DSL (Domain Specific Language)

Ce qui doit amener à revoir notre paradigme de développement autour d’une question centrale :

> Qu’est-ce qui ne changera pas ?
(pourquoi pas, sur les 10 prochaines années)

Alors au lieu de chercher à jouer les devins sur ce que le futur nous réserve, Olivier nous préconise la démarche suivante :

  - Coder des comportements spécifiques
  - Simplifier pour révéler les intentions
  - Découvrir la métaphore (pour généraliser)

Mais au fait … tout cela existe depuis 20 ans !
{{ wiki:xp.jpg?nolink&400 |}}

Bref, encore un bijou pédagogique que vous pouvez trouver sous une forme moins numérique via l’atelier du [[http://softwareball.mnt.space/|Software Ball]].{{ wiki:softwareball_v1.small.png?nolink&400 |}}

Au fait, les slides sont déjà disponibles par ici : [[http://slides.azeau.com/20191031-emergent-design|http://slides.azeau.com/20191031-emergent-design]]

====== Mind the gap par Jérôme AVOUSTIN ======

{{ wiki:jérôme.jpg?nolink&400 |}}

[[https://twitter.com/JeromeAvoustin|Jérôme]] nous propose une réflexion sur les échanges entre experts métiers et experts techniques.

Il commence par une citation de [[https://twitter.com/RonJeffries|Ron Jeffries]] :

> « Le logiciel est un lien entre des personnes qui ont des problèmes et des personnes qui ont des solutions »

Mais alors, comment faire collaborer ces 2 populations qui vive pourtant sur des planètes bien différentes ? Et malgré les silos ??
En spécifiant exhaustivement via des tonnes de papier ? Ça ne marche pas 😰

{{ wiki:tonnepapier.jpg?nolink&400 |}}

Pourquoi ne pas tenter de mettre en place des boucles de feedback à travers une démarche itérative ?

{{ wiki:bouclefeedback.jpg?nolink&400 |}}

Et pourquoi ne pas tenter d’inviter un peu d’empathie dans nos spécifications à travers des User Stories ?
{{ wiki:us.jpg?nolink&400 |}}

Les ateliers de story mapping permettent de partager une vision globale,

{{ wiki:storymapping.jpg?nolink&400 |}}

alors que le sprint planning va favoriser des échanges plus pertinents et plus précis.

{{ wiki:sprintplanning.jpg?nolink&400 |}}

Un atelier des « 3 amigos » (qui consiste à réunir 1 PO, 1 dev, et 1 testeur pour rédiger les tests) permet de vérifier que l’on a traité tous les aspects d’un problème.

{{ wiki:3amigos.jpg?nolink&400 |}}

Pourtant, bien que le manifeste a bientôt 20 ans, nous avons toujours des logiciels trop complexes. Mais … pourquoi ?

{{ wiki:logcomplexe.jpg?nolink&400 |}}

On perd sûrement de vue certaines bases, qui nous empêchent de voir l’éléphant au centre de la pièce.
{{ wiki:elephant_in_the_room_fr.png?nolink&400 |}}

Il y a en fait beaucoup de complexité que nous générons nous-mêmes.
{{ wiki:branchementselectriques.jpg?nolink&400 |}}

Mais il ne faut pas oublier que les POs sont des humains, inférés par de nombreux biais.

{{ wiki:humain.jpg?nolink&400 |}}

Alors que n’oublions jamais que :
{{ wiki:miseenprod.jpg?nolink&400 |}}

Pour cela, il est possible par exemple :

  * de partager un même langage entre techs et métiers
{{ wiki:ubiquitouslanguage.jpg?nolink&400 |}}
  * éviter, ce qui est pourtant une tendance de développeur, de tout modéliser de façon unique
{{ wiki:anneau.jpg?nolink&400 |}}
  * Alors que les modèles doivent s’adapter au contexte dans lesquels ils doivent s’appliquer.
« Bounding context » : espace dans lequel un terme a une définition unique et partagée.
{{ wiki:boundingcontext.jpg?nolink&400 |}}
  * Ne pas modéliser en fonction d’une représentation en base de données, et se concentrer sur les comportements.
{{ wiki:mdd.jpg?nolink&400 |}}
  * Explorer un domaine entre métiers et techs à travers un atelier « Event Storming »

{{ wiki:eventstorming1.jpg?nolink&400 |}}
{{ wiki:eventstorming2.jpg?nolink&400 |}}

  * Mettre tout le monde dans la même pièce, ça fait des miracles
{{ wiki:ensemble.jpg?nolink&400 |}}
Rappel : on n’est pas là pour poser des post-its sur les murs, mais pour générer des échanges
  * L’atelier « Domain Story Telling » permet aussi de se concentrer sur les domaines métiers et les échanges/activités

{{ wiki:domainstorytelling1.jpg?nolink&400 |}}
{{ wiki:domainstorytelling2.jpg?nolink&400 |}}

{{ wiki:domainstorytelling3.jpg?nolink&400 |}}
{{ wiki:domainstorytelling4.jpg?nolink&400 |}}

  * Le « Behavior Driven Dev » est une extension du TDD qui permet, à travers un langage spécifique, de rendre des spécification exécutables

{{ wiki:bdd1.jpg?nolink&400 |}}
{{ wiki:bdd2.jpg?nolink&400 |}}
{{ wiki:bdd3.jpg?nolink&400 |}}

  * L' »Example Mapping » permet de faire le focus sur une US pour faire émerger des règles à partir de cas réels

{{ wiki:examplemapping1.jpg?nolink&400 |}}
{{ wiki:examplemapping2.jpg?nolink&400 |}}

  * Attention : Tout ne se prête pas à une organisation répartie
{{ wiki:matricepratiques.jpg?nolink&400 |}}
  * Les développeurs doivent s’immerger dans l’espace du problème et explorer le domaine métier.

{{ wiki:espaceproblème1.jpg?nolink&400 |}}
{{ wiki:espaceproblème2.jpg?nolink&400 |}}

  * Et ne pas oublier qu’il s’agit principalement d’une question d’apprentissage collaboratif
{{ wiki:learning.jpg?nolink&400 |}}
  * Et focalisez vous sur les comportements
{{ wiki:modelingbehaviors.jpg?nolink&400 |}}

====== Forum Ouvert par Alexis MONVILLE ======

{{ wiki:alexisforumouvert.jpg?nolink&400 |}}

[[https://twitter.com/alexismonville|Alexis]] nous a proposé une facilitation de Forum Ouvert cadré de façon très efficace. Il n’y a qu’à voir le nombre de sujets proposés par les participants, et la qualité des sessions auxquelles j’ai participé.
{{ wiki:placedumarché.jpg?nolink&400 |}}

Une formule bien rodée, qui nous permet de toucher du doigt l’apport d’une grande facilitation.

Bref, une très belle édition dont je ressors rechargé (c’est tout de même fou l’énergie que l’on y trouve) et avec quelques nouvelles pistes à explorer.
Merci à toutes les personnes et entités impliquées dans ce succès.

{{tag>[#Conférences #AgileTour]}}