"La page doit s'afficher en moins de 2 secondes" et "Tous les navigateurs doivent être supportés".
Ce sont les besoins dits "non fonctionnels" avec lesquels je dois travailler depuis plusieurs années… Si le champ de liberté dans la conception est assez vaste (c'est peu de le dire !), la réalité se révèle toujours trop tard bien plus restrictive.
Déjà, la notion de besoins “non fonctionnels” (ou plus communément NFR en anglais - Non Functional Requirements) est relativement propre au monde de l’IT. Loin de moi l’envie de lancer un débat à propos de cette appellation (imagée de façon intéressante dans cet article), mais il n’en reste pas moins que cette typologie de besoin est régulièrement délaissée en comparaison de ses homologues dits fonctionnels, légaux ou contextuels que nous connaissons plus communément
A cause de cette appellation à connotation “technique”, les NFR sont souvent définis (quand ils le sont) entre profils techniques : Architecte, Tech Lead, Développeur. Le manque d’ouverture et de challenge de ces exigences par des profils plus variés (métiers, UX/UI, etc) aboutit généralement à une liste de critères “basiques” et peu discriminants, comme nous avons pu le voir en exemple au début de cet article.
Pour éviter cet écueil, il est donc crucial que les NFR soient définis au-delà du simple spectre technique pour éviter de se retrouver face à de telles problématiques :
- Comment définir l’infrastructure sous-jacente sans connaître le nombre d’utilisateurs de la solution ?
- Comment définir des Recovery Time/Recovery Point Objectives cohérents sans connaître les impacts business et financiers d’une perte de données ou d’une indisponibilité de la plateforme ?
Dès lors, il est nécessaire d’inclure des points de vue plus diversifiés (business, design, produit, etc) pour définir ces besoins, mais d’autres problématiques surgissent alors :
- Comment réunir ces profils d’horizons variés dans des organisations potentiellement silotées ?
- Comment leur faire parler le même langage quand tous ne sont pas forcément familiers avec les besoins “non fonctionnels” ?
En essayant de répondre à ces questions, Michael Plöd s’est inspiré du livre “Game Storming” (également à l’origine de l’inspiration de l’atelier Event Storming) pour concevoir un atelier appelé “Quality Storming”. Cet atelier vise à réunir un groupe de personnes autour d’une table afin de définir collectivement ces NFR en prenant en compte tous les points de vue de l’entreprise et ainsi parvenir à une liste de critères approuvée par tous et pouvant servir de base solide et discriminante aux futures décisions d’architecture.
La théorie
Phase préparatoire
La première étape est d’identifier le modèle de qualité à utiliser afin de pouvoir cadrer l’idéation et organiser les idées. Le modèle de qualité peut être fourni par l’entreprise (et enrichi si besoin) ou il est possible de s’appuyer sur une version normée et exploitable issue d'un référentiel (ie. ISO2510).
La deuxième étape cruciale réside dans le choix des participants. Concernant les profils, le but sera d’avoir la plus grande variété possible de profils pour représenter tous les points de vue: développeur, architecte, designers, sponsors, expert métier, produit, sécurité, etc.
Dans le choix des participants, il est important de s’assurer que les responsables produit soient présents afin de rappeler la vision. Attention toutefois à ne pas oublier de personnes influentes (ex: CTO) afin d’éviter toute remise en cause des résultats de l’atelier !
D’après l’auteur, le nombre idéal de participants correspond à 2 à 3 fois le nombre de catégories du modèle qualité (soit entre 16 et 24 personnes pour le modèle ISO25010). Nous en reparlerons par la suite, mais ce nombre peut être revu à la baisse afin de faciliter l’organisation et la tenue de l’atelier. Concernant le timing, si la théorie exposée par Michael Plöd propose un atelier assez conséquent de 4 à 6h, il est possible de l’alléger avec certaines adaptations sur lesquelles nous allons revenir dans cet article.
Enfin, concernant l’espace, on prévoira une salle agencée comme l’image ci-dessous, dont chaque tableau représente un axe du modèle de qualité (post-it vert) avec ses sous-catégories (post-it rose) et éventuellement un exemple pour illustration si besoin (prévoyez une salle avec de l’espace !). Nous reverrons dans la seconde partie de cet article les ajustements réalisables pour adapter cet atelier au format distanciel.
Déroulé
L’atelier est décomposé en 4 grandes phases : Introduction, Broad Collection, Consolidation et Priorisation
Introduction
Avant de démarrer le cœur de l’atelier, il convient de bien le présenter auprès des participants et de gérer leurs attentes et leurs questions afin que toutes les incompréhensions soient levées. Enfin, nous insisterons également sur l’aspect “engageant” de cet atelier en rappelant que les résultats et critères produits serviront de base pour les futures décisions d’architecture, de design, de développement, etc.
De plus et en regard de nos expériences passées, il est important de rappeler que le but de l’atelier n’est pas de terminer la session avec un ensemble de NFR proprement formalisés, mais de favoriser en priorité la discussion entre les participants, la génération d’idées et leur priorisation : la formalisation se fera à la suite de l’atelier par les facilitateurs avant d’être communiquée.
Broad Collection
Cette étape est une phase d’idéation pure pour laquelle nous allons créer des groupes de 2 à 3 personnes aux profils hétérogènes (Dev, UX, Product Owner par exemple). Par cycle de 10 minutes, chaque groupe va passer devant chaque tableau (donc des catégories du modèle qualité) afin que tous puissent exprimer leurs besoins.
L’idée est de s’assurer que chaque point de vue soit exprimé et tracé afin de susciter le débat et d’assurer une couverture complète des besoins pour le produit.
Dans le contenu, nous essayerons au maximum d’avoir des besoins non fonctionnels qui soient “quantifiés” (nombre d’utilisateurs simultanés, temps de réponse par exemple) pour éviter les biais d’interprétations. Nous appuierons sur le fait qu’il soit normal d’obtenir des besoins similaires et d’autres contradictoires.
Cette phase dure généralement 1h30 au cours de laquelle un nombre important de besoins sont collectés et qui demande une dépense d’énergie importante. Une pause de 30 minutes est alors la bienvenue, durant laquelle les facilitateurs identifieront et regrouperont sur chaque tableau les besoins similaires et contradictoires afin de préparer la phase suivante.
Consolidation
L’étape suivante consiste à consolider les résultats obtenus lors de la phase “Broad collection”. Pour cela, les groupes de l’atelier précédent sont fusionnés afin d’obtenir des groupes de 4 à 6 personnes.
Ces groupes vont se succéder devant chaque tableau par cycles de 15 à 20 minutes : le but ici est de pouvoir se concentrer sur un groupe de besoins contradictoires (un objectif débattu en termes d’utilisateurs simultanés par exemple) afin de débattre et idéalement parvenir à un consensus : ce consensus peut aussi bien se porter sur un post-it déjà exprimé que sur un compromis qui sera alors écrit sur un post-it et affiché. Chaque décision sera identifiée avec une marque d’une autre couleur.
Chaque panneau doit être visité a minima par un groupe, idéalement deux afin que le travail soit challengé et validé par le plus grand nombre.
Durant cette phase, il est possible et probable que certaines discussions soient houleuses et qu’aucun consensus ne se dégage. Pour éviter de nuire au déroulé de l’atelier, plusieurs solutions sont alors possibles avec leur lot d’avantages et d’inconvénients :
Identifier un ensemble de besoins “candidats” et organiser un vote en plénière à la fin de la phase (solution rapide, mais qui risque d’occulter des problématiques légitimes)
Faire revoir le tableau par plus d’équipes pour obtenir des opinions différentes (nous avons un spectre plus large, mais cela demande un temps plus important)
Si aucune de ces solutions ne fonctionne, nous pouvons également remettre la décision à plus tard en le précisant (attention en revanche aux manœuvres politiques pouvant alors se mettre en place)
Une dernière alternative est possible : prendre un candidat comme “hypothèse” en précisant les métriques appropriées afin de confirmer/infirmer cette hypothèse dans le futur
Une fois la consolidation terminée, nous obtenons une liste de besoins non fonctionnels avec lesquels l’équipe va pouvoir travailler. Cette liste de besoins n’est pas suffisante en l’état : en phase de conception, il est rare d’identifier une solution répondant favorablement à l’ensemble des besoins (fonctionnels ou non fonctionnels). Il est alors nécessaire de pouvoir faire des concessions et de savoir sur quels critères il est possible de transiger ou non : c’est pour répondre à cette problématique que la dernière phase intervient.
Priorisation
La phase de priorisation va nous permettre de pondérer les critères collectés afin de fournir aux membres de l’équipe une base solide pour concevoir des solutions en réalisant des choix opportuns.
Pour réaliser cette étape, la méthode du “vote par points” sera utilisée et un certain nombre de points sera attribué à chaque participant (15 à 25% du total de besoins validés à la phase précédente). Chaque participant va alors pouvoir voter pour les besoins qu’il juge les plus importants en collant ces fameux points.
Dans l’idéal, on demande aux participants de coller au maximum 1 point par besoin, en acceptant 2 points si le besoin en question est réellement crucial pour lui.
L’intérêt de cette étape est l’attribution du même nombre de points par participant, quelle que soit sa position dans la hiérarchie. Ainsi, un développeur aura le même poids qu’un CTO dans la définition des priorités: ce parti pris se justifie par l'intérêt d’une “décentralisation” des décisions aux interlocuteurs possédant la connaissance du produit (fonctionnelle, technique, sécurité, etc) et permet de ne pas obfusquer des besoins et des priorités n’émanant pas de la direction.
La fin de la priorisation marque la fin de l’atelier dans sa version “Idéation” avec en livrable une liste de besoins non fonctionnels priorisés.
Outlook
Avant de clôturer la session, il est important de prendre le temps de conclure afin de faire une rétrospective des travaux menés. On résumera les résultats obtenus en soulignant l’importance du nombre et de la diversité des besoins que nous avons été capables de collecter durant cette phase.
Il est également crucial d’indiquer aux participants comment leur participation sera utilisée dans le futur (pour des prises de décisions par exemple) et de pointer où seront accessibles ces résultats ainsi que les livrables associés une fois la matière mise en forme.
S’ensuivra alors le travail de l’architecte (et/ou du facilitateur) pour consolider cette matière produite et la formaliser plus proprement dans les documents d’architectures adaptés : en prolongeant l’arbre du modèle de qualité, en l’intégrant dans un document d’architecture et/ou en rédigeant des scénarios de qualités (en suivant le standard arc42 par exemple).
À l'épreuve de la réalité
Ayant découvert le Quality Storming il y a quelques mois, nous avons tout de suite été fortement intéressés au sein d’Ippon pour expérimenter cet atelier. Nous avons alors saisi les opportunités de tester ce nouveau format lors de la conception de nouveaux produits et nous vous proposons ici de premiers feedbacks issus de notre expérience.
Adaptations possibles
La première concerne l’organisation de l’atelier : nous avons évoqué plus haut le format distanciel que nous avions retenu. En effet, la conjoncture actuelle rend plus difficile la tenue d’ateliers en présentiel et notamment la réunion d’un tel nombre de participants dans une même pièce.
Face à ces contraintes, nous avons donc réalisé ces ateliers à distance en recréant un canvas sous Miro et en utilisant une solution de visioconférence permettant l’usage de salles distinctes. Si on perd tout de même légèrement en interactivité (on prendra bien sur soin d’avoir un nombre de facilitateurs adapté à l’audience - 2 à 3 par exemple), le résultat est intéressant et le but de l’atelier est finalement atteint. On évitera en revanche de tenir l’atelier dans un modèle hybride où les discussions tourneront rapidement au cauchemar…
Une des difficultés principales de cet atelier réside dans sa planification : il demande beaucoup d’acteurs ainsi qu’une plage commune de disponibilités. Lors de nos ateliers, nous avons effectivement été confrontés à des manques de disponibilité des participants et avons essayé plusieurs pistes afin d’alléger l’atelier par rapport à la théorie :
Réduire le nombre de participants “requis”
Cette action nous a facilité la tenue du Quality Storming en limitant les agendas à synchroniser. La diminution du nombre de participants n’a pas particulièrement porté préjudice au contenu de l’atelier (tout le monde a parcouru l’ensemble des tableaux) mais nous avions pris soin de maintenir la diversité des profils qui est une des clés de la réussite. En revanche, le timing de l’atelier s’est un peu allongé puisque moins de personnes étaient présentes pour couvrir l’ensemble, notamment en phase de consolidation.
Réduction du nombre d’axes à étudier
Point un peu plus tendancieux et à manipuler avec précaution pour ne pas passer outre certains besoins critiques. La réduction peut s’opérer en regroupant certains axes ensemble (moins de risque, mais attention à la surcharge sur un même tableau) ou en en omettant d’autres.
Nous avons entre autres essayé cette seconde option en accord et après discussion avec nos interlocuteurs, ce qui nous a permis de réduire presque de moitié le nombre de “tableaux”, et ainsi accélérer partiellement la tenue de l’atelier. Il est cependant nécessaire de porter attention au choix des axes qui devient de fait subjectif, voire peut devenir politique et ainsi occulter des enjeux réels. Les axes éludés devraient alors être traités par d’autres biais afin d’assurer une couverture complète.
Cette solution peut s’avérer utile dans certains contextes, mais devrait être évitée au maximum dans le cadre du Quality Storming au risque de fausser les sortants et de dénaturer l’exercice.
Adapter l’agenda
Concernant le timing (4 à 6h préconisées), nous avons observé qu’il était compliqué de le réduire malgré les optimisations tentées sur le nombre de participants ou de tableaux : même en simplifiant, nous avons toujours à peu de choses près suivi la temporalité indiquée sans pouvoir accélérer.
En revanche, pour alléger la session et le programme de l’atelier, nous avons essayé de séparer l’atelier en 2 épisodes: les phases de Collection/Consolidation à J et la Priorisation/Conclusion à J+2. Ce format a plutôt bien fonctionné, mais demande de tenir les sessions rapprochées dans le temps pour éviter une trop grande perte d’informations. De même, pour garder une cohérence dans les phases d’idéation, je suis convaincu (même sans l’avoir éprouvé) que si une coupure est nécessaire dans l’atelier, elle ne peut intervenir qu’après la consolidation pour éviter d’interrompre la phase de définition des NFR dans sa globalité (avant priorisation).
Revoir le contenu avec les “décideurs” hors session
Ceci n’est pas une adaptation recherchée, mais plutôt opportuniste : au cours de nos ateliers, les décideurs n’ont pas toujours pu se joindre aux ateliers (ou à toutes les sessions). Afin d’éviter un manque de crédibilité de l’atelier vis-à-vis des sponsors, nous avons souhaité organiser une revue de l’atelier avec ces décideurs afin de valider le travail en cours.
Cette solution n’est clairement pas optimale et peut être difficile à gérer politiquement avec les autres membres de l’équipe, a fortiori dans le cas d’une revue faite après la fin de l’atelier (donc de la priorisation).
Lorsque nous avons été confrontés à ce cas, nous avons réussi à organiser cette revue entre la phase de Consolidation et de Priorisation en profitant de la séparation de l’atelier en 2 sessions (cf. point 3). Cela nous a permis de parcourir avec le sponsor un ensemble d’informations déjà raffinées, et ainsi de faciliter la revue et la validation des travaux menés. Cette revue officieuse peut toujours amener des biais, mais cela s’est bien passé et a été accueilli positivement lors de notre atelier, et l’équipe a pu travailler sereinement sur la priorisation des besoins validés.
Ressentis
Après quelques Quality Storming menés au sein d’Ippon et au-delà des pistes d’adaptation proposées, voici nos premiers ressentis autour de cet atelier.
Tout d’abord, l’exercice est un franc succès d’un point de vue du contenu et nous réussissons enfin à obtenir de vrais besoins non fonctionnels, cohérents et réellement utiles pour la conception de nos solutions (et c’est là le point le plus important !)
Ensuite, il ne faut pas être trop strict (surtout sur les premiers ateliers) sur le sens et la définition d’un besoin non fonctionnel : il faut expliquer la notion et ce qu’on en attend dans l’idéal pour que chacun soit aligné, mais il ne faut pas non plus “surexpliquer” pour éviter de brider ou décourager les participants alors que le principe sera au final rapidement saisi en démarrant l’atelier. De même sur les catégories, elles permettent de donner un cadre, mais il ne faut pas hésiter à laisser les participants digresser sur un tableau afin de recueillir de la matière qui pourra être exploitée par ailleurs.
Un travail de réorganisation et de filtrage sera nécessaire, mais en laissant ces libertés, cela permet de récupérer de nombreuses informations, non fonctionnelles, voire plus, qui viendront renforcer la vision du produit cible dans sa globalité. De leur côté, les participants deviendront de plus en plus matures à force d’exercice et les NFR seront de mieux en mieux exprimés naturellement.
De plus, durant nos sessions, nous avons remarqué que l’atelier apportait un côté “fun et dynamique” dans les équipes et que, au-delà même de l'expression des besoins non fonctionnels, il permet d’accentuer le travail d’équipe, même au sein d’organisations dans lesquelles la communication n’est pas forcément idéale.
Enfin, le Quality Storming reste un atelier éprouvant pour les participants de par sa richesse et sa durée, il est donc important de ne pas oublier de faire des pauses conséquentes afin de conserver le dynamisme des participants tout au long de la session.
Ces premiers tests grandeur nature sont donc un succès pour nous, et nous prévoyons de continuer à mener ce type d’atelier, car nous sommes convaincus de la valeur qu’il nous apporte dans nos choix de conception et donc in fine à nos clients. Côté client, les retours sont également positifs, et je vous laisserai avec quelques verbatims entendus lors de nos ateliers en attendant de venir les chercher chez vous !
Vous pouvez retrouver la présentation de cet atelier par Michael Plöd par ici
