Note de lecture : When Coffee and Kale Compete 2nd edt., par Alan Klement

Note : 6 ; Une référence incontestable du « job to be done » mis dont le fil conducteur est des plus alambiqués !

Le « job to be done » est un concept à cheval entre le marketing et la démarche produit, mais il est pour moi d’avantage du côté produit. Le concept est alléchant, car il nous fait quitter le domaine de la solution et même celui de la demande du client pour nous diriger vers celui des aspirations ! La mauvaise nouvelle est que le concept même est abordé, interprété et décliné différemment selon les différents membres influents de cette petite communauté. Il faut bien s’accrocher du côté des ouvrages de référence, et celui-ci émerge très nettement. Nous allons rapidement le comprendre, même si le texte n’est pas exempt de critiques.

Avec 210 pages, cette nouvelle édition reste un ouvrage relativement succinct. Il compte 15 chapitres pour sa partie principale, mais je vais y adjoindre la première annexe qui est la reprise d’un post de l’auteur. Le premier chapitre « challenge, hope and progress » est plus qu’une introduction, il nous dévoile déjà une bonne part du sujet. C’est toutefois une introduction quand même, car il met en lumière les lacunes de l’approche centré sur les besoins utilisateur avec son cortège de biais cognitifs. Il aborde aussi un concept qui reviendra au gré des chapitres : la création destructive. Car quand un client adopte (l’auteur préfère le terme « embauche ») un produit, il en abandonne un moins bien adapté à ses aspirations.

Le chapitre attaque le cœur du sujet : qu’est-ce que le « job to be done » (JTBD) ? Deux écoles s’affrontent pour le définir, et il ne s’agit pas de subtilités. La première école définit le JTBD comme le résultat d’une activité, matérialisée par la citation désormais fameuse : « le client ne veut pas une perceuse, il veut un trou de 12 millimètres ». Pour la seconde école de pensée à laquelle appartient l’auteur, ceci est une démarche qui s’arrête à mi-chemin. Pour lui, il ne va même pas s’agir d’accrocher un tableau au mur, mais de pouvoir se relaxer dans un salon où il se sent bien ! Le concept formulé est le « self-betterness », une meilleure version de lui-même où le « meilleur » correspond aux aspirations du client. Le chapitre 3 complète le précédent en énonçant les principes clés de la démarche, tels que la notion de progrès, la notion de « système » auquel participent le client, le producteur, la solution, etc. Ces deux chapitres forment la base théorique du JTBD. Les chapitres suivants n’en seront que les déclinaisons pratiques.

Continuer à lire « Note de lecture : When Coffee and Kale Compete 2nd edt., par Alan Klement »

Note de lecture : Beyond Requirements, par Kent J. McDonald

Note : 7 ; Spécifier, avec un vrai mindset agile

De prime abord, le titre fait penser au mariage du veau et du cochon. Mais très vite, on comprends qu’il n’en est rien, bien au contraire. Car ce volume va au-delà de la compilation de pratiques d’analyse agile, nous allons voir cela.

L’ouvrage est de taille moyenne avec ses 230 pages structurées en 3 parties pour un total de 15 chapitres. La première partie « Ideas » est forte de 75 pages sur 6 chapitres. Ici, on parle surtout de culture agile, certes centrée sur l’analyse mais sans entrer en profondeur dans les pratiques. Dans le premier chapitre « guiding principles », Kent McDonald nous distille ce qu’il a condensé en 7 principes directeurs sur lesquels s’appuient ses manières de raisonner et de prendre des décisions. Par la manière dont ces principes sont pensés et exposés, nous voyons rapidement que l’auteur est un agiliste de très haut niveau. Peut-être est-ce la 15ème fois que l’on vous assène des principes fondateurs ? Ne manquez pas ceux-cis. Au second chapitre, on entre plus spécifiquement dans le domaine de l’analyse. Et ce sont les concepts structurant de l’analyse agile qui sont développés ici. La référence au BABOK (Business Analysis Body of Knowledge) est certes austère, mais les 6 concepts évoqués ici serviront de cadre au reste de l’ouvrage. Il aborde aussi 2 piliers importants de l’approche produit moderne : outcome versus output et la dualité discovery / delivery.

Signe de l’influence de l’approche produit dans son cadre de spécification agile, l’auteur rend hommage au Lean Startup au chapitre 3. L’auteur ne se contente pas de paraphraser Eric Ries : il projette les concepts de l’approche au monde de l’entreprise. Un bel exercice. La prise de décision, sujet du chapitre 4 semble être un des thèmes favoris de l’auteur. Au menu de celui-ci, nous avons tout d’abord les mécanismes de la prise de décision elle-même, bien décomposés. Kent McDonald semble apprécier Chris Matts, c’est sans doute pourquoi nous avons un coup de projecteur sur les « real options ». C’est un bon teaser à « Commitment » ! Enfin, c’est un plaisir pour moi de voir que les biais cognitifs qui entachent si grandement les processus de décision ne sont pas oubliés.

Continuer à lire « Note de lecture : Beyond Requirements, par Kent J. McDonald »

Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg

Note : 7 ; Pour capturer et écrire plus efficacement des exigences.

Le moins que l’on puisse dire est que ce livre ne date pas d’hier ! Il attire toutefois l’attention par au moins deux aspects : le premier est la cosignature de Gerald Weinberg. Le second se situe dans le titre car il y est question non pas de gérer, de collecter ou de capturer des exigences, mais de les explorer. C’est sans doute pour cela qu’il va être moins questions de processus que de pratiques centrées sur l’humain et l’aspect psychologique de cette exploration. Par certains côtés, on y côtoie l’agilité avant l’heure !

L’ouvrage en lui-même n’est pas anodin : il totalise près de 300 pages structurés en 25 chapitres, eux-mêmes regroupés en 5 parties. Toutefois l’ensemble se lit bien. La première partie compte un peu moins de 50 pages pour 4 chapitres et son thème attire tout de suite l’attention, car il y est question de négocier une compréhension commune ! Le premier chapitre prend le contrepied des méthodologies, mais en fait c’est des notations qu’il s’agit. Et les auteurs, à l’aide d’exemples très simples mettent en évidence à la fois la difficulté sous-estimée de compréhension des notations et introduisent la notion d’ambiguïté des exigences, qui sera particulièrement le sujet du second chapitre. Ce second chapitre est plutôt court et va se limiter à définir cette notion d’ambiguïté dans le domaine du recueil des besoins, et ses conséquences. Mais ce thème reviendra au long de l’ouvrage.

D’ambiguïtés, il est toujours question au chapitre 3, qui va adresser les sources d’ambiguïté : observation, interprétations dans lesquelles le facteur humain vient s’insérer. Les recherches de Daniel Kahneman n’étaient pas encore popularisées mais elles auraient pu être citées ici. Les auteurs mettent néanmoins en relief ces biais au travers d’exercices pratiqués en séminaire. Pour refermer cette première partie, les auteurs s’attaquent à la pratique des questions directes au travers d’arbres de décision. Sans citer les biais cognitifs, ils mettent en question le postulat sous-jacent : la nécessité de s’adresser à des « êtres humains parfaits ». S’ils ne sont pas opposés à leur emploi, le verdict est que cette pratique ne suffit pas.

Continuer à lire « Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg »

Note de lecture : Requirements by Collaboration, par Ellen Gottesdiener

Note : 4 ; Malheureusement bien pauvre sur la substance même de cette collaboration !

J’ai été attiré par ce titre, aussi bien par le thème aussi original qu’important dans les pratiques d’identification du besoin, que par des recommandations tierces. La littérature adressant la manière de collecter, structurer et formaliser les exigences est très importante. Nombre de ces ouvrages sont d’ailleurs excellents ! Mais les textes traitant des interactions entre personnes pour les faire émerger est beaucoup plus réduite. Le présent ouvrage est peut-être le seul entièrement dédié à ce sujet ! Le texte n’est pas récent, il date du début des années 2000 alors que l’agilité en était à ses débuts. Aussi n’y trouverons-nous aucune référence à ce mouvement, même si de nombreuses idées sont convergentes.

Le livre lui-même comprends près de 280 pages. Il est structuré en 3 parties pour un total de 12 chapitres. La première partie nous promet un tour d’horizon des ateliers de définition des exigences, sur 3 chapitres pour environ 65 pages. Elle s’ouvre sur un très classique « getting started », en guise de premier chapitre. Il a pour but de cadrer la suite du sujet, tout d’abord en définissant les différents types et niveaux d’exigences. Ensuite en clarifiant la notion d’ateliers, ceux abordés ici s’inspirent du Join Application Design (JAD) qui nous conduisent à considérer différents types d’ateliers en fonction de leurs finalités. Le chapitre fait bien le travail, on y voit bien plus clair en l’ayant terminé.

Au chapitre 2, nous allons rentrer plus en profondeur sur ce que nous cherchons obtenir des ateliers, donc les artéfacts. Pour ceux qui ne sont pas familiers de la littérature sur la gestion des exigences, ce sera sans doute une découverte de voir le nombre et la variété de ces artéfacts. Bien que l’on ne rentre pas encore dans le cœur du sujet, le propos est intéressant et bien construit. Cette première partie se clôt sur l’aspect préparatoire des ateliers : l’espace, les invitations, l’état d’esprit avec lequel il faut venir. C’est un peu verbeux et enfonce parfois les portes, mais cela reste bien fait.

Continuer à lire « Note de lecture : Requirements by Collaboration, par Ellen Gottesdiener »

Note de lecture : Use Case Modeling, par Kurt Bittner & Ian Spence

Note 6 ; Cas d’utilisation & Unified Process !

Cela n’apparaît pas dans le titre, mais voici le livre officiel sur l’utilisation des cas d’utilisation dans le RUP. Cela explique, comme nous le verrons, une orientation de l’ouvrage clairement orientée vers le processus, plutôt que vers la modélisation. Le cadre est donc franchement prescriptif, mais aussi avec quelques avantages à ce positionnement : l’articulation avec d’autres éléments du processus.

Le texte en lui-même couvre 300 pages sur 12 chapitres. Quand on considère le thème, on peut considérer que c’est un ouvrage franchement volumineux. Mais les chapitres restent de taille raisonnable. Le tout est structuré en deux parties. La première couvre 145 pages pour 5 chapitres. Son objectif est de nous mettre le pied à l’étrier avec les cas d’utilisation. Le premier chapitre est la très classique introduction, destinée à nous permettre d’appréhender la place des cas d’utilisation au sein de la gestion des exigences. Le style est plutôt guindé, mais néanmoins efficace pour à la fois donner un peu de contexte Unified Process et évoquer les finalités des cas d’utilisation sans les trahir.

Le second chapitre s’attaque aux éléments fondamentaux des cas d’utilisation. En réalité il couvre bien tous les éléments nécessaires pour les mettre en œuvre à l’exception des éléments les plus exotiques. L’approche consiste en une déconstruction systématique des éléments méthodologiques : éléments du modèle, acteurs, flux d’évènements, mais aussi artéfacts support. Le tout hélas sans exemple et sans aborder le fond de ce que sont les cas d’utilisation au long de ces 30 pages. Bref, tout y est, sauf l’essence même des cas d’utilisation. Le chapitre 3 parle d’établir la vision, mais en fait le titre est un peu trompeur : il traite de manière plus générale de l’approche « feature » telle qu’elle est proposée par Dean Leffingwell dans « Managing the Requirements process ». Une approche une fois encore très orientée processus à tel point que les presque 40 pages du chapitre s’articulent en étapes ! Cette approche vient, en théorie, intersecter l’approche Cas d’Utilisation qui a une orientation plus comportementale. Dans la pratique, les deux approches ne se rencontrent guère ici. L’un des points forts de ce chapitre est l’étude minutieuse des parties prenantes et de leurs représentants.

Continuer à lire « Note de lecture : Use Case Modeling, par Kurt Bittner & Ian Spence »

Note de lecture : Thinking, Fast and Slow, par Daniel Kahneman

Note 9 : Une plongée dans nos 2 systèmes de décision et les biais qu’ils engendrent. Une lecture indispensable pour les managers et les responsables produits (et tout le monde, en fait).

Voilà un volume qui a pris la poussière durant de longues années sur mes étagères. Je savais que c’était une erreur, mais que ce n’était pas non plus une lecture légère. J’avais raison sur les deux points. Bien que psychologue, l’auteur peut s’enorgueillir d’un prix Nobel d’économie, pour avoir été à l’origine de l’économie comportementale, prix qu’il partage de cœur mais non de fait avec Amos Tversky décédé prématurément avec lequel il a mené une majeure partie de ses travaux.

Comme je l’ai dit, ce volume est plutôt conséquent : il affiche plus de 400 pages (hors annexes) structurés en 5 parties totalisant 38 chapitres. Ce sont donc en moyenne de petits chapitres ce qui rend la lecture plus fluide. La 1ère partie « two systems » regroupe 8 chapitres sur une centaine de pages. C’est assurément la partie le plus importante, au moins en termes de contenu. Il développe la nature des deux systèmes et consacre plusieurs chapitres aux travers du « système 2 », posant les bases des biais cognitifs que nous verrons ensuite : sa tendance à sauter directement aux conclusions, de fonctionner par ressemblance, ou même de substituer à une question difficile une question plus facile. Le propos s’appuie sur la description des heuristiques, mais l’auteur nous propose aussi nombre d’exercices à essayer ! Assurément une partie passionnante.

La seconde partie « heuristiques et biais » compte 9 chapitres pour 90 pages. Elle aurait pu s’intituler « les fails du système 2 ». Ainsi découvre-t-on la confiance exagérée que l’on peut accorder aux évènements peu fréquents, les ancrages dans lesquels nous enferment une information récente ou la tendance à limiter nos conclusions aux informations disponibles, même en les sachant incomplètes. De tous la « régression vers la moyenne » est sans doute le concept le plus difficile à appréhender naturellement, car il s’oppose à notre approche causale, selon l’auteur.

Continuer à lire « Note de lecture : Thinking, Fast and Slow, par Daniel Kahneman »

Note de lecture : Software Requirements 3rd edition, par Karl E. Wiegers & Joy Beatty

Note : 6 ; Il échoue à se mettre au goût du jour et déçoit sur sa prise en compte de l’agilité

J’avais adoré la 1ère et la seconde édition, c’est avec un plaisir par anticipation que j’abordais ce 3ème opus. J’ai l’habitude de faire perdre un point de note à une édition qui ne fait que se maintenir par rapport à l’édition précédente. Las, ce n’est pas 1 mais 3 points qu’a perdu cette édition-là ! J’avais gardé un excellent souvenir de la seconde édition et m’attendais à une modernisation conséquente du texte, plus particulièrement sur la convergence avec le mouvement et les pratiques agiles. Sur ce dernier point plus particulièrement les auteurs ne sont pas dans le coup et la déception est grande. Le texte reste un ouvrage majeur toutefois dans l’ingénierie des exigences. Voyons cela.

Ce sont 550 pages que compte ce 3ème opus, structurées sur 5 parties pour un total de 32 chapitres, hors annexes. Et ces dernières sont conséquentes. Ce n’est pas ce que l’on peut appeler une lecture légère, ni par le volume ni hélas non plus par le style. La première partie est forte de 4 chapitres sur 75 pages et va nous camper le décor de l’ingénierie des exigences. Le premier chapitre est fort bien fait, il donne la big picture des exigences, avec les différents types (dont les fameux NFR, Non functional Requirements), et comment ils s’articulent sur 3 niveaux. On y a un aperçu quoique superficiel du cycle de vie des exigences et des enjeux de leur bonne gestion. Le second chapitre est consacré aux exigences du point de vue des utilisateurs. On apprend donc à les distinguer et à identifier le décisionnaire. Le point réellement intéressant de ce chapitre sont les « bill of rights / bill of responsibilities » des utilisateurs.

Le chapitre 3 nous sert les « bonnes pratiques » du développement et de la gestion des exigences. Il y en a vraiment beaucoup. De fait, c’est un peu la table des matières de la seconde partie de l’ouvrage. Un chapitre pas spécialement sympathique à lire. Cette première partie se referme sur l’analyste : sa vie, son œuvre et ses compétences. Un chapitre bien fait, très clair sur ce qu’on attend d’un bon analyste.

Continuer à lire « Note de lecture : Software Requirements 3rd edition, par Karl E. Wiegers & Joy Beatty »

Note de lecture : Agile Software Requirements, par Dean Leffingwell

Note : 3 ; L’ancien testament de SAFe, sous un titre bien trompeur !

C’est vrai que je n’avais pas regardé de très près. Mais au vu du titre, je pensais avoir entre les mains la 3ème édition du « Managing Software Requirements », cette fois à sauce agile, avec la couche de peinture qui va bien. Il n’en est rien et ce n’est pas une bonne nouvelle.

Le livre est une belle bête, avec sa couverture dure et ses 470 pages (500 pages tout mouillé). L’ensemble est subdivisé en 4 parties totalisant 24 chapitres. Une belle bête, vous dis-je ! La première partie « the big picture » regroupe les 5 premiers et chiffre près d’une centaine de pages. A ce stade, cela reste encore mystérieux, l’objet de cette grande fresque. Toutefois le schéma qui figure en-dessous pourrait nous éclairer car il ressemble furieusement au poster SAFe. Les 26 pages du premier chapitre ont comme objet l’histoire de la gestion des exigences. Il s’agit en fait de l’histoire de la transition vers les approches agiles. Un chapitre agréable, néanmoins.

Avec le chapitre 2 et la grande représentation des spécifications agiles, les choses se précisent. Il ne s’agit pas des spécifications, mais de la vision « par étages » de la réalisation agile à grande échelle, celle qui deviendra SAFe et n’a déjà plus grand-chose d’agile. Ne nous vous inquiétez pas, le pire est à venir. Au chapitre 3, il est question des spécifications au niveau de l’équipe, ou du moins il devrait l’être. Il s’agit des User Stories, mais en fait le chapitre expose le fonctionnement de Scrum. Pour en savoir plus sur les US, n’importe quel autre texte vous en dira plus.

Continuer à lire « Note de lecture : Agile Software Requirements, par Dean Leffingwell »