MOA et MOE ne sont pas Agiles

En France on a tendance à abuser des notions de MOA et MOE

De nombreuses organisations utilisent intensivement ces acronymes. Personnellement je trouve que c’est de façon abusive, surtout quand on les utilise au sein d’une seule organisation ou pour des rôles alors que, historiquement, ces notions s’adressent à des personnes morales.

Mais l’essentiel n’est pas dans le nom. L’utilisation de MOA et MOE tend à créer une séparation très nette entre 2 groupes. Cela contribue aux problèmes suivants :

  • de la communication basée sur des documents au détriment de la communication orale
  • des spécifications trop détaillées dès le début du projet
  • des documents redondants [1]
  • des documents qui mélangent le quoi et le comment
  • du temps perdu dans un processus de validation de doc

Mais le plus grave arrive probablement quand la MOE livre un logiciel sans avoir passé de tests fonctionnels parce que c’est la MOA qui va le faire après. Alors là commence le flot infernal des fiches d’anomalie…

Alors quand on me demande après une présentation Scrum si c’est la MOA ou la MOE qui doit jouer le rôle de Product Owner, je réponds qu’il faut d’abord se débarrasser de ces notions et de ce qu’elles impliquent avant de passer aux méthodes Agiles. Il convient de faire tomber les murs et de créer une seule équipe qui contribue au même objectif, qui n’est pas d’écrire de la doc. Le Product Owner fait partie de cette équipe avec ceux qui analysent, conçoivent, développent, testent, rédigent, etc.

Notes

[1] normalement la MOE répond à la spec générale de la MOA par une spec détaillée et l’interprétation de générale et détaillée est très variable. Sans compter les documents de test…

Voir aussi