Quand les users stories deviennent techniques…

Je ne suis pas un intégriste de la User Story. Il ne m’importe pas tellement qu’elles suivent le fameux template de Mike Cohn « en tant que… je veux… afin de… ». Même si ce template n’a rien de mauvais et peut guider vers l’écriture de meilleurs histoires, c’est aussi un bon moyen de devenir un « template zombie ». Je préfère les 3 questions de Jeff Patton : Qui ? Quoi ? Pourquoi ?

image

En fait, peu m’importe que vous parliez de User Story, d’item de backlog ou d’un autre terme inventé de toute pièce. Ce qui va m’importer, c’est que votre story ait un sens d’un point de vue externe au système que l’on construit. C’est là qu’intervient le « qui », un acteur externe aus système. Ce n’est pas par dogmatisme que j’y suis sensible, mais au contraire par pragmatisme. Une petite explication s’impose.

Lire la suite

Publicité

Note de lecture : Use Cases : Requirements in Context, par Daryl Kulak & Eamonn Guiney

Note : 6 ; Bonne mise en pratique du cycle itératif et de bonnes idées, mais pas entièrement concluant.

Ce livre présente les cas d’utilisation dans le cadre d’un processus itératif, en fait celui d’Unfied Process. A ce titre, il propose une approche incrémentale pour la spécification des cas d’utilisation, basée sur celle de Craig Larman. Cet ouvrage taille aussi un short à la gestion des exigences, par rapport auxquels les auteurs préfèrent la spécification des règles métier, même si en fait c’est surtout la production de gros documents de spécification monoblocs qui est remise en cause. La description des spécifications incrémentale est réellement valable et concrète, et de plus desservie par des exemples concrets en annexe.

La construction du livre est un peu curieuse, car les annexes forment la moitié de l’ouvrage, le texte principal ne comptant que 170 pages structurées en 11 chapitres. Le premier d’entre-eux consacre ses 18 pages à l’identification des problèmes liés à l’approche classique. La prose manque un peu d’élan lyrique, mais s’efforce néanmoins de bien synthétiser ces points d’achoppement. Disons que le boulot est fait.

Le second chapitre s’étend sur 32 pages, il s’agit d’une introduction aux cas d’utilisation d’inspiration très « Gery Schneider ». On y aborde plutôt efficacement les basiques de la représentation des cas d’utilisation et les bonnes règles de conduite. Plus globalement on y traite aussi des cas d’utilisation dans l’environnement UML. Un chapitre rondement mené.

Lire la suite

Note de lecture : Managing Software Requirements, par Dean Leffingwell & Don Widrig

Note : 7 ; Les exigences selon RUP, avec beaucoup d’éléments sur les pratiques, mais aussi un manque de matière sur la mise en œuvre.

Ce livre traite de la gestion des exigences vue par Rational Unified Process. Les auteurs ont d’ailleurs travaillé sur l’outil Requisit Pro. La lecture en est plaisante, le découpage en nombreux chapitres assez découplés bien que complémentaires y aide beaucoup. Comptez 385 pages pour ce volume qui comprend en sus près de 90 pages d’annexes ! Les 35 chapitres que les auteurs ont concoctés sont divisés, non en parties mais en 8 « skills », une petite subtilité, mais assez intelligente !

En une trentaine de pages comptant quand même 3 chapitres, la première partie fort opportunément appelée « introduction » est vite passée ! Si on s’intéresse aux grands classiques du « pourquoi » des exigences, c’est à dire le coût des exigences erronées, on arrive vite à la définition de ce qu’est une exigence au chapitre 2. C’est ici aussi que l’on introduit la pyramide problème / besoin / solution que j’aime tant ! L’auteur n’oublie pas que le développement logiciel, même dans l’ingénierie des exigences, est une affaire d’hommes et de femmes, il consacre le chapitre 3 à l’équipe et aux compétences. Bref, une première partie tout à fait sympathique.

Ce sont 3 chapitres (sur environ 40 pages) qui sont également consacrés à la seconde partie « Analyser le problème » qui est le premier « team skill » du livre. Nous voilà rentrés dans la matière. L’auteur nous propose 5 étapes pour définir le problème. Les choses sont rarement aussi simples que l’on puisse suivre une telle séquence de manière immuable, mais nombre d’analystes devraient s’inspirer de ce que l’on trouve ici : identification des acteurs, définition du périmètre du système et de ses contraintes et surtout, surtout : l’analyse causale ! La matière proposée concernant l’analyse métier est bien moins convaincante, mais on peut bien excuser de petites faiblesses… Le dernier chapitre de cette partie met surtout en musique ce que nous avons vu avec l’étude de cas du livre : HOLIS. Fort intelligemment, il ne se contente pas de reprendre la matière du chapitre 4, on y ajoute quelques petits éléments comme l’elevator statement.

Lire la suite

Note de lecture : Specification by Example, par Gojko Adzic

Note : 8 ; La référence sur le développement guidé par les tests. Book of the year 2014 !

Régulièrement, je retarde le moment d’ouvrir un livre que je sais excellent (de réputation) et qui prend la poussière sur une de mes étagères. Ce livre est de ceux-là ! Bien que Manning nous gratifie de temps en temps de titres non-techniques, il est assez étonnant de trouver celui-ci chez cet éditeur, probablement parce que ce n’est pas un livre pour remplir un vide thématique.

Il s’agit bel et bien d’un texte nous proposant un regard novateur sur les tests d’acceptance, même si l’auteur rappelle régulièrement au fil des pages qu’il fait suite à son ouvrage précédent « The Communication Gap ». Ce n’est pas non plus un livre très facile à lire, non qu’il soit volumineux car il ne compte que 250 pages, mais il s’appuie essentiellement sur de nombreux témoignages qui transforment le fil conducteur en une sorte de patchwork. Evidemment, ces nombreux témoignages qui sont autant de cas d’étude font beaucoup pour la crédibilité du texte qui est ainsi à la fois un travail digne d’un universitaire et l’œuvre d’un praticien de terrain. Venons-en au contenu.

L’ouvrage se découpe en 3 parties inégales. La première d’entre-elles ne compte que 60 pages réparties en 4 chapitres. Le premier chapitre nous laisse un peu dans le flou, il s’agit surtout d’un argumentaire étayé de témoignages sur la raison de s’intéresser à la spécification par l’exemple. On rentre dans le dur au chapitre suivant qui aborde la manière dont Gojko Adzic voit s’articuler le besoin depuis les « business goals » jusqu’à la « documentation vivante ». Les aspects amont sont par ailleurs l’objet de son ouvrage suivant « impact mapping ». On y apprend incidemment pourquoi l’auteur préfère « spécification par l’exemple » à « développement guidé par les tests d’acceptance ». Un chapitre à ne rater sous aucun prétexte ! Le chapitre 3 « living documentation » offre pour moi peu d’intérêt, sauf peut-être celui de couvrir le schéma de processus que l’auteur nous a exposé au chapitre 2 ? La spécification par l’exemple ne se veut pas une pratique spécifique aux projets agile, bien que ce soit un terrain de jeu naturel. Au chapitre 4, l’auteur aborde différentes façon de basculer d’un projet classique à l’écriture des tests en amont sous forme de patterns (bien qu’ils n’en empruntent malheureusement pas la forme).

Lire la suite

Carnet de route : Le ScrumDay 2014 (4/4), Bonus track !

Après avoir couvert mon parcours de ces 2 jours de ScrumDays (ici, ici et ici), une question reste en suspens : et les autres sessions ? J’ai donc été rechercher du mieux que j’ai pu les supports de présentation des sessions auxquelles je n’ai pu assister. Il en manque encore hélas beaucoup, sans compter la mise en ligne des vidéos. Si vous avez des liens vers les supports manquants, faites m’en part, je les rajouteraient.

Pour commencer, voici le livret des sessions, en mode présentation

La transformation numérique de France Télévision

France Télévision fut le premier sponsor « client final » du French SUG ! Ils nous partagent leur retour d’expérience.

Vous retrouverez aussi cette présentation via le blog d’Alain Buzzacaro.

Le Lean Startup au service du Product Owner, par Jérôme Guenver

J’ai entendu dire beaucoup de bien de cet atelier animé par Jérôme. Un atelier que Jérôme a imaginé suite à une discussion que nous avons eu ensemble chez Zenika. Je suis donc plutôt heureux d’avoir eu un petit rôle pour inspirer un collègue !

Des outils du monde de la psychologie… par Bruno Sbille

On ne présente plus Bruno, en tout cas on ne devrait plus ! Bruno est l’un des piliers de l’imposante communauté agile Belge. Il est aussi l’organisateur de l’Agile Tour Bruxelles auquel je participe depuis sa création (et j’espère continuer). Lors de ce ScrumDay, il proposait cet atelier en plus de son rôle dans la « coach clinic » !

Dans cet atelier, Bruno présentait et permettait d’expérimenter divers outils tels que la PNL, le VAK, etc. Je me souviens encore que Bruno avait fait le déplacement depuis Bruxelles pour la soirée de création du French SUG il y a 6 ans de cela. C’était justeent pour nous parler de PNL !

Let’s Sketch together, par Alvin Berthelot

L’atelier d’Alvin était articulé autour de la création visuelle de produits. Je sais qu’il le produit régulièrement, j’aimerais bien avoir l’opportunité d’y participer…

The big payoff, par Alexandre Boutin

J’avais eu l’occasion de pratiquer ce jeu lors des premiers Agile Game France. Alex remet le couvert pour ce très bon agile game. Vous pouvez en trouver le descriptif en anglais ici. Et mieux encore le descriptif en Français ainsi que le matériel de jeu sur le blog d’Alex.

Faites Revivre vos spécifications

Un autre sujet orienté BDD issu d’une expérience récente de Yannick. Il m’en avais parlé lors d’un déjeuner, plus tôt dans l’année. Une optique de l’acceptance testing qui diffère un peu de la mienne, mais sans être incompatible (si, si !).

Open Agile Adoption, par Pablo Pernot et Oana Juncu

Encore une session à laquelle j’aurais aimé pouvoir assister si j’avais pu me dédoubler. Too many sessions, so little time…

Ici, Oana et Pablo nous dévoilent (en partie) le framework de Dan Mezik.

Créer le bon produit avec le Lean Canvas, par Romain Couturier

Romain a vécu un ScrumDay mouvementé, avec une panne de sonorisation suivi d’un changement de salle. Ici Romain nous parle du Lean Startup et plus précisément de l’outil de référence développé par Ash Maurya .

Les nouveaux outils du Product Owner

Story Mapping, Impact Mapping, Lean Canvas et Kanban : ce sont les « nouveaux » éléments que nous propose Claude pour le Product Owner.

Agilité : la fin du middle management ? Par Kevin Maccioni et Fabien Barbaud

Avec le passage à Scrum, le retour d’expérience des deux orateurs les amènent à répondre oui !

Introduction to Visual Management, par Natalie Yadrentseva

Je ne suis pas certain de joindre ici le bon support, je l’avoue…

Certains éléments de cette présentation me rapellent furieusement le Lightning Talk d’Igor Sviridenko à l’Agile France 2013…

Devops Game, par Vincent Daviet

Le troisième atelier Zenika de ce ScrumDay nous était proposé par notre nouveau venu Lyonnais avec ce Devops Game que je n’ai hélas pas pu expérimenter.

Podojo : PO, viens t’améliorer par la pratique avec nous ! Par Guillaume Duquesnay et Nicolas Verdot

A défaut d’un support de présentation, voici une petite vidéo avec une interview de Dominique Lequepeys sur cet atelier

Le Product Owner est-il un Product Manager agile ? Par Sébastien Saccard

Sébastien Saccard n’est pas un inconnu pour moi : tout d’abord il fut à l’initiative du workshop d’Ash Maurya à Paris, ensuite en tant que président de l’association We Do Product Management, il fut à l’instigation de la rencontre avec Gojko Adzic hébergée chez Zenika.

Sébastien cherche à développer le métier de Product Manager en France. Sa présentation va dans ce sens.

Vous pouvez aussi retrouver la présentation de Sébastien sur son Blog.

Agile-Lean-Kanban : Le guide du routard 2014, par Christophe Keromen

Bien rodée, j’avais eu l’occasion d’assister à cette très vivante présentation de Christophe à l’Agile Tour Rennes 2013. Mais était-ce réellement la même ?

My Product is a James Bond Movie – part V, par Pierre Neis

Les présentations de Pierre ne ressemblent à rien de connu ! Elles sont difficile à raconter, et je doute que le support ci-dessous lui rende justice. J’avais assisté à la « part I » de cette série « James Bond Movie » lors de l’Agile Tour Bruxelles 2013 … nous voici rendu au 5ème opus !

Développer en mode Kick-Ass, par Samuel Le Berrigaud

Le Kick-Ass de Samuel, cela me fait penser au « programming motherfucker » ! D’ailleurs en fait, il en parle dans sa présentation. Je vous recommande ce support pas mal du tout … en attendant la vidéo !

De la culture projet à la culture produit, par Céline Stauder et Gregory Alexandre

La présentation de Céline et Grégory est tout à fait dans le thème de ce ScrumDay. Par contre le support ne vous permettra guère de saisir la substance de la présentation !

Le prétotyping, avec Elalami Lafkih

Le prétotyping, c’est du prototypage « low cost », plus tôt donc avec un feedback anticipé. Elalami nous en expose un certain nombre de techniques. J’ai repris le support de l’orateur utilisé durant l’Agile Tour. Je suis parti du principe qu’il s’agissait du même…

Kapla Challenge, avec Dragos Dreptate

Construire un pont par itération (avec des Kapla), c’est le challenge que nous propose Dragos durant cet atelier

Faire Agile, c’est bien…, par Aurélien Morvant et Simon Jallais

Simon et l’homme aux chaussures de couleurs différentes nous proposent de découvrir ce qu’est « vivre agile ». Une session plutôt décalée !

DSL et refactoring pour les tests d’acceptation, par Laurent Py

Laurent nous fait partager son expérience ATDD / Devops chez Smatesting. En fait, la session ressemble terriblement à une promotion de l’outil Zest’ qui est, oh surprise, développé par la société dont Laurent Py est CEO !

Bon, voici quand même cette présentation…

Les reportages du ScrumDay

Une petite séquence « fun », tournée en bonne partie durant la pause déjeuner du second jour.

Et le reportage du ScrumDay, avec quelques interviews et des interventions de Xavier Warzee et Alistair Cockburn

Ils en parlent aussi…

Quelques liens vers des articles de blog que j’ai peu glaner à droite et à gauche. Si vous avez d’autres liens, n’hésitez pas à m’en faire part.

Il y avait une Coach Clinic, mise sur pied par Fabrice Aimetti et Bruno Sbille. Côté Zenika, Géry Derbier y participait ainsi que Laurent Sarrazin pour Rupture 21. Un compte-rendu est disponible sur le site d’Ayeba.

Alex Boutin nous livre sur son Blog la manière dont il a vécu ce ScrumDay.

Un retour de Laurent Sorin sur la table ronde menée par Véronique Messager

Autre retour également en provenance d’Ippon, un feedback sur la session de Rachel Davies par Victoria Pedron.

Dominique Lequepeys nous adresse les points forts des sessions auxquelles il a participé. Youpi, ceci inclut la mienne !

Christophe Deniaud fait aussi son billet de Blog sur les sessions qu’il a vu, ainsi que sur l’open-space. Lui aussi donne son feedback sur mon atelier. Pas sûr que mon message principal sur l’écriture collaborative des tests soit bien passé…

Coactiv nous livre aussi ses retours.

Carnet de route : Le ScrumDay 2014 (3/4)

Nouvelle journée, nouvelle énergie. Après la journée conférence que je vous ai comté ici et ici, voici la journée consacrée à l’open-space, à l’image de ce qui se fait à Grenoble depuis quelques années déjà.

L’organisation met à notre disposition tout ce qu’il faut pour se remettre dans le rythme : thé, café, jus de fruits, viennoiseries…

image

Mais on est vite intrigué par le grand cercle matérialisé à même le sol autour duquel nous sommes invités à nous rassembler pour débuter cet open-space.

image

Ce sont Laurent Bossavit et Raphael Pierquin qui se chargent d’expliquer les règles de fonctionnement de l’Open-space … ou du moins tentent de le faire ! Apparemment, la sonorisation pose quelques problèmes…

image

Le principes sont en fait assez simples. Une fois établis, il est temps d’utiliser le matériel mis à notre disposition au centre du cercle pour proposer nos sujets.

image

Ces sujets sont ensuite eux-mêmes affichés sur les différents créneaux horaires en mode auto-organisé. C’est la « place de marché ».

image

J’ai posté mon propre sujet. Il est temps de faire le tour de ceux qui peuplent le premier créneau horaire. Et je reste un peu perplexe devant le sujet traitant de l’utilisation des points de fonction dans les projets agiles. Quand je vois ce genre de sujet, mon reflexe est de me demander en quoi ces techniques peuvent nous apprendre quelque chose, si la technicité développée ici peut nous aider. Laurent Bossavit semble plus circonspect quand aux motivations. Du coup, nous décidons tous deux de nous joindre à ce débat.

Agilité et point de fonction

La première chose qui me trouble est une certaine confusion entre l’outil et l’usage. Dans l’esprit de beaucoup, il y a une relation directe entre projet au forfait et point de fonction.

image

En fait, il semble même que nous ayons un pattern d’usage : on se sert des points de fonction comme outil « commercial » pour chiffrer une réponse à appel d’offre. Ensuite, lors de la réalisation, on se servira des story points. Voilà un constat assez troublant pour moi, bien qu’instructif sur la vision que l’on peut avoir des différents outils :

  • Les points de fonction sont vus comme un outil donnant un chiffre absolu, alors qu’il donne un chiffre relatif (les points) qui se transforment en charge via des facteurs d’ajustements. Comme les story points, en fait, bien que de façon plus complexe.
  • Quel est l’intérêt de faire un « chiffrage agile » si en amont le projet est de toute manière verrouillé par un chiffrage contractuel ? Je dirais même : quel est l’intérêt de faire le projet en agile, mais c’est sûrement une autre question…

La discussion s’est beaucoup focalisée sur l’usage de l’une ou l’autre approche, alors que je pense que la question n’est pas là : on peut parfaitement utiliser les FP ou les story points dans les mêmes contextes.
Par contre les points de fonctions traitent des « blocs » plus gros, qui sont ensuite décomposés sous l’angle technique (requêtes, entités, I/O, etc…), alors que les story points s’adressent à des blocs plus fins que l’on évalue globalement, en différent les questions sur les choix de conception. Par son approche les points de fonction « vérouillent » les choix techniques dès le chiffrage.

image

J’ai été assez déçu par le débat qui ne s’est finalement pas dirigé vers la question de la nature de ces différents types d’estimation (ce que j’évoque plus haut). Dommage…

Ressources Humaines et agilité

Ce sont à la fois l’originalité du sujet et son importance qui m’ont attiré vers ce groupe. Une groupe à coloration un peu « grandes gueules » avec Pablo Pernot et Pierre Neis, par exemple !

image

Tout d’abord, quels sont les problèmes ?

  • La gestion du parcours professionnel.
  • La gestion des évaluations.
  • La dissonance cognitive entre rôle et fiche de poste.

Le constat partagé par tous est qu’aujourd’hui les RH ne sont pas une aide au sein des projets agiles. Dans le meilleur des cas. Dans le pire des cas, elles sont un frein, voir un obstacle. Bref, il n’y a pas grand monde dans le cercle à aimer les RH. On entend même que les RH n’ont pas de raison d’être !

image

Mais il nous faut aussi admettre que l’on doit mieux comprendre le problème des RH : celui de devoir composer avec la loi, le management, les syndicats, le C.E., etc… En fait, il nous semble que leur effort porte plus sur la composition de ces contraintes que sur une véritable fonction support au sein de l’entreprise (ce serait plutôt un fonction contrainte !). Le mécanisme des entretiens annuels est bien entendu montré du doigt.

Alors, quelle solution pour la RH dans un environnement agile ?

C’est que cette RH devienne elle-même agile, en portant les valeurs agiles au niveau de l’entreprise. Entre autre choses.

image

Pause déjeuner

Pas de pause déjeuner bien calée dans le temps pour cette journée open-space ! Les session occupent les créneaux horaires sans discontinuer. Aux participants de faire une pause quand ils le désirent !

image

On est un peu plus en mode picnic que la veille, d’ailleurs les tables ont disparu au profit de quelques « mange debout », mais on s’assoit aussi par terre.

image

Cela ne veut pas dire que la qualité n’est pas au rendez-vous. Au contraire ! Je n’ai aucune raison de renier mes éloges d’hier. Jugez-en !

image

De mon côté, j’ai passé cette pause déjeuner avec Pierre Hervouet, Joumana et Pierre Neis. Pierre Neis nous parle (et nous montre des photos) de #play14, un rassemblement autour des agiles games qu’il co-organisait au Luxembourg. Prochaine étape : en faire une sorte d’Agile Tour des agile games !

Le bureau du SUG en mode Happy

Christopher Mann était le photographe de ce ScrumDay (il avait fait un excellent boulot lors d’Agile France, une bonne raison pour moi de le recommander pour cet évènement). J’ai suivi le mouvement, quand lui-même et le bureau se sont dirigé vers l’extérieur pour ce qui semblait une photo de groupe. Le résultat est visible sur le reportage du ScrumDay, mais j’ai aussi pris mes propres clichés…

image

Backlog, cher boulet…

J’avais aussi soumi mon propre sujet. En quelque sorte une reprise d’un de mes thèmes préférés sur le backlog produit, à la fois vision de ce qu’il y a à faire et frein du changement.

image

Au final, on trouve deux grand types de situation :

  • Les projets agiles « classiques » où la vision d’un périmètre complet est plutôt une chose souhaitée. Le backlog Scrum rempli bien son office car il donne une vue partagée à tous les acteurs du « reste à faire ».
  • Les projets innovants pour lesquels on essaie de limiter le stock par diverses approches (parfois combinées) : approche type « kanban » où l’on limite volontairement et activement le nombre d’items dans le backlog, où backog à granularité différentielle, à deux ou trois niveaux.

Dans le cas d’une approche « kanban » nous nous sommes posé la question d’évacuer, c’est à dire supprimer les items de plus basse priorité dépassant le WIP. Nous en sommes arrivés à la conclusion qu’il n’y a aucun dommage à le faire : si l’item est important, il reviendra !

J’ai aussi évoqué les sujets qui m’interpellent en ce moment : combiner un backlog (limité) avec une approche type impact mapping et/ou Lean Canvas. Mais nos réflexions n’ont pour l’instant pas abouti…

image

Clôture des ScrumDays

Ce grand open-space s’est terminé par une retrospective type « tour de parole ». Un tour de parole à près de 200 personnes, il faut dire !

image

Il me manque le courage (ou la motivation) pour en être. Je préfère passer un peu de temps avec Samira Batahouche d’IBM qui représentait Big Blue au bureau l’an dernier et avait accueilli le ScrumDay à Bois Colombe l’an dernier.

Le stand de Cloudbees est juste à côté, j’en profite pour fixer pour la postérité Nicolas De Loof en hôtesse d’accueil…

image

Scrum.org était aussi partenaire du ScrumDay cette année. Je me suis vu interdire de prendre le stand en photo, une première pour moi. J’ai moi-même étendu cette interdiction à la keynote de clôture faite par son représentant (je ne me souviens même plus de son nom, pourtant il s’est cité lui-même durant sa présentation).

J’avais aussi décidé de ne prendre aucune note de l’intervention pour faire bonne mesure. Grand bien m’en a pris : elle manquait complètement d’intérêt, j’ai failli quitter la salle. Finalement je suis resté et j’ai consulté mon fil Tweeter pendant le reste de la présentation.

Si j’étais parti, je n’aurais pu prendre en photo l’équipe du French SUG, et cela aurait vraiment été dommage. Grand merci à toute l’équipe pour ce bel évènement ! De droite à gauche : Anne, Christopher, David, Arnaud, Valérie, Karine, Laurence et Xavier.

image

Voilà, il est temps de replier tous le matériel, et de tout remettre dans les cartons … jusqu’à l’an prochain.

image

Note à moi-même

Pour ce qui est du format tout d’abord : le ScrumDay (ScrumDays, donc comme je l’ai écrit par ailleurs), ça marche ! Les open-spaces dans des « coins de salle » ne sont toutefois pas une configuration idéale. il faudra trouver mieux et surtout moins bruyant !

Cette année, le thème était la « culture produit ». En fait cela ne me paraissait pas si évident au vu du programme. Maintenant, est-il nécessaire d’avoir des thèmes annuels ? Des tracks thématiques feraient assez bien l’affaire.

Concernant le lieu, eh bien il a clairement la taille voulu pour accueillir l’évènement. Le hall central (qui hélas n’était pas central) permettait une bonne circulation. Les stands des sponsors étaient disposés sur le pourtour.

Question sponsors, leur nombre était réellement à l’inflation, et cela fait un peu ressembler le ScrumDay à une expo (sans compter un traitement pas différentiant des platinums) … La raison est bien entendu le coût d’organisation, car le lieu est apparemment très cher, malgré son éloignement de Paris.

J’avais crains que cet éloignement, justement,  soit une cause de désaffection, d’autant que la venue en voiture n’est pas vraiment facilitée (pour ne pas dire franchement découragée), mais il semble au final que ce facteur n’ait eu aucune influence.

Bref, un bel évènement, avec deux fois plus de plaisir pour deux fois plus de durée !

Une dernière chose : nous n’en avons pas fini avec ce ScrumDay : je vous ai promis un 4ème volet : ce sera un « bonus track », je n’en dis pas plus. Je ferais aussi un petit post sur mon atelier sur l’acceptance testing.

Gojko Adzic : Making impact !

L’association We Do Product Management nous proposait ce 11 Mars une soirée exceptionnelle avec 2 orateurs. Gojko Adzic himself nous proposera une présentation sur le thème “making impact” tandis que Nicolas Gouy nous gratifiera d’un développement autour de l’Agile with GUTS !

Zenika accueillait cette soirée : un grand merci à Sébastien Sacard et Lisa Marçais du côté du WDPM, et aussi à Al chez Zenika pour son aide avant, pendant et après la soirée !

On commence d’ailleurs par une petite présentation du WDPM avant d’attaquer les choses sérieuses.

image

Making Impact par Gojko Adzic

La définition amont d’un produit se heurte à des facteurs d’imprédictabilité. Facteurs que l’on connait par ailleurs depuis plus de 100 ans :

  • Le facteur local
  • Le facteur temps
  • Le facteur Humain

Ces facteurs ont été identifiés par Peter Palchinsky. Dans The Ghost of the Executed Engineer, les auteurs reviennent sur certains désastres de l’Union Soviétique illustrant les facteurs de Palchinsky. Intéressons-nous spécifiquement à l’un d’entre-eux: le canal de la Baltique à la Mer Blanche.

image

Ce canal peut être considéré comme un succès, car il a bel et bien vu le jour, comme prévu. Cependant, il échoue aux 3 critères da Palchinsky et malgré son existence c’est effectivement un échec cuisant :

  • Le facteur temps : la construction du canal n’a pas anticipé l’évolution des cargos. En définitive, le canal s’est avéré rapidement trop peu profond pour les nouveaux navires !
  • Le facteur local : Sa situation septentrionale le rend gelé, donc impraticable 6 mois par an !
  • Le facteur humain : creusé à main d’hommes par des prisonniers dans des conditions extrêmes, il aura coûté le vie à 200000 d’entre-eux !

Autre exemple d’échec : le PC Junior d’IBM. Cette aventure coûta à IBM pas moins de 2 milliards de dollars ! Et pourtant, le géant de l’informatique ne fit jamais que délivrer exactement ce que l’utilisateur voulait ! Mais il échoua sur l’imprédictabilité du facteur humain.

D’un point de vue du Product Manager, on tend à planifier comme si tout était sous notre contrôle. Il faut au contraire créer des plans à même d’exploiter cette imprédictabilité au lieu de la combattre vainement.

Rechercher de nouvelles idées, essayer de nouvelles choses.

Cette approche trouve une incarnation dans le Set Based Design, l’aptitude à essayer différentes solutions en éliminant progressivement les moins valables.

En 2002 (ou était-ce en 2003 ?) Ducati se lance dans l’aventure Moto GP. Plutôt que d’essayer de construire d’emblée la meilleure moto, les ingénieurs conçoivent un engin sur lequel ils peuvent essayer multitude d’options. Après des débuts laborieux, celle-ci devient redoutable en seconde moitié de saison et l’écurie finit 2nd au championat constructeur !

Vous courrez après le déploiement continu ? Mais qu’en est-il de votre capacité à multiplier les versions, les comparer, créer des variations ? Cette approche permet d’expérimenter et d’apprendre. Bref essayer de nouvelles idées pour comprendre dans quelle direction il convient de se diriger !

La survivabilité

Le principe est simple : si votre expérimentation échoue, que les dommages en soit minimes … en tout cas que cela ne fasse pas couler l’entreprise !

Les connaissances et les pratiques d’ingénierie sont là … mais pas l’état d’esprit du product management !

Selection

Il faut faire le nettoyage sur ce qui ne sert à rien ou ce qui a échoué. En développement logiciel on ne supprime jamais rien (on garde, on ne sait jamais…). Et ce code ou ces composants morts deviennent un passif qui nous empêche d’avancer.

Non aux roadmaps, oui aux map of roads"

Mauvaise nouvelle pour les agilistes : le Product Manager n’est pas intéressé par les User Stories ! Ou plutôt, il est intéressé par leur faible granularité et leur côté “survivable” !

C’est le boulot du Product Manager de se créer des options, et les User Stories sont un bon outil pour cela : explorer des directions, sélectionner, changer d’option … bref tout sauf un plan linéaire ! Quelque chose qui ressemblerait à un plan avec un GPS pour s’y diriger. Ce GPS, c’est l’impact Mapping !

L’alignement rapide avec l’impact Mapping

L’impact mapping, c’est avant tout 4 questions pour arriver à une meilleure solution : 

  • Pourquoi ?
  • Qui ?
  • Comment ?
  • Quoi ?

Ce framework nous aide, car il nous évite de nous enfermer dans une logique unidirectionnelle, il nous permet d’explorer des variations : cette hypothèse contribue-t-elle au pourquoi ? Dois changer le “quoi” … ou m’intéresser à un autre acteur… S’il est parfois difficile de déterminer le pourquoi, les clients ont souvent moins de mal à dire ce qu’ils ne veulent pas. C’est un autre moyen d’arriver à nos fins !

On peut rapprocher l’approche Impact Mapping du Design Thinking : se générer des options, les explorer et les éliminer ! On a changé le mode dialogue au niveau du product management : on est passé du sacro-saint périmètre aux options et à leur contribution à un objectif…

Nicolas Gouy : Agile with GUTS

Nicolas est l’auteur d’un ebook portant ce titre et publié par infoQ.

image

Désolé pour la piètre qualité de la photo, vraiment l’éclairage (ou son absence, plutôt) m’a rendu la tâche difficile…

Parlons de valeur

Tout d’abord, c’est une notion subjective ! Et comme l’a indiqué précédemment Gojko Adzic, elle est subordonnée aux facteurs d’imprédicatabilité. Histoire de bien commencer, et de commencer fort (je dois dire), Nicolas nous parle des Shreddies. Les voici en image, pour illustrer le propos.

image

En passant d’un modèle à l’autre (sic !), Schreddies a vu son chiffre d’affaire s’envoler : la valeur n’est pas une question de sens commun ! Mais cela se travaille. Pourtant, sur nos projets agile, nous arrêtons notre horizon au backlog, comme si ce qu’il y avait avant était tabou !

Dans GUTS, il y a “G”, et ce “G”, c’est le Goals ! Notre but, c’est d’avoir un impact en étant en empathie avec notre client.

Le “U” quand à lui, c’est “Uncertainty”, et nous retrouvons les éléments que nous a partagé Gojko juste avant : il nous faut être à l’aise avec cela, et même en tirer parti. Comment ? En “crash testant” nos idées, en les validant au plus tôt.

Le “T” est plus original, car il s’agit du “Trade Off”. La solution parfaite est rarement un but désiré et raisonnable : il faut faire des compromis intelligents. Sur ce point, je ne suis pas sûr d’avoir compris ce que Nicolas voulait dire (exprimé plus simplement : je n’ai en fait rien compris). Bon, je verrais cela plus tard…

Le “S” signifie lui “Speed”. Une notion qui devrait remplacer celle de vélocité. Si la seconde notion couvre l’idée d’abattre plus de travail en moins de temps, la seconde consiste plutôt à atteindre un but plus rapidement … donc à être intelligent sur la manière d’y arriver ! C’est donc en fait remplacer la notion de périmètre par celle d’objectifs !

Quand on met l’acronyme ensemble, eh bien on parle bien entendu de “courage”. Et avoir du courage, c’est savoir être pertinent : toujours chercher à faire plus avec moins !

User Stories … What else ?

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

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