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

Note de lecture : User Story Mapping, par Jeff Patton

Note : 9 ; Bien au-delà du story mapping, vers la découverte de la vraie nature des spécifications agiles en tant que compréhension partagée. Book of the year 2015 !

Jeff Patton est un vrai maître Jeidi de l’agilité : après avoir lu, ou plutôt dévoré son livre, je n’en ai plus aucun doute ! Mais si vous pensez lire « simplement » un ouvrage décrivant par le menu la technique développée par Jeff Patton, vous allez être surpris ! Car c’est bien plus que cela.

Le livre fait un peu plus de 260 pages en 18 chapitres. Je dis « un peu plus de 260 pages » car le corps principal du livre est précédé d’une introduction « read this first » qu’il ne faut rater sous aucun prétexte. On y parle « instructions » versus compréhension partagée, de comparer les (docs de) spécification à des cahiers de voyage, de l’importance de raconter des histoire et d’être frugal dans la construction tout en cherchant à maximiser l’impact plutôt que les fonctionnalités ! Bref, cette introduction à elle seule a la valeur d’un très bon livre. Et ce n’est pas fini !

Raconter des histoires, c’est le sujet du 1er chapitre où l’auteur introduit les story maps dans le but de raconter la grande histoire du système, d’avoir une « big picture ». Il le fait d’ailleurs en racontant une histoire, celle de Gary par qui les user stories sont arrivées ! D’ailleurs la totalité du livre est formée d’histoires. Et celles-ci sont illustrées de photographies des fresques (en couleur dans la version anglaise) que sont ces stories maps auxquelles l’auteur surimpose des explications sous forme de cartographie.

Lire la suite

Note de lecture : Why Plans Fail, par Jim Benson

Note : 8 ; Où l’on parle (enfin) de biais cognitifs !

J’ai eu un peu de mal à classer ce texte. De par la nature du texte, il devrait plutôt se classer dans la gestion de projet, la gestion de projet agile pour être plus précis. D’un autre côté, la nature même du sujet me donnait envie de le classer dans l’expression de besoin : à mon avis la détection des biais cognitifs doit nécessairement faire partie de la boite à outil du Product Owner. Finalement j’ai opté pour le premier choix.

L’une des grandes qualités de ce mini-livre est sa brièveté : 82 pages (plus quelques annexes) sous un format des plus réduit. Il s’agit donc d’une lecture que l’on peut avaler en quelques jours, voir une seule journée ! Ce sont une douzaine de biais cognitifs parmi les plus fréquents qui sont évoqués ici, remis dans un contexte de projet informatique. Cela en fait un livre unique, car si le sujet est traité de manière plus extensive dans d’autres ouvrages qui font autorité et auxquels l’auteur se réfère, celui-ci est le seul à évoquer le propos dans le domaine qui nous concerne.

Le texte ne se veut pas un traitement en profondeur du sujet, mais plutôt une amorce de réflexion et de discussion autour de ces biais cognitifs. La prose est en effet découpée en 16 chapitres, qui ne comptent donc que quelques pages chacun.

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 !

Tout est incroyablement plus simple avec les User Stories. L’utilisateur évoque une possibilité ? Hop ! Une User Story ! Une idée autour d’un café ? En voilà une autre !

Plus besoin de gros document, simplement de me balader avec mon calepin sous le bras ! Hélas, cette simplicité est trompeuse. En nous débarrassant d’un artéfact lourd et compliqué, j’ai nommé le célébrissime IEEE 830-1998, les créateurs des User Stories voulaient laisser la place au vrai travail de spécification : l’observation du terrain, la collecte des informations, les conversations constructives, l’exploration des alternatives. Décider ce que l’on doit faire est souvent un véritable travail d’abnégation, ou du moins il devrait l’être.

La simplicité du formalisme des User Stories est trop souvent interprété comme une licence à la superficialité. Pourtant le corpus de connaissance existe, encore faut-il aller le chercher !

La littérature traitant des spécifications est riche de dizaines d’années de publication d’excellente valeur. Oui, d’excellente valeur. Tout cela a souvent été interprété à tord au sein des projets classiques comme la nécessité d’écrire de lourds et nombreux documents se paraphrasant entre-eux (et souvent eux-mêmes).

La spécification agile a fait table rase du passé et de ses enseignements. Table rase d’un formalisme qui a fini par prendre le pas sur le contenu.

Mais est-ce vraiment le cas ?

Template Zombies

Dans l’ouvrage qui leur sont consacrés [Cohn04], Mike Cohn nous propose une formulation aujourd’hui devenu le standard de rédaction des User Stories.

“En tant que xxx, je veux yyy, afin de zzz”

Le template a comme vertu première d’obliger à capturer les éléments importants. C’est bien le cas ici. Cette approche est surtout nécessaire aux débutants comme le relèvent Tom DeMarco et ses co-auteurs [DeMarco+08]. Mais elle vient aussi avec un travers important, où la forme prends le pas sur le fond : c’est le « template zombie ». Gojko Adzic nous en donne un bon exemple [Adzic13] :

“As a user, I want to register in order to log in”

Ah oui ! Etre obligé de me logger et devoir m’enregistrer pour ce faire, j’ai vraiment hâte… D’autres sont des tâches afférentes au travail de développement. Par exemple :

“En tant que développeur, je veux automatiser le processus de déploiement, afin de mettre à disposition l’application plus rapidement et plus souvent”

Bien sûr, cela doit certainement être fait, mais qu’est-ce que cela a à voir avec le produit ? Cela a surtout à voir avec le dogmatisme qui veut que tout ce qui figure dans le plan de sprint soit sous forme de User Story. Si votre motivation est d’être conforme au processus, félicitations : vous faites un projet non-agile en utilisant des techniques agiles !

Dans le même ordre d’idées, nous pourrions évoquer les « stories techniques », mais j’ai déjà écrit sur ce sujet il y a quelques temps.

On peut accuser une certaine paresse, ou une indolence à donner un véritable sens aux user stories. Mais il n’y a pas que cela.

More rules, more pain…

On dit qu’une story doit être petite, de manière à tenir dans une itération ou à être une « survivable experiment » [Adzic+14]. De manière à avoir du feedback plus rapidement aussi, bien sûr, l’un des moteurs de l’agilité. Mais plus de focus, c’est aussi moins de contexte et moins d’invitation à aller le chercher. C’est ainsi que l’on finit par se retrouver avec des User Stories de ce genre :

“En tant qu’analyste financier, je veux un export Excel, afin de manipuler les données comme je le souhaite”

Autant pour la qualité de l’analyse. Et ce n’est pas fini. Nos stories doivent aussi être INVEST. Une bonne idée de manière générale, mais que dois-je faire si certaines de mes stories ne sont effectivement pas indépendantes ? Est-ce si grave ?

Que se passe-t-il si ma User Story consiste à explorer des options ? Dois-je rejeter cette user story car justement, je ne serais pas capable de l’estimer … ou même de la tester ?

L’approche agile doit en principe nous aider à faire face à l’inconnu ou aux idées novatrices. Au lieu de cela, nous nous engageons gaillardement dans une voie qui cherche à éliminer tout risque, à prétexter que notre story n’est « pas prête », bref à aseptiser gentiment notre beau projet.

Alors, doit-on en finir avec ces User Stories ?

Dans son livre, Jeff Patton [Patton14] nous rappelle la véritable nature d’une spécification : créer de la compréhension partagée. Les «  3 C » (carte, conversation, confirmation) nous rappellent que la carte est l’élément le moins important, simplement un « jeton pour une conversation ». Le template de des User Stories a insidieusement déplacé notre attention sur les cartes, et plus précisément l’élément situé au milieu. Ce dernier représente la solution, ironiquement c’est celui qui devrait constituer la marge de négociation du « INVEST » !

Au template, je préfère les 3 questions que nous suggère Jeff Patton (encore lui) : Qui ? Pourquoi ? Quoi ? Et précisément dans cet ordre, avec le « quoi » à la fin !

Enfin, si les User Story remettent l’église au milieu du village en redonnant aux interactions l’importance qui leur est dû, elles ne doivent pas occulter la nécessité de développer des savoir-faire, d’appréhender d’autres techniques permettant la compréhension du contexte et des enjeux, ou supportant l’acquisition d’information. Certaines de ces techniques viennent de la communauté agile, d’autres viennent d’autres domaines comme l’UX ou le « requirements management » que nous avons déjà évoqué.

Bien comprises, les User Stories véhiculent réellement l’état d’esprit agile à ce que nous appelons spécifications (à défaut d’un autre nom plus adapté) : se focaliser sur ce qui compte réellement. Mais il s’agit juste d’un point de départ, à compléter et renforcer comme nous le faisons avec nos pratiques d’ingénierie.

Références

[Adzic13] : Writing “As a User” does not make it a user story ; Gojko Adzic ; http://gojko.net/2013/09/30/writing-as-a-user-does-not-make-it-a-user-story/

[Adzic+14] : Fifty Quick Ideas to Improve your User Stories – Gojko Adzic & David Evans – Leanpub 2014 – ASIN : B00OGT2U7M

[Cohn04] : User Stories Applied, for agile software development – Mike Cohn – Addison Wesley / Signature series 2004 – ISBN: 0-321-20568-5; EAN: 978-0-321-20568-1

[DeMarco+08] : Adrenaline Junkies and Template Zombies ; Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson & Suzanne Robertson

[Patton14] : User Story Mapping – Jeff Patton – O’Reilly 2014 – ISBN : 978 1 491 90490 9

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.

La liste des stories que nous réalisons durant le sprint doit être considéré comme notre contrat de fourniture : voilà ce que nous avons fait, voici où nous en sommes. L’un des mécanismes essentiels en contexte agile est le feedback. La simple déclaration énoncée ci-dessus est sans valeur si je suis dans l’incapacité de la constater et de donner du feedback dessus. Et pour donner ce feedback, il nous faut la connaissance de l’acteur concerné.

Régulièrement, hélas, je vois arriver ces fameuses « user stories techniques ». La justification que j’obtiens alors est : non mais là c’est technique, on a besoin de le faire ! J’ai alors droit à des merveilles du genre :

  • Stocker les donner fournisseur.

Ne souriez pas, c’est très fréquent. Mon exemple est d’ailleurs loin d’être le pire. Je vous épargne le classique « développer la couche de persistance »…

Un second effet de ces user stories techniques peut aussi se constater en planning meeting

La user story technique et le planning meeting

C’est donc conjointement à des user stories plus classiques que ces « stories techniques » se présentent en planning meeting.

image

Mais si les user stories classiques sont traitées assez efficacement, leurs homologues techniques necessitent environ 4 fois plus de temps (bien que je ne l’ai pas mesuré précisément).  Sont en cause :

  • Une difficulté à cadrer la solution, car la finalité n’est pas claire. Il manque le contexte.
  • Impuissance à déterminer le périmètre de la story. Quand celle-ci sera-t-elle terminée ? Quels sont les tests d’acceptation ?

Même avec 4 fois plus de temps, le découpage en tâches et l’estimation s’avèrent moins satisfaisants. Même si vous n’êtes pas fan du découpage en tâches et des estimations, il n’en reste pas moins que ceux-ci s’avèrent symptomatiques de la compréhension de l’item.

Mais voilà : c’est du travail technique, ce n’est pas fonctionnel. Est-ce vraiment le cas ?

Remettre la story technique dans son contexte

Basculer de la user story technique à leurs équivalents fonctionnels est moins difficile qu’il n’y parait de prime abord. Il s’agit surtout de se poser les bonnes questions :

  • Pourquoi a-t-on besoin de faire cela ? Que se passe-t-il, ou qu’est-ce qui se passe mal, si on ne fait pas cela ?
  • Dans quel contexte cela sera-t-il utilisé ?
  • D’un point de vue externe, comment saurais-je que le système possède cette propriété ou cette capacité supplémentaire ?
image

Cette liste n’est pas exhaustive, et vous pourrez facilement imaginer d’autres questions de la même eau. Le but est simple : remettre l’item technique dans un contexte fonctionnel. Dans le cas que nous avons énoncé plus haut (stocker les données fournisseur), à la question « qu’est-ce qui se passe mal si on ne fait pas cela », la réponse est : on ne peut pas communiquer ces informations si le système s’arrête entre leur acquisition et la transmission. Je pourrais vous le souffler à l’oreille, mais cette réponse nous permet assez facilement d’en déduire une user story fonctionnelle…

Et mon refactoring, alors ?

Eh bien c’est vrai, le refactoring, ce n’est pas fonctionnel (apparemment).  Doit-on le rejetter, l’ignorer ? Bref, le développeur doit-il se débrouiller et caser ça à l’heure du déjeuner ?

Bien sûr que non ! Mais ce n’est pas non plus une raison pour produire une « user story technique ».

N’oubliez pas que le mainteneur du système (donc le développeur) est aussi un utilisateur du système. Tout comme le sont les ops et les exploitants chargés de déployer et d’assurer le bon fonctionnement du système en production, soit dit en passant. En tant que mainteneur, vous pouvez demander à rendre un type d’évolution plus facile, de pouvoir prendre en charge de nouveaux périphériques ou de nouveaux algorithmes plus efficacement. Vous pouvez souhaiter que les évolutions ou les corrections soient localisées à un seul composant.

image

Bref, vous pouvez exprimer des besoins qui une fois remis dans le contexte d’un objectif, peuvent être discutés avec le Product Owner. Et vous pouvez même produire des critères d’acceptation ! Certes, ce ne seront pas des tests d’acceptation (on reste iso-fonctionnel, n’est-ce pas ?), mais on peut évaluer l’atteinte de ces critères ne serait-ce que qualitativement. N’oubliez-pas :

Tout ce qui a besoin d’être mesuré peut être mesuré d’une manière qui est de toute manière supérieure à pas de mesure du tout !

Maintenant, c’est trop gros !

Vous avez basculé dans l’usage ? Bien. Et maintenant vous vous rendez compte que votre story a pris de l’embonpoint, car elle intègre maintenant le contexte d’usage ! Je vous entend : c’est justement pour cela que vous aviez fait une story technique, pour que ce ne soit pas trop gros.

Il faut alors passer à la cure d’amaigrissement. Mais pas en réalisant un morceau du mécanisme après l’autre, en faisant des tranches plus fines de ce mécanisme.

image

Faire des tranches fines dépasse le cadre de ce post. Cela reste une compétence clef à acquerir pour le développement agile, en particulier pour le Product Owner. Je vous recommande à ce titre l’exercice du Carpaccio pour aiguiser votre savoir-faire.

A emporter

Peut-être un jour devrais-je faire face à une story technique que je ne saurais pas mettre dans un contexte d’utilisation. Pour l’instant tout va bien. Si vous faites face à cette difficulté, tentez l’exercice !

Reprenez les questions évoquées dans ce post. Au besoin, enrichissez-les des vôtres. Reprenez vos User Stories techniques et mettez-vous à 2 ou 3 autour d’une table et basculez votre story technique dans l’usage qui en est fait.

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

Le chapitre 3 aborde enfin une des originalités de l’approche des auteurs : le « business rules catalog ». Ce chapitre sert aussi d’introduction aux chapitres suivants en présentant les 4 niveaux de raffinement de ce business catalog.

Justement, c’est à la première étape de raffinement, la « façade iteration » que le chapitre 4 est dédié. Ce niveau de complétion correspond à des cas d’utilisation de niveau « résumé », avec une identification sommaire des règles métier. Les auteurs ont en fait un idée très précise de ce que signifie ce niveau de complétion. Trop même, car le processus s’avère franchement prescriptif !

Le chapitre 5 consacré au niveau de complétion suivant, le « filled iteration » suit le même schéma que le chapitre précédent, d(ailleurs il a pratiquement la même longueur. La vue très « processus » des auteurs et l’aspect répétitif des chapitres (pour ne pas parler des suivants) s’avère même un peu ennuyeuse.

On poursuit au chapitre 6 qui couvre la « focused iteration ». Un chapitre plus léger de 14 pages qui va plus droit à l’essentiel que les deux précédents. Dans la même veine, le chapitre 7 « finished iteration » est même encore plus court avec 8 pages !

Le chapitre 8 « managing requirements » est véritablement une vue gestion de projet. On y couvre des thèmes tels que la nature itérative et incrémentale du travail, la gestion des risques et les estimations.

Avec 4 pages, le chapitre 9 « working in team » est le plus court du livre. Sans rentrer dans le détail, il semble que les auteurs se soient sentis obligés de dire quelques mots sur le sujet, mais le résultat n’est ni utile ni convainquant.

Le dernier chapitre « classic mistakes » nous donne sur 15 pages des points de repère pour progresser. Hormis la présentation en tableau un peu pénible, le contenu est tout à fait valable. L’annexe A qui suit « beyond use cases » aurait pu être un chapitre du livre : on y évoque les articulations que peuvent avoir les cas d’utilisation par rapport aux autres travaux d’ingénierie. Le 5 pages de cette première annexe ne sont pas suffisantes pour couvrir décemment cet aspect. Il est mieux couvert dans « Applying Use Cases ».

Les chapitres du livre s’appuient sur un cas d’utilisation. La documentation de celle-ci dans son état finalisé est disponible dans l’annexe B. On en prend pour 140 pages : qui a envie de lire cela ?

Du coté des regrets, je ne suis guère convaincu par la séparation règles métier (qui se mappent sur les cas d’utilisation mais dont on ne peut déterminer les critères de vérification) et des spécifications non fonctionnelles (qui ressemblent à des exigences, mais ne sont pas mises en relation avec les cas d’utilisation). Je pense également que les annexes sont par trop volumineuses (elles représentent la moitié du livre), entre autre 2 exemples concrets de 60 pages chacun c’est trop. Un seul aurait suffit, et faire apparaître les différences entre 2 itérations dans une autre couleur aurait été une bonne idée.

En conclusion, le livre est raisonnablement bon, mais je continue à préférer celui de Geri Schneider. A noter qu’une seconde édition de cet ouvrage existe.

image

Référence complète : Use Cases : Requirements in Context – Daryl Kulak & Eamonn Guiney – Addison Wesley / A.C.M. Press 2000 – ISBN : 0-201-65767-8

Use Cases: Requirements In Context


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

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.

La 3ème partie, comprendre les besoins utilisateurs, c’est vraiment du sérieux : pas moins de 9 chapitres ici ! De petits chapitres toutefois, car ils totalisent moins de 80 pages. Identifier les besoins utilisateur, ce n’est pas si simple et le chapitre 7 est consacré à ce challenge, même si c’est seulement sur quelques pages. Quelle est la différence entre « feature » et « requirement » ? La plupart du temps, on s’arrête à une bonne zone de flou. Dean Leffingwell nous propose une articulation claire entre besoin / feature et requirement. Savoir questionner est un art essentiel dans l’ingénierie des exigences. Si le sujet n’est pas aussi puissamment investigué que dans « exploring requirements » de Weinberg et Gauge, au moins est-il évoqué de manière non anecdotique. Les workshops sont un complément naturel à cette activité et là encore une matière intéressante et exploitable nous est proposée. Le chapitre qui suit sur le storyboarding est là pour servir d’introduction à celui sur les Use Cases qui va suivre. Il est vrai qu’aujourd’hui, en ingénierie agile, on s’appuiera d’avantage sur le Story Mapping. Oui, bien sûr les cas d’utilisation sont évoqués, c’est forcé ! En fait, ils le sont plusieurs fois dans l’ouvrage, ici on s’arrêtera à la vision d’ensemble. On ne peut évoquer les cas d’utilisation sans parler de rôles, l’occasion pour l’auteur pour évoquer brièvement les cartes CRC, une brièveté certainement frustrante mais il est certainement possible de se reporter sur l’ouvrage de Bellin et Simone si le cœur vous en dit… On termine cette partie très riche par l’évocation des prototypes, à titre d’introduction.

La « team skill 3 », c’est définir le système, on a 3 chapitres pour cela. Comptez 3 chapitres et un peu moins de 30 pages. Oui, un moment, on parle documents et organisation de ceux-ci. Ce n’est pas le plus passionnant, mais au moins le sujet est-il abordé avec une certaine intelligence. Un chapitre est même consacré au document de Vision (avec un template, s’il vous plait), si cher à Philippe Kruchten. Retour à l’aspect humain pour clore le chapitre, avec le Product Champion. Ce qu’on y évoques recoupe pas mal ce qu’aujourd’hui on appelle un Product Owner.

Gérer le périmètre, c’est le sujet de « team skill 4 », qui couvre 4 chapitres sur un peu plus de 40 pages. On commence par le « pourquoi » de cette problématique de périmètre : en quoi est-ce important et dimensionnant. Pour aborder cette question du périmètre, Leffingwell s’adosse aux dimensions suivantes : des priorités qui se ventilent sur des releases, une gestion des risques et de l’effort, le tout illustré avec HOLIS. On trouve là les prémices de SAFe… L’engagement des utilisateurs dans cette gestion de périmètre est évoqué, mais guère convaincante. Personnellement j’ai bien aimé le chapitre 22, non pas parce qu’il évoque RUP (dans lequel l’approche de l’auteur s’inscrit), mais parce qu’il évoque aussi comment la gestion du périmètre a évolué entre le modèle en cascade, le modèle en spirale de Boehm et finalement le modèle itératif.

La partie consacrée au raffinement des spécifications est l’autre grosse partie du livre : 6 chapitres sur un peu plus de 80 pages. On commence par évoquer en profondeur la nature des exigences : comment on différencie le domaine du problème de celui de la solution, ou encore les différents types d’exigence. Le chapitre 23 est particulièrement affuté sur le sujet. S’en suit une introduction sur la spécification des cas d’utilisation. Bel exercice, même s’il ne saurait concurrencer les livres dédiés au sujet (je pense particulièrement à celui de Géri Schneider. Quand on parle de requirements à l’ancienne, on parle souvent de SRS et du fameux IEEE 830-1998. Le sujet n’est pas esquivé. Ambiguïtés et précision font parties des pratiques que doit développer tout analyste. Le sujet n’est qu’effleuré, même s’il l’est plutôt bien. Mais « exploring requirements » ou Tom Gilbs avec Planguage vont au moins un cran plus loin. La question des critères et de la mesure de qualité des spécifications est la mesure de la rigueur de l’analyste. Leffingwell aborde honorablement le sujet, même si je préfère la prose des Robertson dans « Mastering Requirements » à cet égard. On referme cette partie avec une revue des formalisations plus ou moins funkies des exigences : pseudo-code, diagrammes d’état-transition, etc.

La dernière partie « building the right system » reste imposante avec 6 chapitre et plus de 70 pages. Le chapitre consacré à la transition des exigences à la réalisation n’est pas mon préféré et apporte je pense assez peu. La traçabilité est un grand classique. S’il a cessé d’être un centre d’intérêt pour moi, le sujet existe, dommage qu’il soit abordé sous l’angle des outils, tout comme le sera le volet sur le change management. Par contre le test et la validation sont des points d’importance. Ils ne sont peut-être pas traités avec l’importance qu’ils devraient mais ils sont là. J’aurais par contre du mal à cautionner l’approche d’effort de validation par le ROI…

Le point fort de cet ouvrage est l’importance du tour d’horizon qu’il nous imprime sur l’activité d’ingénierie des exigences. C’est probablement l’ouvrage le plus complet à cet égard, et il faut bien avouer que l’on ne s’ennuie jamais. Nombre sinon tous les sujets peuvent nous amener sur des textes plus complets, et c’est très bien.

Au delà de ceci, on regrettera toutefois que le livre se cantonne souvent à la présentation des techniques de capture d’exigences, et que les véritables “guidelines” soient par trop absents, de même qu’un véritable processus de gestion d’exigences capable de cimenter l’ensemble des techniques présentées. Ceci fait que je préfère l’ouvrage de Suzanne et James Robertson, et que je considère celui-ci à la fois comme un complément et un texte embrassant plus large sur les différents volets de l’ingénierie des exigences.
Ce texte a connu deux éditions depuis celle-ci, dont la dernière markettée en agile.

image

Référence complète : Managing Software Requirements, a unified approach – Dean Leffingwell & Don Widrig – Addison Wesley / O.T. series 1999 – ISBN: 0-201-61593-2

Managing Software Requirements: A Unified Approach


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

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

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.