Cela fait quelques mois que je travaille sur un projet utilisant la méthodologie Scrum. Cette méthodologie dite "agile" bouleverse le travail de la MOA dans les organisations classiques où les rôles MOA et MOE sont gérés par des personnes distinctes, voire des équipes distinctes. Après vous avoir expliqué quelques bases sur l'agilité et la MOA dans un précédent billet (Le rôle de MOA est-il compatible avec les méthodes agiles ?), je me propose ici simplement de vous livrer mon retour d'expérience sur l'impact d'une telle méthodologie pour la MOA.
Ce qu'on a dit sur le rôle de la MOA dans les méthodes agiles...
On a beaucoup parlé des méthodes agiles depuis quelques années. Et on peut avoir l'impression par exemple que Scrum a été conçu par des développeurs, pour des développeurs. Je dis cela car la communauté agile s'est très vite rendue compte du problème que posait la MOA pour mettre en œuvre Scrum :
Scrum, Agilité et Rock'n roll : Se passer de la MOA ou se passer de l'agilité ?
J'ai dit à N. qu'une meilleure solution serait de supprimer la MOA. MOA et MOE c'est fait pour les travaux publics, pas pour le développement de logiciel. C'est le bon moment en période de crise pour éliminer les gaspillages...
Bon, c'était une boutade, on ne peut pas supprimer la MOA du jour au lendemain.
OCTO Talks! :
Installer Scrum sur une organisation existante
L’autre population qui est mise en porte-à-faux lors du déploiement de SCRUM : la MOA. Là aussi, le rôle de MOA tel que nous le connaissons est en grande partie absorbé par l’équipe : clarification du besoin, qualification des demandes, tests, … Quelle position la MOA peut-elle alors adopter pour continuer à apporter de la valeur à un projet ?
La solution en laquelle nous croyons aujourd’hui est que la MOA soit partie intégrante de l’équipe.
Et ce n'est pas seulement un problème franco-français ou un problème de la métaphore MOA/MOE issue du BTP. C'est simplement que les méthodes agiles veulent mettre le client au cœur du process de développement d'un système informatique, en limitant les gaspillages : documentation inutile, intermédiaires superflus entre le développeur et le client. Ces sujets touchent principalement les activités de la MOA.
... et ce que j'ai expérimenté : User stories et storyboards,
Sur mon projet actuel, nous avons donc mis en place Scrum. En tant que MOA, on m'a dit : "Maintenant, tu rédiges des user stories.". Ok. J'ai en fait pris le rôle de Product owner, délégué. Avant cela, j'ai quand même fait une étude préalable qui a abouti sur la rédaction d'un cahier des charges chargé d'une étude de l'existant et d'une liste d'exigences. J'ai ensuite décliné ces exigences en user stories. Ces user stories sont un outil très pratique pour planifier les sprints. Au départ j'ai simplement accompagné ces user stories d'un storyboard et de maquettes réalisées via Axure.
quelques spécifications fonctionnelles "old school"
Pas suffisant. J'ai rapidement bifurqué vers une spécification fonctionnelle détaillée ! Aïe, de la documentation ? Mais pourquoi ? C'était impossible d'avoir une vision globale du système sans cela. Et la traçabilité n'était pas suffisante, j'avais toujours l'impression d'aller à l'encontre d'un choix de conception fonctionnel fait plus tôt dans le projet, faute de me rappeler des motifs de ce choix. De plus il était très difficile de discuter avec les projets non Scrum sans un document de spécifications fonctionnelles. J'ai donc décidé de maintenir ce document, enrichi au fil des sprints en essayant d'avoir toujours un ou deux sprints d'avance. De plus certaines réglementations demandent que le système d'information soit documenté, donc impossible de passer outre une documentation fonctionnelle.
et les critères d'acceptation !
Oops, malgré cela, je me suis rendu compte que j'avais oublié un élément capital dans les user stories : les critères d'acceptation ! Pour faciliter la recette au fil de l'eau, il est important d'avoir ces critères d'acceptation au niveau des users stories, même si ceux-ci font souvent référence aux spécifications fonctionnelles. Je pense aussi qu'une automatisation des tests fonctionnels est capitale pour tirer tous les bénéfices d'un mode de développement avec des itérations courtes.
Au final, un bilan positif ?
Finalement, nous avons mis en place Scrum, mais j'ai quand même gardé certains outils propres aux cycles en V. Pourquoi ? Surement parce qu'on ne peut pas changer ses habitudes aussi facilement, mais aussi parce que Scrum ne se suffit pas à lui-même. Comme toute méthodologie, il faut l'adapter au contexte. Tous les développeurs ne sont pas capables de gérer les aspects fonctionnels, les clients ne sont pas forcément prêts à rédiger des users stories, et les équipes avec lesquelles vous devez interagir ne sont pas forcément "agiles". Les itérations courtes, les démos, la collaboration, la recherche du consensus, le pilotage par la valeur ajoutée sont par contre autant d'éléments très positifs de la méthodologie.
Je pense donc que le rôle de MOA ou AMOA s'inscrit parfaitement dans cette méthodologie du moment que l'on accepte que le product owner puisse être en fait une équipe composée d'un sponsor métier, d'utilisateurs clés et d'un ou plusieurs MOA. Dans ce cas, la ou les MOA doivent clairement avoir la délégation et la capacité pour arbitrer les points en temps réel, quitte à remonter ensuite les points les plus problématiques lors des comités de pilotage du projet. La MOA peut alors apporter toute son expertise en terme d'analyse, de modélisation et de construction de lien fort entre le SI et le métier.