[Tribune] L'agilité et la méthode scrum en pratique

Il est de plus en plus rare d'entendre parler de projets digitaux sans que les mots "agilité" et "scrum" (méthode agile dédiée à la création de projet) ne soient évoqués. Pour aider des clients à sortir d'une impasse ou parce que ces méthodes sont déjà utilisées en interne, nombreux sont les consultants certifiés "scrum/agile" à intervenir dans des rôles de product owner, c'est-à-dire qu'ils définissent et priorisent, avec l'équipe métier et l'équipe de réalisation, le produit et ses fonctionnalités.

La méthode scrum est notamment adaptée au développement de projets ou produits complexes. La méthode a été proposée à l'UFC-Que Choisir à l'occasion de la refonte de son site internet. La méthode traditionnelle (cahier des charges, maquettes fonctionnelles, spécifications fonctionnelles générales et détaillées, maquettes graphiques) avait été utilisée dans un premier temps pour la partie front-office mais pas encore pour la partie back-office. Il y avait donc deux grands problèmes: une liste de fonctionnalités front-office trop importante par rapport au temps imparti, et aucune spécification pour la gestion en back-office. Le groupe souhaitait changer de Content management system (CMS) et modifier l'architecture en place.

La méthode scrum fonctionnant de manière empirique, le projet a débuté avec une première phase visant à définir l'architecture technico-fonctionnelle des back-offices ainsi que la technologie de CMS la plus adaptée aux besoins. Un élément clé de la méthode agile réside ainsi dans la priorisation de chaque élément fonctionnel (en langage scrum : "card" ou "user story") en fonction de son ROI .

Comment définir le ROI de chaque card ?

Pour obtenir un ROI, deux éléments sont à définir pour chaque card. D'abord, sa complexité: c'est l'équipe de réalisation qui donne une valeur relative par rapport aux autres fonctionnalités. En tant que product owner, il est envisageable de négocier sur ce qui est inclus dans la fonctionnalité, voire la découper en plusieurs sous-fonctionnalités, pour repérer ce qui a le plus de valeur. Ensuite, sa business value: estimée par les parties prenantes et les utilisateurs, qui ont parfois des intérêts divergents. Il peut donc être complexe de définir un dénominateur commun. C'est au "product owner" de les aider à le trouver.

Deux méthodes peuvent être utilisées:

- la méthode d'estimation qualitative: organisation d'ateliers "buy your feature", où les parties prenantes vont définir le prix et acheter les user stories du futur produit, ou de façon relative, positionnement par rapport à d'autres user stories déjà évaluées.

- la méthode d'estimation quantitative: utilisation des outils de webanalyse , d'A/B testing, ou de données métiers internes. Dans le cadre d'un projet de refonte de site internet, il est plus simple d'estimer la valeur pour une page ou une fonctionnalité existante (à partir des données de webanalyse, nombre de pages vues, taux de clic, taux de conversion etc.) que pour une page ou une fonctionnalité nouvelle (une technique consiste à A/B tester un élément fonctionnel, comme un bouton, sans développer totalement la fonctionnalité, pour estimer la performance de ce dernier).

Au fur et à mesure, le backlog (liste des cards ou user stories) s'enrichit, se précise (division ou fusion de user stories) et s'ajuste. L'objectif n'est pas d'être précis dans les valeurs mais bien de pouvoir prioriser et d'obtenir le MVP (minimum viable product : première version éligible à une mise en production).

Dans un projet, trois variables sont interdépendantes pour garantir la qualité du produit: le périmètre, le délai et les coûts. Si les trois sont fixés indépendamment, il n'est pas possible d'en maîtriser la qualité. C'est l'un des inconvénients de la méthode traditionnelle, qui fixe le périmètre (spécifications fonctionnelles générales puis détaillées), le planning et les coûts a priori.

Cependant, passer "en méthode scrum" n'est en aucun cas une solution miracle, ni la garantie d'une réussite du projet. En revanche c'est un cadre pour aider à :tirer le meilleur parti des ressources, garantir la qualité des produits, commencer la phase de réalisation à partir d'une vision globale, travailler de manière itérative, éviter l'effet tunnel (période pendant laquelle les métiers n'ont pas de visibilité sur le produit) et ajuster la priorisation en fonction des feedbacks.

La méthode agile appliquée aux web analytics

La méthode agile peut s'appliquer à de nombreux processus différents, pas seulement au développement pur de sites internet ou d'applications. Elle a pour interlocuteurs différents "clients internes, " en charge des évolutions des pages du site ou du développement de nouvelles fonctionnalités. Leurs besoins métier en collecte de données sont centralisés par des product owners (PO) au sein de l'équipe web analytics, qui les traduisent en besoins de tracking du site. Ces demandes sont priorisées par les PO et leur complexité est évaluée par les développeurs. Ce travail préparatoire, orchestré lors de réunions récurrentes, permet de définir les sujets qui feront partie du "sprint", c'est-à-dire qui seront traités dans les trois semaines à venir.

Quels sont les points positifs de cette méthode?

- Réfléchir en amont aux sujets prioritaires, à la différence de l'ancienne méthode, qui consistait davantage à du "premier arrivé-premier servi".

- Chaque sujet est matérialisé par un post-it et priorisé en le déplaçant sur un grand panneau: cela assure une transparence vis-à-vis des demandeurs et de l'équipe, puisqu'il est possible de visualiser clairement les sujets par ordre de priorité.

- Une fois un sujet embarqué dans un sprint, un délai précis est communicable aux équipes métier quant à sa finalisation - qui aura lieu, si tout se passe bien, à la fin du sprint.

- Les équipes métier, clientes internes, qui sont également en méthode agile, reçoivent des spécifications techniques qu'elles peuvent implémenter rapidement. Cela leur permet de mesurer, par exemple, la performance d'un nouveau bouton, d'un nouveau volet qui se déplie. L'équipe analyse durant une période courte les données. En fonction des résultats, elle peut décider de garder ou non la fonctionnalité.