Retour d’expérience Scrum sur un projet BI


Contexte

Jusqu’à présent, mes expériences Scrum tournaient autour des technologies Web. La BI m’est inconnue et me voici amené à être Scrum Master sur un projet décisionnel.
C’est pourquoi j’ai eu cette réflexion sur la manière d’appliquer Scrum dans ce contexte. Je vous présente ici, mon expérience sur ce projet mais également les retours que j’ai pu avoir des différents experts BI que j’ai pu côtoyés.

BI et Scrum, est-ce compatible?

Avant d’arriver sur ce projet, la seule inquiétude que j’avais, était de monter en compétence sur la BI mais rapidement certaines personnes m’ont fait part de leur scepticisme sur l’application de Scrum. J’ai recherché de la documentation sur ce sujet, et je n’ai rien trouvé qui me satisfaisait, la plupart des articles trouvés décrivent la méthodologie Scrum sans vraiment entrer dans les spécificités de la BI.

Avec du recul, ça paraît normal qu’il n’y ait pas beaucoup de documentation sur ce sujet car Scrum est une méthodologie qui s’applique indépendamment des technologies. C’est le contexte du projet qui compte.

Scrum peut s’appliquer à la BI et je vais expliquer progressivement mes différents points de blocage qui se sont peu à peu résolus.

Je ne connais rien en BI, est-ce grave?

J’avais pour habitude de faire quelques tâches de développements sur tous mes projets. J’aime garder un œil sur la technique mais sur un projet BI, j’ai du m’abstenir.

En théorie, le Scrum Master n’est pas obligé de faire du développement mais j’appréhendais cette nouvelle expérience car ça me semblait logique qu’un Scrum Master ait un bagage technique.

Quelques notions s’avèrent tout de même utiles à la compréhension d’un projet BI : modèle en étoile, dimension, mesure, fait… Un peu de lecture permet de combler rapidement ces manques, sans besoin de rentrer dans le détail.

Finalement, sur ce projet, nous avons un PO et des développeurs qui respectent bien leur rôle. Il n’y a aucune raison pour que je n’arrive pas à assumer mon rôle de Scrum master. Le maintient de la méthodologie se fait sans problème même si je ne développe pas.

Longueur des sprints et sprint review

Au démarrage de notre projet, il a fallu mettre en place l’intégration des premiers fichiers sources, la base de stagging, l’entrepôt de données, le cube et sharepoint pour enfin afficher nos premiers rapports.

Pour les premières fonctionnalités, il a donc fallu faire beaucoup de développements pour avoir de quoi montrer quelque chose au client.

C’est pourquoi, on s’est posé plusieurs fois la question de passer à des sprints de un mois au lieu de 2 semaines. Ce n’est pas interdit par Scrum mais j’aime bien les sprints de 2 semaines, d’une part car ça plait au métier d’avoir des retours si rapidement et d’autre part, ça donne une cadence qui rythme les développements.
Mais est-ce faisable techniquement? pouvons-nous livrer des fonctionnalités toutes les 2 semaines? C’est là que je vois la particularité de la BI. On n’a pas forcément des fonctionnalités visuelles à livrer sur les premiers sprints. Alors que montre-t-on lors de la démo au client? On peut par exemple, montrer le modèle de données. Il peut y avoir un sprint de conception car en BI, la technique reste proche du fonctionnel. Les échanges avec le métier sur le modèle du cube peuvent s’avérer enrichissants et donner lieu aux premières modifications du besoin initial.

On peut également montrer les rapports d’intégration de fichiers. Nous avons découpé certaines user stories en plusieurs. Par exemple, la mise en place d’une mesure initialement prévue en une user story a été découpée 2 :
– Une user story d’intégration des fichiers sources : “En tant qu’utilisateur A, je souhaite que les fichiers sources du système X soient intégrés afin de pouvoir effectuer des analyses sur ces données”. Les critères d’acceptation sont de visualiser un report d’intégration et des alertes en cas d’erreur d’intégration.
– Une autre qui portait sur le besoin d’analyse : “En tant qu’utilisateur A, je souhaite accéder aux mesures X et Z, afin d’y effectuer des analyses”.
Ainsi, nous avions de quoi montrer notre avancement au métier dès les premiers sprints.

Développement incrémental

Sur mes expériences de projets Web, la plupart des développeurs avaient déjà expérimenté Scrum. Alors que parmi les développeurs BI que j’ai côtoyés, peu d’entre eux avaient expérimenté cette méthodologie, même s’ils la connaisse vaguement.
Mais, dans la pratique, le développement incrémental fait surgir quelques réticences. Certains développeurs veulent tout développer d’un coup et le métier pense qu’il ne changera pas d’avis et donc n’y voit pas d’intérêt. Mais lors de l’enchaînement des sprints chacun prend ses repères et tout le monde y voit des avantages :

– les développeurs comprennent que s’ils avaient tout développé d’un coup, certains développements auraient dû être mis à la poubelle car le métier à changé de position sur certaines fonctionnalités. Ce qui peut démoraliser.

– le métier comprend qu’il peut changer d’avis sur ses fonctionnalités tant que ce n’est pas pris sur un sprint.

Conclusion

Peu importe les technologies employées, si on a les bonnes personnes qui assument les bons rôles, Scrum s’applique sans problème.
Je conseille vivement de tenter l’expérience si ce n’est pas déjà fait. Les réticences ou appréhensions rencontrées venaient surtout du manque de connaissance et d’expérience sur Scrum. Tout comme, moi, j’appréhendais faire de la BI. Rien ne vaut une démonstration pour convaincre :-)

4 commentaire(s)

  • Merci pour ton retour d’expérience de la mise en oeuvre d’un projet BI avec Scrum.

    J’ai toutefois une remarque sur ton découpage :
    – Une user story d’intégration des fichiers sources : …
    – Une autre qui portait sur le besoin d’analyse : “En tant qu’utilisateur A, je souhaite accéder aux mesures X et Z, afin d’y effectuer des analyses”.

    On voit clairement qu’il ne respect pas les critères INVEST
    Le I : Indépendante des autres : Implémentée avant ou après n’importe quelle autre

    Je n’ai pas la réponse , mais tu fais un découpage “Horizontal” (vision techniqe) et non “Vertical” (Vision utilisation).

    Pour moi c’est le gros problème des projets BI , si quelqu’un a réussi à faire autrement , personnellement je suis preneur de REX 😉

    Reply
  • En effet, je suis d’accord. J’ai mis en place ceci pour essayer de réduire la durée des sprints.
    Mais finalement, c’est préférable d’avoir des sprints d’un mois pour que l’équipe ait le temps de mettre en place une solution fonctionnelle à chaque sprint.

    Reply
  • Merci pour ce REX.
    J’ai une question sur l’automatisation des tests, comment avez vous fait pour assurer un développement et des recette en continue en // ?

    Reply
    • Bonjour,

      Si on parle d’automatisation, il est possible d’utiliser des outils tels Fitnesse ou NBI (add-in de NUnit) qui permettent de jouer des requêtes et vérifier le résultat.
      En terme d’organisation, la BI n’a rien de différent des autres technos. Les développeurs créent leurs tests et s’assurent qu’ils sont en succès à chaque livraison.

      Par contre vous parlez de recette et je pense que les tests automatisés ne dispensent pas d’une recette métier. Les tests automatisés vont éviter les régressions, vérifier certaines règles mais n’empêcheront pas certaines incompréhensions des fonctionnalités à livrer.
      La recette doit tout de même avoir lieu pour que les utilisateurs métier valident les fonctionnalités livrées.

      Reply

Commentez cet article