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

Note de lecture : Essential Scrum, par Kenneth S. Rubin

Note : 8 ; La référence sur Scrum, à la hauteur des ouvrages de Mike Cohn

Le nom de l’auteur ne m’évoquait rien jusqu’à présent. Mais Kenneth Rubin n’est pas seulement un vieux routier de l’informatique et de l’agilité, il fut aussi le premier chairman de la Scrum Alliance ! La motivation de l’auteur était, pour cet ouvrage, de réaliser un texte de référence sur Scrum, que l’on puisse prendre avec soi et qui suffise lorsque l’on se pose une question sur la mise en œuvre de Scrum. Je vais certainement casser le suspens, mais c’est pour moi mission accomplie. En prenant un peu de recul, on peut constater que les points abordés tombent dans 3 catégories.

  • Les éléments et pratiques qui font partie du cœur de Scrum. C’est ce que l’on va trouver dans le Scrum Guide, par exemple, ou dans les 3 ouvrages de Ken Schwaber.
  • Les pratiques généralement admises dans la mise en œuvre de Scrum, mais qui ne font pas partie du framework officiel. Ce sont par exemples les pratiques empruntées à l’Extreme Programming. A ce titre, c’est ce que nous pourrons rencontrer dans l’excellent « Scrum from the Trenches » de Kniberg ou le livre en Français sur Scrum de Claude Aubry.
  • Les pratiques avancées qui peuvent compléter Scrum. Nous pouvons penser au Management 3.0 de Jurgen Appelo ou au Lean Startup…

Ce livre vise à couvrir complètement les deux premiers aspects et une bonne partie du 3ème. C’est un vrai texte pratique qui ne se limite pas à ce que l’on doit faire, mais surtout développe le « comment ». On s’appuie ici sur une prose de bonne qualité (je l’ai comparé à Mike Cohn tout à l’heure), mais aussi sur une abondante illustration. Le tout pèse benoitement ses 400 pages, c’est le prix à payer ! Au niveau du contenu, il faut compter avec 23 chapitres regroupés en 4 parties principales.

Le premier chapitre est une courte introduction sur la raison d’être de Scrum. Un peu ce que l’on retrouve dans « Software in 30 days », mais mieux écrit. C’est expédié en 10 pages.

La première partie regroupe 7 chapitres sur un peu plus de 150 pages et est dédiée aux « core concepts ». On commence très classiquement par un chapitre 2 justement nommé « the Scrum Framework » de 15 pages. Juste Scrum, rien que Scrum. C’est ce que couvre le Scrum Guide, rien à ajouter.

Ce sont aux principes agiles qu’est consacré le chapitre suivant. Par principes on entend : gestion du changement, taille des lots (WIP size) ou coût du délais, le tout comparé aux approches « plan driven ». Un chapitre un peu dense, dont les 30 pages ciblent plutôt le middle management et les décideurs. On reste encore beaucoup dans les principes avec les 17 pages du chapitre 4 consacré aux sprints : à quoi sert le timeboxing, les conséquence d’un changement en cours de sprint, etc. On retrouve un propos plus en phase avec les préoccupations du praticien. « requirements et user stories » qui est le titre du chapitre 5, c’est un bon condensé de ce que l’on trouvera dans l’ouvrage de Mike Cohn sur le sujet. C’est une sorte de MVP des stories pour partir du bon pied. Le chapitre 6 consacré au backlog continue sur cette lancée mais couvre également les cas particuliers de backlogs multi-équipe et autres spécificités. Les 20 pages destinées aux estimations sont aussi un condensé d’Agile Estimating and Planning de Cohn. Mais c’est très bon et suffisant pour démarrer. Le sujet des dettes techniques tient visiblement à cœur pour l’auteur, les 23 pages qui sont dédiées à ce point sont un peu en décalage avec les chapitres précédent. Le sujet est traité sous l’angle économique, qui distribue la nature de cette dette en 4 catégories.

La seconde partie est consacrée aux rôles de scrum, enfin à une couverture un peu plus large que les rôles officiels. On leur dédie 5 chapitres sur un peu moins de 100 pages. Contrairement à moi, l’auteur s’accroche à la séparation des rôles « by the book », avec un chapitre 9 consacré au Product Owner, complet et bien fait, où il est toutefois admis que l’ensemble des compétences demandées ne se retrouvent pas forcément en un seul homme… Le chapitre 10 est logiquement dédié au Scrum Master. Là aussi je diffère de l’auteur qui préfère le SM « professionnel » quite à se qu’il s’occupe de plusieurs équipes. Les 8 pages dédiées au sujet paraissent étrangement peu. L’équipe est traitée au chapitre 11. Il est beaucoup question de polyvalence au long de ces 16 pages, mais aussi de « profil en T » que je vois rarement évoqué. Le modèle a ses limites, à mon avis. Une dizaine de pages sont consacrées à la question du « team structure ». Sceptique sur l’intérêt du sujet de prime abord, j’avoue que l’auteur fait du bon boulot à opposer le « feature team » au « component team » et à évoquer le travail en équipes multiples. Le chapitre 13 qui clot cette partie est dédié au management. On sort un peu de Scrum pour aborder des questions qui sont reprises du Management 3.0 de Jurgen Appelo.

La troisième partie sort en grande partie du « Scrum by the book ». Elle est intitulée « planning » et couvre 5 chapitres sur 90 pages. Le chapitre 14 sert d’introduction et aborde sur 8 pages les principes économiques sous-tendant la manière d’aborder la planification agile. Le chapitre 15 sert de guide au reste de cette 3ème partie en reprenant le « multi-level planing » que Rallye Software évoquait déjà en 2006. Le chapitre 16 embraye donc sur la planification de portefeuille qui sort du cadre projet. Disons que le sujet n’est pas mal abordé sur une vingtaine de pages, bien qu’il lui manque un volet réellement pratique. Le chapitre 17 « envisonning » semble être un sujet qui passionne l’auteur. Il lui dédie même un début d’étude de cas, ce dont on n’a pas eu le droit avant. Et on y évoque aussi le release plan du projet et le « validated learning » du Lean Startup ! Ce sont 25 pages qui sont consacrés au release planning traité au chapitre 18. Je ne suis pas fan du sujet, mais il est fort bien traité en y intégrant plusieurs stratégies de contraintes.

J’aurais préféré voir cette quatrième partie « Sprinting » plus tôt dans l’ouvrage, car c’est quand même le cœur de Scrum ! 11 pages semblent suffire pour couvrir le Sprint planning au chapitre 19. C’est très concret, à la limite de la recette de cuisine, donc réellement exploitable. Le chapitre 20 « sprint execution » n’est pas facile à aborder car il doit traiter de ce qui se passe entre le début et la fin de Sprint. Bien sûr on y évoque le Daily Stand-up, mais aussi la communication dans l’équipe et la manière de se distribuer les tâches. Bon boulot, finalement. Très logiquement le chapitre 21 aborde la démo, pardon le « sprint review » ! Pas trop de blabla sur cette dizaine de pages et l’auteur y aborde aussi des points épineux comme le « rien à montrer » ou la démo de réalisations sous le capot ! Enfin c’est à la rétrospective que se consacre le chapitre 22. Le contenu reprend plus ou moins la trame d’Esther Derby, mais l’auteur consacre un peu plus de développement à la timeline. Pourquoi pas ? C’est mieux que de paraphraser un ouvrage déjà bien connu. Aller plus loin, c’est le thème du chapitre de clôture. C’est un peu mon « Scrum Ri ». Une bonne façon de terminer l’ouvrage.

De mon point de vue, l’objectif est atteint. Ce livre vise le même créneau que l’ouvrage de Claude Aubry : être un livre de référence sur Scrum. Je pense qu’il est un cran au dessus de son équivalent Français déjà fort honorable. Son seul réel défaut est peut-être que sa cible naturelle est constituée d’un public peu enclin à avaler un ouvrage de 400 pages.

image

Référence complète : Essential Scrum, A practical guide to the most popular agile process – Kenneth S. Rubin – Addison Wesley / Signature series 2013 – ISBN : 978 0 13 704329 3

Essential Scrum: A Practical Guide to the Most Popular Agile Process

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

Note de lecture : Agile Estimating and Planning, par Mike Cohn

Note: 8; La mine d’information de la gestion de projets agile

Déjà auteur d’un ouvrage sur les “User Stories” (et futur auteur d’un autre livre sur la transition vers Scrum) Mike Cohn nous livre ici un texte complet sur les estimations et la planification agile, et c’est vraiment une bonne surprise. A la différence de certains livres qui entretiennent un flou artistique, l’auteur a vraiment fait l’effort de couvrir le terrain du sujet, en découpant le texte en 7 parties, qui totalisent 23 Chapitres (soit 312 pages) !

La première partie “problems and goals” traite des défaillances de la planification classique, pourquoi elle échoue et en quoi l’approche agile est radicalement différente. Les 3 chapitres constituant cette première partie se résument à 32 pages. On débute par la question de l’estimation par le biais du cône d’incertitude. De là, le chapitre 2 aborde les causes d’échec des estimations classiques : multitâche, ignorance des dépendances et estimations se transformant en engagements ! On conclut logiquement cette première partie par un chapitre 3 mettant en relief les vertus de l’approche agile : planification à plusieurs niveaux, boucle de feedback, planification par la valeur métier.

La seconde partie traite de l’estimation. Forte de 5 chapitres totalisant 44 pages, l’auteur a réellement privilégié ici les petits chapitres, condensés et efficaces ! Les deux premiers chapitres expliquent l’approche de l’estimation en “story points” puis en “jours idéaux”, avant d’aborder les techniques collaboratives (planning poker, analogies, wide band delphy, etc.). Plus original, le chapitre 7 évoque la réestimation ! Cette partie se conclut logiquement par une discussion du choix entre story points et jours idéaux.

Prioriser par la valeur est le thème de la troisième partie (50 pages, 4 chapitres). C’est à mon avis la partie la plus ludique de l’ouvrage, car on y découvre l’évaluation par le modèle des cash flows, l’utilisation d’abaques « risque vs valeur » ou encore l’utilisation du modèle de Kano. L’utilisation de ces techniques révèlent parfois certaines user stories comme ambivalentes. Le dernier chapitre de cette partie traite du découpage de ces stories.

Avec la quatrième partie, on aborder le second grand thème du livre : la planification. Il est logique que cette partie soit la plus longue, avec 80 pages découpées en 6 chapitres. Les deux premiers chapitres couvrent les deux niveaux principaux de la planification agile : le release plan, puis la planification d’itération. Les autres aspects couverts dans cette partie sont l’évaluation de la vélocité et les problématiques de synchronisation entre équipes (buffering, planification avec plusieurs équipes). Cette quatrième partie est assez dense, croyez-moi !

C’est au suivi de la réalisation qu’est consacré la cinquième partie. Ce n’est pas un sujet sur lequel l’approche agile met un accent particulier, aussi est-il logique qu’il ne couvre que 34 pages (3 chapitres). Bien entendu, on y parle burndown charts, suivi de l’accomplissement des tâches et communication avec le management.

Les sixième et septièmes parties ne comportent qu’un seul chapitre chacune. Si la sixième partie forme une sorte de conclusion (ou devrais-je dire d’ode) à la planification agile en en listant les qualités, La dernière partie reprend elle l’ensemble des thèmes via une étude de cas. Ce chapitre (assez long) est intéressant car il recolle les morceaux directement en situation, l’ensemble étant narré via des dialogues entre membres d’une équipe de développement, le management et un coach.

On pourrait en douter de prime abord, mais l’estimation et la planification agile couvrent un grand nombre de sujets et de techniques. Le tour de force de l’auteur est de nous présenter une boite à outil très complète de manière concise, efficace et agréable à lire.

C’est tout simplement un incontournable d’une bibliothèque « agile » digne de ce nom!

agile-estimating-planning

Référence complète : Agile Estimating and Planning – Mike Cohn – Prentice Hall 2006 – ISBN: 0-13-147941-5; EAN: 978-0-131- 47941-8

Agile Estimating and Planning


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

Note de lecture : Succeeding with Agile, Software development using Scrum, par Mike Cohn

Note : 8 ; Réussir la transition vers l’agilité

En quelques années et avec 2 livres remarquablement écrits, Mike Cohn s’est imposé comme l’in des leaders du mouvement agile. Voilà donc un livre qui pouvait difficilement passer inaperçu au sein de la communauté !

Globalement, le livre est assez pesant, dans tous les sens du terme : avec ses 450 pages, d’abord, ensuite parce qu’il est composé presqu’exclusivement de texte. Ce n’est pas un texte qui s’avale en un week-end ! Heureusement, Mike Cohn sait écrire et il fait mieux qu’aligner des platitudes, mais je pense quand même que la présente prose n’est pas aussi efficace que celle de l’excellent « agile estimating and planning ». C’est aussi que j’attends beaucoup d’un auteur capable de délivrer un livre d’excellente qualité.

L’une des premières impression qui m’est venue à l’esprit, est le parallèle entre ce livre et celui de Craig Larman « agile & itérative development ». Le livre est divisé en 5 parties, il nous faut bien les passer en revue, car le contenu s’avère au final plutôt riche !

La première partie « getting started » compte 5 chapitres qui totalisent 92 pages. Ce n’est hélas pas la meilleure partie de l’ouvrage. Un large focus est mis sur les communautés de transition vers Scrum, sujet qui m’est apparu abstrait et hélas peu convaincant. Cette première partie se termine sur le choix du projet pilote. Certainement cela s’adresse à ceux qui ont ce choix, donc un public assez restreint pour autant qu’il existe. Heureusement, les parties suivantes reprennent du poil de la bête.

La seconde partie adresse les individus. Longue de 80 pages, elle compte 4 chapitres. Mes deux chapitres préférés sont le chapitre 6 sur le traitement des résistances au changement : agrémenté d’exemples, j’ai trouvé le tour d’horizon complet et pertinent. La façon d’adresser les différents types de résistances est aussi fort judicieuse. J’ai également apprécié le chapitre sur le changement des rôles, il va plus loin que le simple « oubliez ce qui existait avant ». Le rôle du « functionnal manager, par exemple, simplement méprisé par la littérature agile en général, est bien pris en compte.

Avec près de 150 pages et 7 chapitres, la 3ème partie consacrée à l’équipe est la plus longue du livre. Elle traite à la fois la structure de l’équipe et les pratiques de Scrum. Il s’agit justement du chapitre le plus « Scrum » du livre, et l’auteur y livre sont point de vue subjectif sur nombre de pratiques Scrum. Bien que n’étant pas en accords avec tous les points de vue de l’auteur, je n’en considère pas moins cette partie extrêmement riche : elle nous guide littéralement vers la mise en place de Scrum. A noter le chapitre sur la planification qui est un résumé du livre précédent de l’auteur … et une invitation à lire celui-ci !

La quatrième partie est consacrée à l’application de Scrum aux organisations. J’avoue m’être moins intéressé à cette partie qui ne fait pas partie de mes préoccupations. Les 100 pages découpés en 4 chapitres de cette partie évoquent surtout Scrum appliqué en équipes multiples, la coexistence avec d’autres approches et toutes ces sortes de choses..

La cinquième partie a forme de conclusion, avec ces 2 chapitres et ses 20 pages. L’auteur nous signifie simplement qu’on n’est pas au bout du chemin. On ne l’est jamais. On y voit quels outils utiliser pour s’évaluer et quels horizons il reste à explorer.

Comme je l’ai dit au début, le livre est assez lourd, parfois fastidieux à lire. Néanmoins il n’en reste pas moins un ouvrage majeure de cette littérature Scrum encore naissante. Et je pense qu’il le restera. Comment, vous ne l’avez pas encore commandé ?

succeeding-with-agile-Cohn

Référence complète : Succeeding with Agile, Software development using Scrum – Mike Cohn – Addison Wesley 2010 – ISBN : 0-321-57936-4 ; ISBN13 : 978-0-321-57936-2

Succeeding with Agile: Software Development Using Scrum


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