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.

Le chapitre 5, « deliver value » est en grande partie dédié au feature injection. A l’origine de ce concept, on retrouve Chris Matts, mais j’ai toujours trouvé ce concept pour le moins difficile à appréhender. C’est sans doute la première fois que je peux dire qu’il s’éclaircit raisonnablement, même si je ne peux encore prétendre me l’être totalement approprié encore. En bonus ce chapitre met en perspective le MVP (minimum viable product) qui est relatif au « discovery », avec le MMF (minimum marketable feature) qui appartient au « delivery ». Le chapitre 6 « analysis with an agile mindset » est le point d’orgue de cette première partie : l’auteur nous y dévoile l’articulation de sa démarche d’analyse en 4 étapes : de quoi avons-nous besoin ? Quelles sont les solutions possibles ? Que devons-nous faire ensuite ? Quels sont les détails ? Les pratiques associées seront évoquées en 3ème partie.

La seconde partie consacrée aux études de cas occupe 40 pages avec 4 chapitres. Le chapitre 7 qui ouvre cette partie est consacrée à un petit projet, un site pour les CFPs de l’Agile Alliance dont l’auteur était le PO. L’accent est mis ici sur la qualité de la collaboration et la légèreté des rituels ayant permis la co-élaboration de la solution entre les membres de l’équipe. Un projet peu significatif, toutefois. Au chapitre 8, on évoque sur quelques pages un système de gestion uniformisée des commissions d’un groupe ayant fortement grandi par croissance externe. L’approche articule parfaitement l’expression du besoin, l’énoncé des solutions possible et la delivery. On y apprend que ce type de projet s’inscrivant dans le changement doit s’aborder dans une vue plus systémique où tous les volets ne sont pas IT. De même, le choix d’un progiciel peut à la fois optimiser les coûts et assurer la mise en œuvre des pratiques correspondant à l’état de l’art, au prix du renoncement à certaines envies des utilisateurs.

Le chapitre 9 aborde un sujet orienté entrepôt de données, plus difficile à appréhender avec un écosystème métier et applicatif qui encombrent un peu le propos. Le focus de ce cas d’usage est la progression de la livraison de valeur et la manière dont peuvent être packagées des releases pour s’inscrire dans cette progression. Un propos hélas affaibli par un jargon trop hermétique. Le chapitre 10 qui clôt cette partie nous propose d’aborder un système de personnalisation de cursus destiné à une école. C’est l’occasion d’aborder le purpose-alignement model. Ici l’auteur nous invite également à reformuler les besoins en terme de finalité, une évolution majeure dans la manière d’aborder les spécifications agiles.

La dernière partie de l’ouvrage est un catalogue de techniques et il totalise 100 pages. Elle est composée de 5 chapitres dont la progression s’approche de celle dévoilée au chapitre 6. Le chapitre 11 qui débute cette partie est dédié aux pratiques nous permettant de comprendre les parties prenantes. La cartographie des parties prenantes et surtout l’échelle des engagements méritent une certaine attention. C’est moins le cas pour la cartographie des utilisateurs, tandis que les Persona méritent bien d’être mentionnées mais leur description ici ne peut guère servir de référence.

Comprendre le contexte, sujet du chapitre 12, est une activité trop méprisée. Le purpose alignement model y prend place, mais le texte de référence à son sujet reste « stand-back and deliver ». J’aime bien les « 6 questions », un moyen simple de donner du contexte stratégique. En revanche le Context Leadership model reste trop confus pour moi (sans parler de son bestiaire). L’usage que l’on peut en faire reste assez mystérieux. Dommage de ne pas y trouver de pratiques concernant le contexte applicatif. Au chapitre 13, pour comprendre le besoin, l’auteur nous propose le « decison filter » qui n’est pas spécialement dédié à cet effet. Le « project opportunity statement » mérite le détour, et le « problem statement », un grand classique, mérite le respect pour la manière simple dont l’auteur l’a gamifié !

Le chapitre 14, comprendre les solutions, nous emmène un peu plus loin que ce sujet sensu stricto. D’emblée, on attaque les deux grands classiques, l’impact mapping et le story mapping. Ce ne sont guère que des introductions, qu’importe les textes de référence sont bien connus. Le collaborative modeling nous ramène vers la gestion des exigences à l’ancienne, mais ces techniques n’ont pas perdu leur intérêt pour autant. La différence entre critères d’acceptation et tests d’acceptation est souvent mal expliquée et je ne cesse de croiser des personnes confondant joyeusement les deux ! Ici, le tout est parfaitement expliqué. Enfin le chapitre qui clôt l’ouvrage est orienté vers l’exécution : discovery et delivery boards, definition of ready et definition of done… Même la section sur la « system documentation » peine à donner un peu de corps à ce chapitre assez peu original.

S’il y a un absent de marque dans cet ouvrage, ce sont les User Stories. C’est exprès. Non seulement le sujet est traité ailleurs, mais l’auteur préfère centrer son propos sur les sujets d’avantage à coloration « discovery », la marque, s’il était besoin de le répéter, que cet ouvrage est bel et bien un texte sur l’agilité.

Référence complète : Beyond Requirements – Kent J. McDonald – Addison Wesley 2016 – ISBN : 978 0 321 83455 3