Note de lecture : Fifty Quick Ideas to Improve your Tests, par Gojko Adzic, David Evans & Tom Roden

Note : 7 ; D’excellents conseils dans la lignée du titre éponyme sur les user stories

Gojko Adzic et ses co-auteurs ont gardé la recette qui marche avec ce nouveau titre. Celui-ci ne compte que 117 pages, et comme le titre le suggère : 50 conseils chacun occupant 2 pages avec une illustration quelque peu décalée. Ces conseils sont répartis en 4 sections.

La première partie « generating testing ideas » regroupe 12 conseils. Je citerais en particulier parmi ceux-ci la « big picture view of quality », un pendant pour les tests de la pyramide de Maslow. Un concept bien plus intéressant que la classique pyramide des tests rassemblant des choux et des carottes ! Le « tap into your emotions » nous donne un truc de plus pour explorer les tests à construire. « monitor trends in log & console » est une excellente idée pour chercher des éléments à inspecter. Enfin le « mob your test sessions » est une nouvelle variante du workshop des 3 amis, étendu à plus de personne et qui ne se limite pas à l’écriture des cas de test !

Lire la suite

Publicités

Note de lecture : Fifty Quick Ideas to Improve your User Stories, par Gojko Adzic & David Evans

Note : 7 ; De bonnes recettes, surtout pour le découpage des user stories

Les auteurs l’annoncent clairement dès le début : ceci n’est pas un livre pour le débutant. Il s’adresse à ceux qui ont déjà une connaissance et une compréhension de base de ce qu’est une user stories. Les 200 pages de l’ouvrage sont consacrées à solidifier cette connaissance et à améliorer le savoir-faire qui y est lié. Le tout en 5 parties et en, comme l’indique le titre, 50 idées ou principes. Je ne vais pas parler des 50 principes, ce serait fastidieux.

Chaque « idée » emprunte la même présentation. D’abord une introduction que l’on pourrait appeler « motivation ». Elle développe ce qu’il y a derrière le titre, le « pourquoi » de cette idée. Vient ensuite une section intitulée « key benefits », comme son nom l’indique elle met en exergue l’amélioration apportée par cette pratique ou le travers qu’elle évite. Enfin, la 3ème partie est consacrée au « how to make it works », c’est à dire le mode d’emploi.

La première partie est dédiée à la création de User Stories. Ce sont 8 idées sur environ 35 pages qui constituent celle-ci. On retrouve quelques idées qui font leur chemin aujourd’hui comme les « 3 C » de Ron Jeffries ou les 3 questions de Jeff Patton plutôt que le template de Mike Cohn qui perd son aura de jour en jour. Mon « take away » de cette partie est certainement la notion de sphère de contrôle liée à la sphère d’influence qui est le thème de l’idée n° 7.

Lire la suite

En finir avec les User Stories ?

Aujourd’hui je vous propose d’investiguer l’un des outils les plus emblématiques des approches agile : la User Story. Par son « focus » et la légèreté de son expression elle symbolise une part importante de ce que nous voulons faire en agile.

Créées avec l’Extreme Programming, elles ont été adoptées largement par la communauté Scrum (Scrum n’évoque qu’une notion plus générique de « product backlog item » ou PBI). Ces User Stories peuvent-elles nuire aux projets agiles ? En quoi leur usage peut-il être néfaste ?

3 mots sur un bout de carton !

…Ou sur un post-it, pour rester dans la tradition agile. Voilà qui nous change des documents de spécification tellement épuisants à compléter ! Sans compter que ces derniers sont vraiment ennuyeux : traquer la précision, chasser l’ambiguité, devoir tout justifier… Un vrai travail de romain !

Lire la suite

L’Impact Mapping s’invite au French SUG !

Décidément, cette nouvelle année du French SUG voit émerger une nouvelle dynamique : celle de permettre aux membres de la communauté d’être acteur des évènements ! D’accord, pour l’évènement de février on peut argumenter que je suis un ancien membre du bureau… Mais ce n’est pas le cas de celui-ci . Il a été imaginé par Géraldine Legris, épaulée par Dragos Dreptate.

image

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).

La seconde partie est la plus imposante du livre, avec environ 130 pages et 6 chapitres. C’est le cœur de l’ouvrage. Les 11 pages du chapitre 5 « deriving scope from goal » sont un prélude à « impact mapping » et on y retrouve les mêmes thèmes. Je ne peux qu’en recommander la lecture. Le chapitre 6 est un de mes thèmes préférés car on y évoque la spécification collaborative. Tous les patterns de cette vingtaine de pages valent de l’or. J’applique déjà certains d’entre eux mais trouve ici des éléments pour m’améliorer. Encore un chapitre à ne pas rater.

Les deux chapitres suivants sont au cœur de l’ouvrage. Le chapitre 7 aborde l’écriture même des tests, comment les concevoir, comment les penser pour couvrir une spécification. Là encore ce sont des patterns desquels se dégage une stratégie claire et précise : sur la conception des tests, des cas passants et non passants, des données de test et des exigences « non fonctionnelles » ! Le chapitre 8 est un approfondissement du précédent, avec un accent mis sur les antipatterns.

Il était probablement difficile de parler de ce sujet sans évoquer les questions d’automatisation. C’est ce que font les 2 chapitres suivant. Le chapitre 9 évoque les options techniques d’automatisation y compris l’épineuse question des IHM. Le chapitre 10 se préoccupe surtout de l’intégration de ces tests dans des plateformes d’intégration et des stratégies possibles : isolation des systèmes tiers, plusieurs niveaux de validation, etc. Le chapitre 11 qui clos cette partie reprend le thème de la « documentation vivante ». Les patterns n’y sont pas sans intérêt, mais il reste le chapitre le plus léger de cette partie.

La Troisième partie est consacrée aux études de cas, c’est à dire les projets principaux (pas tous) qui ont donné la matière au livre. Des 7 chapitres qui la compose, 6 sont consacrés à ces études de cas sur 40 pages. J’ai eu du mal à me passionner pour cette partie. Y sont exposés les challenges auxquels ces différents projets ont été exposés à leur passage à le spécification par l’exemple, pourquoi ils l’ont fait et ce qu’il y ont appris.

Le dernier chapitre du livre nous livre les conclusions de l’auteur. L’une des plus importantes me semble être le passage d’une pratique des tests basée sur la défiance (coûteuse et inefficace), à une dynamique basée sur la collaboration et la confiance. Pas étonnant que cette pratique marche mieux en milieu agile.

L’ATDD ou plutôt la spécification par l’exemple est aujourd’hui ce que je considère comme un des plus forts effets de levier pour un projet agile, une fois acquis les pratiques d’ingénierie. L’auteur aborde les différents aspects (collaboration, processus, écriture et conception) avec un regard aiguisé que corrobore des données de terrain. En le lisant, je suis passé du « waouh effect » au « mais bien sûr » jusqu’à « ah oui, c’est ce que je fais et ça marche du tonnerre ». Cet éventail de réactions me rappelle la lecture du Design Patterns. Une autre façon de dire que je pense qu’il s’agit là d’un texte majeur !

image

Référence complète : Specification by Example, How successful teams deliver the right software – Gojko Adzic – Manning 2011 – ISBN : 978 1617290084

Specification by Example

https://www.goodreads.com/book/add_to_books_widget_frame/1617290084?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

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 !

Note de lecture : Impact Mapping, par Gojko Adzic

Note : 8 ; Simple, puissant et très facile à lire !

A peine un livre, cette nouvelle prose est plutôt un livret de 70 pages. Et encore ! Nombre d’entre elles sont couvertes entièrement ou partiellement de figures pour non-voyants. Alors, comment prendre au sérieux un texte qui, entre nos mains, ressemble d’avantage à une plaquette publicitaire qu’à une prose solide, sérieuse et dense ?

La réponse est simple : il suffit de lire le livre ! Tout d’abord la technique elle-même est non seulement intéressante, elle est en train de devenir un grand classique de la définition des produits. Elle me rappelle en partie la pyramide de Leffingwell, mais projetée dans une réelle pratique agile, et m’évoque également le “start with a why” de Simon Sinek. L’autre aspect est la prose très épurée. On sent que l’auteur, loin d’avoir essayé de noircir du papier, à cherché à épurer sa prose. Au final, on obtient un texte très simple et court. Justement, le contenu, parlons-en !

Il est compose de 3 chapitres. Je les appelleraient “chapitres” même s’ils ne sont pas présents ainsi.

Le premier chapitre “what is an impact map” nous montre ce qu’est une “impact map” et l’illustre avec deux exemples. L’explication est très claire, mais le but de ce chapitre n’est pas d’indiquer comment on procède pour construire cet outil.

Le second chapitre “the role of impact map” fait le lien entre cette pratique et d’autres du monde agile : les user stories, le MVP du Lean Startup, le design thinking (une référence aussi importante que celle des users stories !). Ce chapitre donne de nombreuses références complémentaires, plusieurs à chaque page, en fait !

Enfin le troisième chapitre “creating an impact map” nous propose un processus complet de construction de la map en plusieurs étapes, dispensant de nombreux conseils pratiques au long du chemin. Ce chapitre se termine par différentes catégories d’anti-patterns, qui auraient mérité leur propre chapitre.

Vu la taille de l’ouvrage, celui-ci se lit très, très vite … et c’est tant mieux ! Notre temps est précieux et l’on appréciera l’auteur qui sait être concis et cependant nous livrer de la matière. La dernière page tournée, on pense quand même que l’auteur aurait pu donner un peu plus de corps à son propos. Par exemple, deux études de cas nous faisant vivre la construction de la map auraient donné un aspect plus concret à cette pratique. Je me dis aussi que les chapitres 2 et 3 auraient pu être intervertis avec profit (sauf les anti-patterns). Mais au final, je suis très satisfait par cette lecture.

Il s’agit là d’un investissement de temps extrêmement minime, n’en faites pas l’économie !

impact-mapping

Référence complète : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0

Impact Mapping: Making a Big Impact with Software Products and Projects

http://www.goodreads.com/book/add_to_books_widget_frame/0955683645?atmb_widget%5Bbutton%5D=atmb_widget_1.png