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

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

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

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

On monte d’un cran et on arrive au niveau « programme ». A l’instar du chapitre précédant, il est question de processus : des releases qui sont plus longues que les itérations (et sont en fait le vrai rythme de SAFe). J’avoue avoir du mal à gober que l’on parle de rythme élevé en évoquant des incréments de 2 ou 3 mois… Au passage on évoque quand même Vision, features et exigences non fonctionnelles. Les features, c’est plus gros que les US, c’est tout ce que l’on en apprend. Le chapitre 5 atteint les étages de la moquette feutrée et des fauteuils en velours. On y parle epics (donc un truc plus gros que les features) et thèmes d’investissement. Au niveau processus, ce n’est pas clair et d’ailleurs le chapitre est court.

La seconde partie va rentrer plus en profondeur dans les spécifications au niveau de l’équipe, du moins c’est la promesse. Cette partie pèse 150 pages et s’étale sur 7 chapitres. Beau bébé. Les User Stories ouvrent le bal au chapitre 6. C’est un bon chapitre. Il couvre bien les aspects essentiels de la pratique, en commençant par les « 3 Cs » et en invoquant l’INVEST sans oublier l’importance du split de stories. C’est typiquement cette qualité que j’attends de la prose de Leffingwell.

Pour compléter cela, une douzaine de pages suivent sur les utilisateurs au sens large avec les approches Stakeholder Persona et UX. Boulot bien fait ici aussi. La prose est instructive et agréable à lire. Le chapitre 8 va me valoir mon premier arrêt cardiaque. Déjà la présence d’un chapitre sur les estimations au sein d’un texte consacré aux spécifications me dérange. Mais si l’estimation relative est bien présentée, en se claquant sur l’approche de Mike Cohn dans son remarquable « Agile Estmating and Planning », l’auteur va proposer sa méthode géniale en calibrant 1 point = 1 jour homme pour simplifier et standardiser les estimations entre équipes … tout en prétendant qu’il s’agit d’estimations relatives car il s’agit de points et non de jours-hommes. Relisez cela si vous n’avez pas vu l’entourloupe.

Il est question d’itérations au chapitre 9. Donc non, on ne va pas y parler spécifications. Au-delà du propos sur la variabilité des queues de travail qui est une simple reprise du propos de Don Reinertsen (et mieux décrit dans son ouvrage), la totalité du contenu tourne autour d’une seule idée : la chose la plus importante pour l’équipe est qu’elle tienne ses engagements. Tout autre chose est complètement non-professionnel. L’équipe est bel et bien une unité d’exécution et rien d’autre. Mais agile (?). Nous quittons le propos déprimant du chapitre 9 pour aborder les tests d’acceptation au chapitre 10. Ce n’est pas transcendant mais au moins l’auteur ne dit pas bêtises. Il évoque même du bout des lèvres les tests unitaires et de composants. Au moins le lecteur qui n’aurait pas été intéressé par un texte sur le sujet aurait-il un verni adéquat.

Le rôle du Product Owner, abordé au chapitre 11, sera l’occasion de mon second arrêt cardiaque. En effet, Leffingwell milite pour une dualité PO / PM avec le PO dans la couche équipe et le PM dans la couche programme. Le PM est en charge de la proposition de valeur tandis que le PO « owns the implementation ». Voilà donc le PO dépossédé de son rôle par rapport au produit, et dépossédant à son tour l’équipe de sa responsabilité par rapport à l’implémentation. Il est devenu chef de projet. Mais il est agile car il se nomme PO. Fuyons ces affres avec le rafraichissant chapitre 12 sur les techniques de recueil des besoins. Ce sont des techniques à l’ancienne, mais elles restent intéressantes et sont moins déprimantes que le chapitre 11.

La 3ème partie évoque la gestion des spécifications au niveau programme. Ce sont 7 chapitres sur 130 pages qui sont à l’honneur. Le chapitre 13 couvre vision, features et roadmap. Il s’agit de réchauffé de ce que nous avons pu découvrir avec Unified Process il y a plus de 20 ans. Le tout est mâtiné de coût du délai introduis par Don Reinertsen. La roadmap elle, n’est jamais qu’un plan de release, là aussi à l’ancienne.

Le rôle du Product manager au chapitre 14 est intéressant (mention spéciale à la citation de début de chapitre). Son travail est en fait celui du PO (normalement), sauf qu’il ne parle pas à l’équipe et que son horizon de travail est la release (2 mois). Le release train abordé au chapitre 15 est plus un chapitre processus que spécification. C’est la véritable itération de SAFe (les itérations d’équipe, c’est pour rire). Le chapitre expose clairement le concept : contrôler et faire marcher au pas un ensemble d’équipes.

Le release planning (qui deviendra le PI planning) est le sujet du chapitre 16. Clairement développé et exposé, il rentre dans le détail de cette activité, jusqu’à l’agenda du workshop sur 2 jours. C’est carré. Les exigences non-fonctionnelles sont au menu d’un chapitre 17 assez court. C’est dommage. Je sais l’auteur capable de traiter le sujet d’excellente manière. Présentement, c’est hélas superficiel.

Les chapitres 18 et 19 sont le toolkit d’analyse du niveau programme. Ils font écho au chapitre 12, avec un chapitre 19 spécifiquement dédié aux cas d’utilisation. Là encore je retrouve la qualité de la prose du « Managing the Requirements Process ». Ce n’est pas souvent qu’un ouvrage parle de la manière dont les techniques traditionnelles peuvent aider un processus agile. J’aurais aimé que tout le livre soit de la même eau.

La dernière partie traite des spécifications au niveau de la gestion de portefeuille. Ce sont 5 chapitres sur 90 pages. Elle s’ouvre sur un chapitre 20 consacré à l’architecture agile. L’architecture agile est-elle émergente ? Oui quand on parle de petits trucs. Pour les gros, il faut faire des epics d’architecture, un socle, le tout géré par un architecte système. Curieusement cela va à l’encontre des 8 principes évoqués dans le même chapitre auxquels j’adhère facilement.

Le chapitre 21 m’a occasionné mon 3ème arrêt cardiaque. Il s’agit, pour dire les choses clairement, d’un processus d’architecture que l’auteur présente sous forme de Kanban. En fait c’est du processus en cascade très compliqué avec modèles, des documents et des validations, tout ça sous la coupe de l’architecte système. J’allais oublier l’intervention de l’équipe de développement en fin de course pour implémenter le machin. Mais bon c’est agile, c’est marqué dessus. Au chapitre 22 on bascule sur la gestion de portefeuille, où l’on manipule des epics (des choses plus grosses que des features) et des thèmes d’investissement. L’auteur nous met en garde : le PMO, c’est mal. Mais à l’échelle d’une entreprise c’est inévitable. Donc, le PMO finalement c’est bien si on dit qu’il est agile…

Je passe rapidement sur le chapitre 23 qui évoque le processus de gestion des epics. C’est le même que celui que j’ai évoqué au chapitre 21. Ce qui me permet de faire l’économie d’une crise cardiaque.

Le livre est une déception à plusieurs titres. Tout d’abord il parle très peu de spécification et beaucoup de processus à l’échelle. Cela aurait pu être intéressant si les idées évoquées n’étaient de tels retours en arrière. Je les ai largement évoqués ci-dessus, je n’y reviendrais pas. Ce qui frappe surtout c’est la schizophrénie entre les principes et le mindset déclarés (que je partage) et les mises en œuvre proposées, largement qualifiées d’agile bien sûr (quand on ressent le besoin de le dire autant…) mais qui contredisent ces intentions. Une lecture où je n’ai pris aucun plaisir.

Référence complète : Agile Software Requirements – Dean Leffingwell – Addison Wesley 2011 – ISBN : 978 0 321 63584 6