Une question qui revient souvent : doit-on vraiment utiliser les Nonfunctional Requirements (NFR) dans des projets en Scrum ? Avant de répondre à cette question, nous allons commencer par définir ce que veut dire ce terme NFR pas forcément connu pour tout le monde.
Sachez qu’il existe 3 façons différentes de faire des NFR :
- des items techniques
- des critères du definition of done
- des critères dans les items
La deuxième est devenue la plus couramment utilisé car le framework SAFe a défini les NFR comme des critères du Definition of Done.
Définition des NFR en tant qu’item technique
Dans un projet scrum, nous sommes souvent confrontés à un soucis ; comment gérer des demandes techniques qui seront utiles pour ne pas dire indispensables pour plusieurs user-stories (US) ?
Par exemple, je dois ajouter une table « offre » pour créer une fiche produit ; mais cela sera vrai aussi pour le panier, mais aussi le back-office…. Sachant que pour cela, il me faudra installer une base de données. Donc j’aurais 3 user-stories suivantes :
- En tant que client je souhaite visualiser le produit de façon détaillée
- Et en tant que client je souhaite ajouter un produit au panier
- En tant que logisticien, je souhaite lister la liste des produits disponibles
Pour ces 3 users-stories, nous aurons le besoin (requirement) technique (nonfunctionnal) d’une base de données pour réaliser ces 3 user-stories. A première vue, rien de dramatique… Cependant, cela va soulever différentes questions :
- Sur quelle user-story, on va estimer la charge ? La charge sera différente si on inclus ou non l’installation de la base de données.
- Si je mets l’installation de la base de données sur les 3 user-stories, est-ce que je ne risque pas de faire 3 fois le travail ?
- Si je mets la charge de l’installation de la base de données sur une user-story, est-ce que je ne force pas la priorisation de celle-ci ?
Il existe différentes écoles pour répondre à ce problème et pour ma part je vais vous conseiller la méthode suivante.
Nous parlions de ce type de NFR en vidéo sur La Minute Agile, n’hésitez pas à la regarder.
L’utilisation de storyotypes
J’en avais déjà parlé mais je privilégie l’utilisation de storyotypes que j’avais déjà expliqué dans un précédent article. Cependant, je ne la privilégie pas dans toutes les situations.
Article : Faire des user-story de différents storyotypes
Les Nonfunctional Requirements (NFR) sont pour moi des tâches techniques qu’il faut vraiment différencier des user-stories.
Je n’écrirais pas ma NFR comme ceci : « En tant que dev, je souhaite avoir une base de données afin de créer une table offre ». En effet, je trouve que mélanger les user-stories et les tâches techniques a tendance à être perturbant. Laissons cette syntaxe aux user-stories ; privilégions le type « Mettre en place une base de données » si nous reprenons l’exemple précédent.
Une sous-tâche reste une sous-tâche
Maintenant, partons sur la création d’une table offre en considérant que la base de données est déjà installée ; je laisserais alors la création de la table offre au niveau des user-stories car l’impact est minime.
Nos développeurs vont découper en sous-tâches techniques nos user-stories lors de la Sprint planning. Sachant qu’il y a une daily tous les matins, un board visuel (si possible avec les sous-tâches techniques) et que l’équipe de développeurs dépasse rarement 7 personnes, la communication reste relativement simple intra-équipe.
Dans une équipe avec une bonne maturité agile, l’estimation se fait souvent peu de temps avant le sprint planning (en product backlog refinement) voire directement en planning. Le risque que la création de la table soit un problème reste minime et n’impose pas de NFR.
Pourquoi aller complexifier le travail de l’équipe en ajoutant un NFR alors que ce besoin est minime ? Y a t il vraiment des risques à ne pas faire un NFR pour une création de table offre ? Sincèrement, je ne pense pas… On imagine des problèmes où la probabilité de tomber dessus est presque nulle.
Le spike pour venir en aide
Cependant, si une véritable étude technique est indispensable pour créer une partie du modèle autour de la table offre, alors je recommanderais dans ce cas un Spike (un type de tâche différent des user-stories).
Le Spike est une technique qui permet de réaliser de la recherche sur quelque chose encore impossible à estimer réellement.
Article : Qu’est-ce qu’un Spike dans un projet Scrum ?
Oui aux Nonfunctional Requirements (NFR) dans certains cas
Les indispensables de début de projet
Quand nous lançons un projet, il est parfois indispensable d’installer ou de mettre en place certaines choses indispensables pour lancer le projet : un framework, une base de données, des outils de tests…
Dans ce cas je recommande vivement de mettre une tâche technique appelée ici Nonfunctional Requirements (NFR) car ce type d’installation a un impact sur 100% des user-stories. Sans passer par ces installations, aucune user-story ne serait réalisable.
De plus, ce type de travaux peuvent être relativement long voire durer tout un sprint.
Le refactoring
Le refactoring qui n’apporte rien à l’utilisateur final pourra être considéré comme un Nonfunctional Requirements (NFR) si il est considéré indispensable pour la suite du projet.
Avoir du vieux code et des anciens outils peut être préjudiciable sur :
- la stabilité
- le recrutement de nouveaux profils
- la sécurité…
Je rappelle qu’une user-story doit avoir une valeur business pour les utilisateurs clés.
Attention dans la gestion de votre refactoring : Le refactoring en scrum
En NoEstimate, c’est presqu’inutile
Quand les équipes fonctionnent en #NoEstimate, faire des Nonfunctional Requirements (NFR) devient presque inutile car le soucis de ne pas savoir où mettre la charge des indispensables n’existe plus.
Inutile de s’embarrasser en ajoutant des NFR alors qu’il n’y en a pas besoin dans ce cadre.
Les Nonfunctional Requirements (NFR) dans les user-stories ?
Dans certains cas, les NFR sont considérées par certains comme partie intégrante des user-stories pour indiquer certains pré-requis comme par exemple :
- fonctionnera sur IE 11
- site responsive
- fonction qui s’affiche en moins de 100ms
- activer la fonction « géolocalisation » sur iPhone
Cependant quand certains points sont les mêmes pour l’ensemble des user-stories, je préfère mettre le critère au niveau des Definition of Done afin d’imposer ces attendus à l’ensemble du projet.
Les Nonfunctional Requirements (NFR) dans la Definition of Done
Les Nonfunctional Requirements (NFR) peuvent aussi être représentés comme les pré-requis techniques que doivent respecter l’ensemble des « items fonctionnels ». Ce sont des critères qui se rajoutent souvent dans la Definition of Done.
Cela concerne souvent :
- la sécurité
- la fiabilité
- la performance
- la maintenabilité
- l’évolutivité
- la facilité d’utilisation
C’est même aujourd’hui la définition la plus courante que nous pouvons trouver (sûrement dû au au framework SAFe qui a donné sa version des NFR).
Conclusion Nonfunctional Requirements (NFR)
Si certains refusent catégoriquement les Nonfunctional Requirements (NFR) et que d’autres les imposent, pour ma part je fais parti de ceux qui les limitent mais qui les utilisent.
Bien que cette utilisation de NFR est discutable voire discutée, mon expérience me montre que c’est le cas où il y a moins de soucis sur la fluidité des développements. Si l’équipe refuse totalement cette façon de faire, en tant que coach agile, je ne peux que leur conseiller d’utiliser la méthode qui lui parait la plus logique, quitte à changer ou non après.
Pas d’inquiétude, selon leurs expériences, les coachs agiles ne donnent pas forcément les mêmes recommandations sur ce sujet de Nonfunctional Requirements (NFR). Mais ce n’est pas grave, ce qui compte réellement, c’est que l’équipe se sente au mieux avec la méthode qu’elle choisira.
Lien utile : Nonfunctional Requirements (NFR) in Scrum?
3 Rétroliens / Pings