User Stories … What else ?

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

Publicités

Software Requirements, 3rd Edition by Karl Wiegers & Joy Beatty | Seilevel

Il devrait sortir cet été ! La prose de Karl Wiegers reste un de mes grands classiques du recueil de besoins, que l’on parle agile ou pas !

Ici, en l’occurrence, on nous promet un peu de coloration agile, comme James & Suzanne Robertson ont su le faire.

Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty | Seilevel

Note de lecture : Practical Project Initiation, a handbook with tools, par Karl E. Wiegers

Note : 6 ; Moins bien que d’habitude

Karl Wiegers nous a habitué à des ouvrages de qualité, aussi bien par la forme que sur le fond. Cet ouvrage de moins de 200 pages s’avérait donc prometteur car j’apprécie les auteurs qui savent s’exprimer avec concision. Finalement l’ouvrage manque sensiblement de corps. S’il passe bien en revue les différents aspects de la gestion de projet, il nous laisse largement sur notre faim en ce qui concerne le contenu. La plupart des 15 chapitres se concluent par des conseils de mises en pratiques et des templates, mais ni les uns ni les autres ne m’ont paru extrêmement pratiques, du moins pas assez pour que j’ai envie de m’y référer. Le livre se découpe en 5 parties.

La première partie est consacrée aux fondamentaux de la gestion de projets. Les 3 chapitres qui le composent couvrent 35 pages et peuvent être vus comme un survol du reste de l’ouvrage, c’est en tout cas l’objectif du chapitre 1, le « primer ». Le chapitre 2 se focalise sur les principales bonnes pratiques / mauvaises pratiques de la gestion de projet. Très pertinent et une bonne référence quand on veut prendre un peu de hauteur, tandis que le 3ème chapitre nous aide à considérer les priorités.

La seconde partie s’intitule pompeusement « preparing for success » et s’étale sur 65 pages soit 5 chapitres. Cette partie se devait d’être la plus solide mais elle n’est pas ma préférée. Le chapitre 4 s’intéresse aux critères de succès et aux objectifs d’un projet, un sujet important qui aurait pu être mieux traité. Le chapitre 5 considère la mesure de l’avancement (bonne idée). Le chapitre 6 évoque le « risk management », sujet important de l’aveu même de l’auteur mais bien légèrement traité. Le chapitre 7 suggère le développement d’une charte que je trouve bien peu convaincante.

La troisième partie s’intitule « vivre avec la réalité » et n’est longue que de 27 pages représentant 3 petits chapitres. Le chapitre 8 traite de la négociation des objectifs et est particulièrement intéressant. Au chapitre 9 l’auteur nous propose de mettre en place des « buffers » pour contrer les imprévus, ce que je désapprouve, mais c’est une question de point de vue. Le chapitre 11 est une nouvelle source de frustration car il aborde la dualité estimation / réalisation, mais de manière bien plus superficielle que Steve McConnell dans son art de l’estimation (auquel Karl Wiegers se réfère beaucoup, justement).

La quatrième partie évoque la mise en place de métriques. Le « Software metrics primer » du chapitre 12 est encore une fois bien léger ! Le chapitre 13 sur les pièges à éviter est bien plus instructif.

La dernière partie traite du retour d’expérience. Tout d’abord via le chapitre 14 qui évoque les « best practices »… et renvoie vers le « Rapid Application Development » de Steve McConnell ! Le chapitre 15 enfin fait état des rétrospectives, mais ne sert guère que d’introduction au remarquable ouvrage de Norman Kerth !

Mon propos montre pas mal de frustration à la lecture de cet ouvrage ! C’est le lot des bons auteurs que l’on en attende toujours les meilleurs. Cet ouvrage n’est certes pas l’œuvre la plus marquante de Karl Wiegers, mais étant assez condensé, il pourra servir d’ouvrage introductif au chef de projet junior, car il renvoie utilement vers des textes plus complets.

wieger-pract-proj-initiation

Référence complète : Practical Project Initiation, a handbook with tools – Karl E. Wiegers – Microsoft Press 2007 – EAN : 978 0 7356 2521 1

Practical Project Initiation: A Handbook with Tools


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

Note de lecture : More about Requirements, par Karl E. Wiegers

Note : 7 ; Karl Wiegers n’a pas tout dit !

Comme son nom l’indique, ce petit opuscule (185 pages) est un complément au classique « Software Requirements » du même auteur, et plus précisément à la seconde édition de cet ouvrage. Plus que d’être un livre par lui-même, ce texte fait un peu l’effet d’être un complément d’information. Aussi je déconseille fortement de plonger dans cette lecture si vous n’avez pris d’abord le temps d’étudier le premier ouvrage. Si vous l’avez fait et l’avez apprécié (ce qui est mon cas), cette lecture poursuit le plaisir.

Le format du livre est réellement inhabituel, il rappelle celui, un peu déconcertant, de Kent Beck : l’ouvrage compte 23 chapitres répartis en 7 parties. Pour un livre de 185 pages. Faites le calcul, la moyenne de chacun d’entre-eux se situe aux alentours de 8 pages ! En fait, je trouve cela fort agréable, car on a le sentiment que chaque chapitre a un objectif « tactique » et que celui-ci doit être atteint le plus efficacement possible. Et cela rythme bien la lecture. Par contre, on a aussi l’impression que chaque chapitre est traité assez superficiellement. En fait les renvois vers le livre principal sont assez nombreux, on est parfois aux limites de la FAQ.

La première partie est consacrée aux concepts : ce qui est vrai ou faux concernant la gestion des exigences et aussi la « big picture » des types d’exigences vue par Karl Wiegers, que j’aime particulièrement.

La seconde partie se focalise sur la partie management des exigences : comment peser le retour sur investissement ? Comment en estimer l’effort ? Comment planifier ce travail et le répartir tout au long du projet ?

L’interaction avec les utilisateurs est abordée dans la troisième partie. Ici c’est l’élément humain qui est décortiqué, et l’on s’intéresse à la meilleure façon de collaborer avec un utilisateur.

La quatrième partie est dédiée aux cas d’utilisation : que sont-ils, quels sont les concepts importants et quand est-il utile de compléter ce formalisme par un autre ou tout simplement de l’abandonner au profit d’un autre !

La rédaction des exigences est un problème crucial, car elle détermine la qualité et l’utilisabilité effective du produit final. La cinquième partie est dédiée à ce sujet.

Karl Wiegers reste un homme de processus, et la sixième partie recadre la gestion des exigences dans un processus projet : définition de la portée du projet, gestion du changement, etc..

Enfin la dernière partie aborde le volet « gestion » : de quels indicateurs peut-on avoir besoin ? Comment gérer les exigences à travers plusieurs releases d’un projet ou comment aborder le choix d’un outil de gestion des exigences.

Cet ouvrage n’est certainement pas un ouvrage de référence, comme peut l’être le « Sotware Requirements, 2nd edition », mais c’est une bonne lecture complémentaire. Le propos de Karl Wiegers fait souvent mouche et apporte grandement au sujet. Je vous engage donc à poursuivre la lecture du premier ouvrage cité par celui-ci !

more-about-requirements

Référence complète : More about Requirements – Karl E. Wiegers – Microsoft press 2006 – ISBN: 0-7356-2267- 1

More About Software Requirements: Thorny Issues and Practical Advice: Thorny Issues and Practical Advice

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

Note de lecture : Software Requirements, 2nd edition, par Karl E. Wiegers

Note : 9 ; Encore meilleurs avec le temps … et toujours une référence sur la gestion des exigences!

Je l’avais dit ailleurs, mais j’estime qu’un ouvrage dans sa seconde édition qui ne s’améliore pas mérite une note en baisse ! Vous pouvez donc déjà conclure qu’en gardant la même note que j’avais attribué à la première édition, cette nouvelle mouture a amélioré le texte original. Pas seulement amélioré d’ailleurs, mais aussi amplifié car l’ouvrage est augmenté de 100 pages. Après presque 10 ans de perspective sur les écrits concernant la gestion des exigences, Karl Wieger et les Robertson restent mes ouvrages de référence sur le sujet. Ce n’est pas rien et cette mise à jour (qui est en fait plus que cela) remet le livre en selle pour autant qu’il fût jamais détrôné.

La structure du livre est passée de 3 parties à 4 et le découpage a également évolué. Je ne vais pas rentrer dans le détail des chapitres, mais tenter de parler de chacune des parties.

La première partie est intitulée « Software requirements : What and Why ». A priori cette partie est dévolue aux nouveaux venus dans la partie. Erreur, cette partie mérite d’être également étudiée par les analystes expérimentés tout autant ! A la place des banalités convenues, l’auteur explique clairement et nettement les différents types de besoins et les différentes perspectives à considérer sur leur expression. On y aborde avec honnêteté les attentes des utilisateurs et la façon concrète et pragmatique dont on peut les aborder dans le cadre d’un projet. Les « bonnes pratiques » nous renvoient aux droits et aux devoirs de l’analyste et de l’utilisateur durant l’expression des besoins. Sans jamais réellement évoquer l’approche agile, l’état d’esprit y est et je conseillerais sans hésitation la lecture de cette première partie à tout agiliste !

La seconde partie porte tout simplement comme titre « Software requirements developpement ». Avec ses 220 pages et ses 12 chapitres, c’est la plus longue du livre ! Il s’agit d’une approche « par facette » plus que par activité et qui couvre remarquablement toute l’activité de recueil du besoin : établissement de la vision, dialogue avec les utilisateurs, règles métiers, scénarios d’usage, documentation, validation, qualification, etc… Chaque chapitre est clairement focalisé sur un point de vue, clair et riche sans se perdre dans des considérations stériles.

La troisième partie est consacrée au « requirements managements », où comment gérer l’évolution des exigences dans le temps. Cela couvre l’outillage, la gestion des changements et de la traçabilité. Si cela ne couvre que 65 pages, ne croyez pas pour autant que le sujet est traité avec légèreté car l’essentiel est dit, même si il peut être complété par ailleurs.

La dernière partie « implementing requirements engineering » est nouvelle et certainement moins passionnante (sans être mauvaise). Mais on est plus loin des processus agiles.

La première édition était bonne, la seconde l’est plus encore. L’ouvrage couvre avec succès toutes les facettes du recueil des besoins et peut figurer comme seul ouvrage sur la gestion des exigences dans votre bibliothèque si vous ne souhaitez qu’un livre.

wieger-soft-reqt

Référence complète : Software Requirements, 2nd edition – Karl E. Wiegers – Microsoft press 2003 – ISBN: 0-7356-1879-8; EAN: 978 0 7356 1879 4

Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle

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

Note de lecture : Peer Reviews in Software, a practical guide, par Karl E. Wiegers

Note : 7 ; Une approche qualité “à la CMM”, toutefois claire et efficace. Mais le livre n’atteint pas la qualité des autres livres de l’auteur!

Que cela soit bien clair: Karl Wiegers est un auteur remarquable. C’est pour cela que je dirai que ce n’est pas le livre le plus remarquable de cet auteur, mais cet ouvrage assez court donne toutefois une bonne idée d’une approche “processus ” (mais alors vraiment processus !) De la revue de pairs. Le propos est un peu moins concret que ce que l’auteur a l’habitude de nous livrer, mais il faut bien dire qu’écrire un livre sur la revue de pairs est probablement un exercice difficile.

Du coté positif, l’auteur a une connaissance et une vision exceptionnellement large du sujet, et il est capable de synthétiser très efficacement cette vision. Coté négatif, je regrette que l’ouvrage se focalise exclusivement sur une approche “processus lourd”, à la CMM, ce qui ne conviens guère à toute les organisations, et surtout aux plus petites qui ont quand même des besoins de revue. J’ai aussi été un peu gêné tout le long de l’ouvrage par l’absence de cas d’étude concret. Cela dit, le livre est assez bien complété par des artéfacts disponibles sur le site Web.

Ce livre pourra vous convenir, si vous savez ce que vous allez lire, c’est à dire un livre très orienté processus. Vous apprécierez alors la capacité de l’auteur à s’exprimer efficacement en moins de 200 pages.

peer-reviews-software

Référence complète : Peer Reviews in Software, a practical guide – Karl E. Wiegers – Addison Wesley / I.T. series 2002 – ISBN: 0-201-73485-0

Peer Reviews in Software: A Practical Guide


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