Les exigences non fonctionnelles en agile

Un projet agile se pilote par la valeur apportée au métier. Spécifier agilement, c'est se focaliser sur l’expérience utilisateur, et décrire simplement les exigences qu'aura cet utilisateur dans l'usage du futur système, et ceci à différents niveaux de granularité (User Story).

Pour autant, l'intégration d'une application dans un SI, et plus généralement l'acceptation d'une application par un client passe aussi par le respect d'Exigences Non Fonctionnelles (ENF). Parmi celles-ci, on peut lister:
  • La Sécurité
  • La Performance
  • La Capacité
  • La Disponibilité
  • L'Intégrité
  • L'Évolutivité
  • La Maintenabilité
  • La Scalabilité
  • La Compatibilité

Il existe trois techniques simples permettant d’intégrer naturellement les ENF dans la réalisation d'un projet agile. Ces techniques ne sont pas mutuellement exclusives et peuvent parfaitement être combinées:
  1. Identifier les utilisateurs non métier et leur affecter des User Stories
  2. Insérer dans le Product Backlog des Spikes ou des Technical Stories
  3. Ajouter des critères d'acceptation non fonctionnels aux User Stories

Identifier les utilisateurs non métier et leur affecter des User Stories

Afin qu'un utilisateur métier puisse accomplir ses tâches au travers d'une application, il faut qu'un autre type d'utilisateur puisse lui en garantir la disponibilité: l'Exploitant.

L'Exploitant est un utilisateur de l'application comme n'importe quel autre. Il possède ses propres interfaces, qui peuvent être de simples lignes de commandes et des logs, mais qui peuvent aussi se matérialiser au travers d'écrans spécifiques.

Le fait de considérer ce type d'utilisateur non métier dès les premiers cadrages du périmètre et de lui identifier ses propres User Stories permet d'intégrer naturellement un certain nombre d'ENF. Par exemple:
  • En tant qu'Exploitant, je veux un script de bascule de nœud applicatif afin de pouvoir mettre à jour l’application sans interruption du service
  • En tant que RSSI*, je veux que l'application contrôle que chaque utilisateur se soit préalablement identifié au SSO


Insérer dans le Product Backlog des Spikes ou des Technical Stories

Le Product Backlog doit contenir TOUT ce que l'Equipe a la charge de réaliser. Il est donc important que le Product Owner soit sensibilisé au fait que certains des éléments du Product Backlog, bien que n'apportant pas de valeur directe aux utilisateurs, sont essentiels pour l'implémentation du produit. 

On peut donc construire un Product Backlog sur la base d'une typologie d'éléments:
  • Des User Story, qui représentent les fonctionnalités vues de l’utilisateur, et constituent la valeur intrinsèque du produit
  • Des Spike ou Investigation Story, qui représentent les besoins de travaux exploratoires lorsqu'il n’est pas possible d’estimer la complexité d’une User Story (manque d’entrant fonctionnel, hypothèse technique à prototyper, …)
  • Des Technical Story, qui représentent la mise en œuvre d’exigences techniques liées au produit,  à son environnement ou à la gestion de la dette technique

Exemples de Technical Stories:
  • Mise en place de l’environnement de gestion de configuration sous GIT, afin de se conformer aux outils en vigueur dans le SI 
  • Upgrade de la bibliothèques de composants graphique PrimeFaces, afin de bénéficier des dernières améliorations du fournisseur
  • Implémentation de la procédure de sauvegarde et de restauration, afin d'atteindre un RPO* de 30 minutes
  • Dénormalisaiton de la base de données afin d'optimiser les performances des requêtes

Ajouter des critères d'acceptation non fonctionnels aux User Stories

Enfin, lorsque des ENF s'appliquent plus spécifiquement à des fonctionnalités, on les ajoute simplement aux critères d'acceptation des User Stories.

Exemple de critères d'acceptation non fonctionnels pour une User Story:
  • Le tableau de résultat doit s'afficher en moins de 5 secondes
  • L'affichage doit être compatible IE9, IE10 et IE11
  • Seul le rôle Administrateur peut accéder à cette fonctionnalité


Normalement, ces trois techniques combinées permettent de ne rien oublier dans la réalisation, et d'estimer au plus juste la complexité réelle du périmètre à implémenter au sein d'une itération.


* RSSI : Responsable de la Sécurité des Systèmes d'Information
* RPO : Recovery Point Objective




Commentaires

Posts les plus consultés de ce blog

Audit de maturité agile

Kanban en 4 étapes