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

Enregistrer un commentaire

Posts les plus consultés de ce blog

Audit de maturité agile

Image
Que l'on soit au stade de l'initialisation d'une transition, ou bien au stade où l'agilité est déjà intégrée et laisse place à l'amélioration continue et au coaching, il peut être intéressant d'évaluer le niveau de maturité de l'agilité à un instant T, que ce soit pour une équipe, un projet ou encore une organisation. Cet "instantané" de maturité permet à la fois d'identifier les axes d'amélioration et établir des plans d'action adaptés à chaque contexte, mais aussi de mesurer la progression dans la durée avec des prises de mesures régulières. Je propose ici une méthode simple et outillée avec Excel. Elle se base sur 5 axes d'audit, chaque axe comportant une série de questions. Les questions peuvent (doivent) être adaptées à chaque contexte. Attention tout de même : certaines questions peuvent ne pas être très complaisantes avec la réalité et soulever la poussière cachée sous les tapis! Quelque soit les questions, l&#
Lire la suite

Kanban en 4 étapes

Image
La méthode Kanban est une méthode simple, visuelle et compréhensible par tous les acteurs d’un processus. Elle est également faiblement intrusive dans l’organisation, contrairement à Scrum qui définit de nouveaux rôles (Product Owner, ScrumMaster), de nouveaux artéfacts (Product et Sprint Backlogs), une cadence figée (Sprints) et des cérémonies dédiées (Planning meeting, Sprint Review, etc…). Kanban est simple, mais sa mise en œuvre nécessite un peu de méthode et beaucoup d'accompagnement. Je vous propose dans cet article de décrire la démarche que j'ai implémentée sur l'un de mes projets. J'ai volontairement essayer d'en faire ici une démarche générique et non spécifique. Kanban en 4 étapes Pour démarrer avec Kanban, pas besoin de big bang. On part du processus existant, et on itère sur la mise en oeuvre, de manière progressive. On se focalise d’abord sur un flux simple ou un sous-flux, en limitant le nombre de nouveaux concepts à implémenter et ap
Lire la suite