Agile et règlementaire

Attention à ne pas confondre agile et Scrum ou bien encore agile et XP. Être agile, c'est se conformer aux valeurs et principes de l'agilité. Encore faut-il les lire vraiment... Pas en diagonale !
Vous pouvez retrouver une version française du manifeste agile sur ce site.
Prenons la première valeur :
Les personnes et leurs interactions plus importantes que les processus et les outils.
Cela ne signifie pas que les processus ne sont pas importants.
En ce qui concerne l'aspect réglementaire, nous voyons qu'il n'y a pas de contre-indication. Au contraire, si nous considérons ces principes agiles comment autant de guides de diminution de risques sur les développements, nous pouvons en déduire de façon quelque peu théorique que l'agilité est particulièrement recommandée sur des projets critiques.

Scrum + XP de base

Cette approche - Scum+ XP - est une base, qui est insuffisante en cas d'environnement réglementaire.
Avant de s'intéresser aux ajouts nécessaires en cas d'environnement régulé, voyons tout d'abord les documents produits lors d'une mise en œuvre Scrum + XP.

  • Expression de besoins sous forme de "stories" : le backlog
  • Les Tests d'Acceptance - qui sont autant de spécifications - et naturellement associés aux stories
  • Le résultat des tests, sprints après sprints.


De base, Scrum + XP offre la traçabilité entre besoins, tests et passages de tests. Ce qui n'est pas rien.
Reste à voir comment outiller cela :

  • Outil de gestion de l'expression de besoins par stories
  • Outil de gestion des cas de tests
  • Outil de gestion des résultats de tests

et lien entre ces outils.

Scrum + XP adapté au règlementaire

Le principe de base du réglementaire : réfléchir à une stratégie de tests et tester pour s'assurer de la qualité du produit est en fait directement pratiqué au travers des différents processus agiles : expression de besoins, pilotage par les tests d'acceptance (définition de fini).
La question est plus de formaliser ces pratiques et bien entendu de les améliorer en tenant compte des exigences réglementaires.

Equipe


Les documents habituels - qui en eux-mêmes permettent au Product Owner/Manager de se forger une opinion sur la qualité du produit - sont renforcés par d'autres : plan de validation, protocoles de tests...

Sans reprendre l'ensemble des principes et pratiques, nous pouvons toutefois donner quelques "guides" simples de l'agilité

  • Centré valeur métier
  • auto-similarité de feedback concret et rapide (feedback à tous les étages)
  • travail en équipe et responsabilités claires
  • amélioration continue.

Comment appliquer ces principes ?
Prenons le cas d'un plan de validation.
Il décrit essentiellement la stratégie de tests - pour s'assurer de la qualité du produit, de sa conformité aux besoins - et est en quelque sorte un document "chapeau".
Appliquons les principes ci-dessus.

  • l'accent est mis sur les tests des fonctionnalités - ou features - les plus importantes
  • il est établi - tout comme les autres documents - de façon itérative, une première version dès la phase exploratoire et est complété si nécessaire en fonction de l'avancement du produit
  • les intervenants "qualité" sont embarqués au plus tôt dans le projet et travaillent en collaboration avec les autres membres
  • à chaque sprint, lors de la rétrospective, les questions de validation peuvent être évoquées et faire l'objet d'actions d'amélioration.

Dans ce billet Définition de fini, je rappelais l'importance de cette pratique. Et un corollaire qui est "ne pas remettre à plus tard ce que l'on peut faire et qu'il faut faire...". Il en est ainsi des tests d'acceptance qui deviennent donc à chaque sprint partie intégrante du protocole d'acceptance.

Fin de release

A strictement parler, nous pourrions dire que les tests d'acceptance sont passés systématiquement à chaque sprint.
La dernière campagne de tests est alors une formalité.
Plus précisément, si le plan de validation prévoit une validation sur une plate forme dédiée (plateforme de recette), alors cette plateforme devrait être utilisée à chaque sprint (ou, le mieux étant l'ennemi du bien, avant la phase décisive pré-release).
Le guide est : comment s'assurer que la phase de test finale est simplement une formalité ?

En résumé

Nous pouvons considérer que "réglementaire" signifie "encore plus d'attention". Et dans ce cas, les principes agiles, que l'on peut considérer comme autant de préventions de risques, sont d'autant plus pertinents.

Scrum + XP sont des bases, suffisantes la plupart du temps.
Il est nécessaire d'ajouter des pratiques
afin de satisfaire aux exigences réglementaires,
tout en respectant les principes agiles.