Dev
Comment l’agile peut déployer une application auprès de 150 000 utilisateurs en 6 mois…
Par La rédaction, publié le 22 juillet 2021
La conception de produits en méthode agile permet la mise en place de cycles de développement courts afin de présenter des résultats réguliers et incrémentaux, permettant la réduction du coup marginal de l’erreur. Mais lorsque les besoins proviennent de dizaines de milliers d’utilisateurs, il peut être plus rassurant de s’appuyer sur des experts représentant ces mêmes utilisateurs.
Par Mejdi Hizem, Expert Agile, TNP Consultants
et Victor Mateus, Consultant Senior, TNP Consultants
En limitant ainsi le nombre d’interlocuteurs, il est possible de gagner en efficacité, mais au détriment de la représentativité et, in fine, de l’adoption de la solution par les utilisateurs finaux.
Alors, comment développer et faire adopter une application de contrôle des risques pour 150 000 utilisateurs en six mois ?
CONSTITUER UNE « CORE TEAM » DES BESOINS AUTOUR DU PRODUCT OWNER
Afin de maximiser la représentativité des besoins, nous avons pris le parti de ne pas solliciter des experts, mais des utilisateurs finaux reconnus par leurs pairs ; nous nous sommes focalisés sur la recherche de la « voix du client », en mettant de côté l’expression de besoin pour aller à l’essence même des besoins utilisateurs. Sur ce type d’application, l’expérience montre que 20 % des expressions de besoins permettent de couvrir 80 % des besoins utilisateurs.
Avec l’aide des sponsors de la direction des Risques, nous avons donc monté une « core team » constituée de huit ambassadeurs, en moyenne, et portant chacun la voix des utilisateurs finaux ainsi que de leurs managers. En prise directe avec le PO, cette équipe était au cœur du raffinage des besoins exprimés. Nous avons ainsi tenté de construire conjointement des solutions fonctionnelles les plus simples possibles, nous permettant d’avoir 95 % des fonctionnalités communes à tous les utilisateurs.
DÉVELOPPER, DÈS LE DÉMARRAGE DU PROJET, UNE CULTURE DE LA MESURE
Une fois les EPIC et les US déterminées, le backlog a été construit conjointement entre la core team et le PO : chaque US a été valorisée en termes de complexité grâce au poker planning. Ces mêmes US ont également été priorisées par la core team afin de prendre en compte les priorités du métier.
Au fil du temps, et avec le gain en maturité de l’équipe, une priorisation des enjeux au niveau des EPIC a également été introduite. À noter qu’une identification systématique des US « spécifiques » a été mise en place, car nous sommes convaincus qu’au-delà de 20 % de fonctionnalités spécifiques sur un outil de masse, la conception est un échec.
Des indicateurs de suivi de la capacité à faire (CAF) ont été mis en place, intégrant les points de complexité abordés précédemment ainsi que les charges d’automatisation des tests, de formation (à l’automatisation notamment), ainsi que de remédiation de la dette technique.
Enfin, une attention toute particulière a été apportée aux utilisateurs finaux, ainsi qu’à leur niveau de satisfaction. Celui-ci a été mesuré à la fois de manière quantitative (nombre d’utilisateurs connectés aux démos, enquêtes de satisfaction) et qualitative (retours de démos, fil des questions/ réponses).
PROTÉGER LA CAPACITÉ À FAIRE POUR ÉVITER L’ASPHYXIE
Faire « vite et bien » est tout à fait possible. Le faire dans la durée est plus ardu.
Pour être en mesure de préserver la capacité à faire de l’équipe de développement, nous avons été intransigeants sur le maintien de la capacité à faire « non fonctionnelle ». En effet, nous avons maintenu dans le temps une capacité d’automatisation fixe qui a permis de maintenir un taux d’anomalies en dessous de 16 %, contre 20 % en moyenne pour le marché (calculé pour 100 jours*hommes de développement). Cinq jours*hommes de formation à Cucumber Studio ont été investis pour chaque membre de l’équipe projet. En réservant également 5 % à 10 % de la CAF pour automatiser les tests, l’équipe projet a pu pratiquer et maintenir une CAF fonctionnelle suffisante au rythme des itérations.
D’autres bonnes pratiques ont également été mises en place, dont la remédiation systématique des non-conformités techniques constatées (par exemple, le changement du framework de gestion des données persistantes en base de données) afin de limiter l’accumulation de dette technique.
Mis en regard des besoins du backlog, ces indicateurs et bonnes pratiques ont permis de prioriser les fonctionnalités nécessaires pour le MVP 1. Nous avons donc alerté pour arbitrer objectivement le périmètre. In fine, pour transformer la capacité à faire en capacité à délivrer, nous avons dû, avec la core team, dépriorisé près de 30 % du périmètre initial pour le MVP1 et le reporter au MVP2.
En conclusion, pour être en mesure de livrer dans les délais une solution de masse, l’expérience montre que la construction d’un backlog avec la « voix des utilisateurs » est nécessaire, dès le démarrage. Si l’expertise métier reste le cas le plus courant pour les expressions de besoin, elle ne garantit en rien l’adoption ultérieure d’un produit parfois inadapté à la simplification des tâches opérationnelles. C’est ce qu’apporte deux concepts clés de l’agile : la voix du client et l’automatisation.
A lire également dans notre série thématique sur l’Agile :
Comment réussir un projet agile en télétravail ?
Management Agile (3/3) : maîtriser les leviers technologiques
Management Agile (2/3) : les processus métiers
Management Agile (1/3) : le leader d’équipe
ERP et agilité, enfin possible ?
L’Agile, un levier pour surmonter la crise.
L’Agile au forfait, comment changer la posture des Achats ?
Comment impliquer le Métier dans les projets Agile ?
Être Agile sans « soft skills », est-ce possible ?
L’Agile a-t-il besoin d’un chef de projet ?
L’automatisation, une nécessité pour créer de la valeur en Agile
Transformation Agile à l’échelle : quelle stratégie pour votre entreprise ?
Le bien-être de l’équipe, l’autre vertu de l’Agile
Convertir son entreprise à l’Agile… en douceur
Méthodes agiles : il est temps de passer à l’échelle !
