Voici un retour d’expérience sur l’application de la méthode AGILE lors de la mise en place de rapports BI basés sur l’application de relation client (CRM ou Customer Relationship Management) à la demande d’un client du secteur bancaire.

Historiquement, ce client pratique la méthode AGILE et investit dans les nouvelles technologies, notamment sur le rapid delivery.

Les étapes clés d’un sprint AGILE

Phase 1 : Les ateliers fonctionnels d'un projet BI Agile (Refinement)

Une fois que le besoin de l’application a été émis, nous avons mis au point des ateliers fonctionnels avec :

  • 3 banquiers demandeurs de l’application (= le final User)
  • 1 Scrum Master (SM) : il suit l’équipe et s’assure que toutes les conditions sont réunies pour pouvoir dérouler au mieux le sprint et optimiser la réalisation
  • 2 Product Owners (PO) : il s’agit des garants des livrables et des tests associés
  • Les équipiers (ou dev team) : il s’agit de l’équipe de réalisation. Ils peuvent également être sollicités en support du PO ou du Scrum Master.

La présence de l’ensemble des personnes de la chaîne est essentielle pour que tout un chacun dispose d’une vue d’ensemble de l’application finale, même si lors de ces ateliers, tous les rôles ne sont pas acteurs.

Lors de l’atelier, la Scrum team (PO, SM et dev team) écoute et interagit avec les banquiers pendant qu’ils expriment leur besoin. L’objectif étant de comprendre au mieux leurs actuels et / ou futurs usages ainsi que leurs priorités.

Une fois le besoin clarifié, les PO traduisent celui-ci en fonctionnalités hiérarchisées et priorisées et constituent ainsi le backlog (Epic, Feature, User Story, Task, etc.)

Les User Story décrites doivent permettre à la dev team de comprendre parfaitement le besoin tout en ne dirigeant pas la conception technique. C’est l’équipe de développement qui reste maître de la solution technique qu’ils vont apporter au besoin (en consultant évidement tout intervenant extérieur nécessaire : architecte, leader technique, équipes adjacentes etc.)

Ex : Le client souhaite établir un rapport Cognos permettant de connaître les conquêtes de client sur le mois passé.

  • User story trop vague : Je (banquier) souhaite connaître mes nouveaux clients (quoi ? quand ?)
  • User story trop précise techniquement : Je (banquier) souhaite récupérer via une une requête SQL tous les id clients et attributs associés créés dans la table CRM_Customers du 1er du mois 00h00 au 31 du mois 23h59
  • User story OK : Je (banquier) souhaite connaître le nombre de nouveaux clients créés dans le CRM entre le 1er et dernier jour ouvrés du mois passe

À la fin, on arrive avec environ 20 User stories, chacune faisant l’objet de rapports Cognos, et il devra être possible de croiser les données in fine :

  • Quels sont les clients gagnés par le banquier sur le mois passé ?
  • D’où proviennent les clients que j’ai gagnés sur le mois passé ?
  • Ces clients, sont-ils des conquêtes internes à la banque (quelqu’un qui était venu pour un prêt bancaire, une assurance-vie), ou des conquêtes externes (arrivées via internet, recommandation, etc.) ?
  • Quelle est la typologie de mes clients en termes de : Age, Métier, Géographie, Sexe… ?

Phase 2 : Sprint planning du projet BI Agile

Une fois le backlog constitué, l’équipe de développement peut chiffrer avec des cartes de points de complexité chacune des Users Story en termes de réalisation. C’est ce qu’on appelle généralement le Poker Planning.

Le temps nécessaire pour cette phase est de plus en plus court à mesure que l’équipe gagne en expertise et en compétence sur les potentielles difficultés techniques.

Une fois toutes les US instruites et chiffrées, la scrum team est prête pour le sprint planning.

Durant cette cérémonie, l’équipe de développement décide d’embarquer ou non les US dans le sprint en fonction du nombre de points de complexité global qu’il est possible d’absorber sur un sprint (compte tenu des congés, de la capacité à faire, etc.) ainsi qu’en fonction des priorités exprimées par les métiers et reportées par les PO.

Phase 3 : Sprint du projet BI agile 

Durée : Dépend de ce qui est défini, mais pas plus de 3 semaines

Les réalisations de spécifications et les recettes sont généralement faites par les Product Owners et les développements par les équipiers. Néanmoins, la dev team étant une équipe pluridisciplinaire, chacun peut être en mesure de réaliser des tests sur une user story qu’il n’aura pas développée lui-même.

Tous les jours a lieu un daily meeting pour que l’équipe puisse partager son avancement et ses éventuels blocages.

Phase 4 : Sprint Review

Durée : 0.25 jour à 0.5 jour 

Les rapports qui ont été produits sont présentés aux banquiers. Ces derniers font un retour sur ce qui pourrait leur manquer, ce qui leur convient et ce qui est à revoir.

Très important : le rapport, même incomplet, est utilisable tout de suite, ce qui permettra de se maintenir dans la boucle Agile.

Phase 5 : Sprint Retrospective

Durée : 0.25 jour

Phase de rétrospective avec le PO, les équipiers et les clients finaux si besoin

Cette étape essentielle permet de voir ce qui va, ou ne va pas dans les sprints, pour prendre les actions correctrices pour les phases suivantes. Ainsi, les cycles suivants pourront s’améliorer afin que le client soit satisfait du produit qui lui a été proposé.

Ensuite, les phases 2 à 5 se répètent pour délivrer le produit final de façon itérative.

Résumé application de la méthode BI Agile 

La méthode AGILE permet de donner un livrable très rapidement au client afin qu’il puisse commencer à travailler immédiatement sur le nouveau produit et ce même si le produit ne répond pas complètement au besoin final. Cette méthode itérative permet de définir au mieux les besoins du client et pour les équipes informatiques, d’être plus efficientes.

Vous cherchez des consultants pour vous accompagner dans l'application de la méthode BI AGILE ? Contactez-nous !