Les Nonfunctional Requirements (NFR) en Scrum ?

Ecrit par << Paquet Judicaël >>

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 pas forcément connu pour tout le monde.

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 aussi le panier, mais aussi le back-office…. Sachant que pour cela, il me faudra installer une base de données. En gros j’aurais 3 user-stories suivantes :

  1. En tant que client je souhaite visualiser le produit de façon détaillée
  2. En tant que client je souhaite ajouter un produit au panier
  3. 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.

L’utilisation de storyotypes

J’en avais déjà parlé mais je privilégie l’utilisation de storyotype 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 « En tant que dev, je souhaite avoir une base de données afin de créer une table offre » car je trouve que mélanger les user-stories et les tâches techniques a tendance à être perturbant. Laissant cette syntaxe aux user-stories et privilégions le type « Mettre en place une base de données » si on prend 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âche 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 est indispensable, 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 impossible à estimer réellement.

Article : Qu’est-ce qu’un Spike dans un projet Scrum ?

NonFunctional Requirement - NFR
NonFunctional Requirement – NFR

Oui aux Nonfunctional Requirements (NFR) dans certains cas

Les indispensables de début de projet

Quand on lance 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 sera 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é… C’est un point indispensable à traiter.

Je rappelle qu’une user-story doit avoir une valeur business pour les utilisateurs clés.

En NoEstimate, c’est presqu’inutile

Quand on fonctionne en #NoEstimate, faire des Nonfunctional Requirements (NFR) est 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 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.

Conclusion Nonfunctional Requirements (NFR)

Si certains refusent catégoriquement  lesNonfunctional Requirements (NFR) et que d’autres les imposent, pour ma part je fais parti de ceux qui les limitent mais qui les utilisent.

Si cette utilisation 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. Mais ce n’est pas grâce, ce qui compte réellement, c’est que l’équipe se sente au mieux avec la méthode qu’elle choisira.

[ Article lu 4 fois aujourd'hui ]

2 réponses sur “Les Nonfunctional Requirements (NFR) en Scrum ?”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.