Pré-requis
Avant de lire ce chapitre nous vous recommandons de vous familiariser avec la méthodologie SCRUM. Voici deux liens à lire obligatoirement et une petite vidéo :
Quelques autres ressources intéressantes :
Pourquoi une approche agile pour les projets de Business Intelligence ?
Le risque d’un projet de Business Intelligence conduit avec une méthode de type cycle en V est de produire tardivement des livrables qui ne sont plus en phase avec les besoins des utilisateurs.
Parmi les causes d’échecs fréquemment citées dans les projets Business Intelligence on retrouve un manque d’alignement avec la stratégie de l’entreprise, un manque d’adéquation avec les besoins des utilisateurs, la tentation de créer une usine à gaz ou de se laisser guider par un choix d’outil.
Les projets de Business Intelligence vont donc pouvoir tirer pleinement d’une approche de gestion de projet agile. Cette approche va permettre de s’adapter à l’évolution des exigences des utilisateurs et donc de développer leur engagement vis-à-vis du projet avec des livraisons opportunes et plus fréquentes.
Si on s’intéresse aux entrepôts de données, qui sont au coeur des technologies Business Intelligence, on peut découvrir deux écoles de pensées pour la modélisation des données : celle de Inmon et celle de Kimball. L’approche de Kimball, qui date de 1996, était déjà en phase avec les méthodes de gestion de projets agiles. En effet, la notion d’architecture en bus permet de donner de la souplesse au modèle de données dimensionnel.
Quelques liens pour approfondir ce sujet :
- Décisionnel agile : réalise son datawarehouse en itérations agiles
- La Business Intelligence Agile
- Retour d’expérience Scrum sur un projet BI
Découverte de l’approche SCRUM appliquée à la Business Intelligence
Nous choisissons ici de présenter l’approche SCRUM, mais ce qui est important avant tout est d’utiliser une approche qui convienne à votre projet et aux besoins de votre équipe. Dans le contexte de cet enseignement l’utilisation de SCRUM reste obligatoire pour tous les groupes dans un souci de simplicité d’organisation pédagogique.
Les différents rôles
Product owner
Le propriétaire du produit, ou Product owner est le représentant des parties prenantes et du client. Il n’est pas réellement le propriétaire du produit mais c’est lui qui est en charge de définir la vision du produit et la feuille de route afin de gérer le Product Backlog.
- Exprimer clairement les items du Product Backlog
- Ordonner les items du Product Backlog pour mieux réaliser les objectifs et missions
- Optimiser la valeur du travail effectué par l’Équipe de développement
- S’assurer que le Product Backlog est visible, transparent, et clair pour tous, et qu’il montre ce sur quoi l’Équipe de développement travaillera prochainement
- S’assurer que l’Équipe de Développement comprend adéquatement les items du Product Backlog
Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer à l’Équipe de développement. Toutefois, le Product Owner demeure responsable de ces dernières.
– – Le guide Scrum - Développé et maintenu par Ken Schwaber et Jeff Sutherland
Scrum Master
Le Scrum Master a pour rôle de veiller à ce que la méthodologie Scrum soit correctement appliquée. Il doit agir comme un coach et faire preuve de pédagogie auprès du Product Owner et de l’Équipe de développement. Attention il ne s’agit pas d’un chef de projet, même si parfois la même personne tient les 2 rôles.
L’équipe !
Une équipe Scrum est une équipe multi-disciplinaire composée de moins d’une dizaine de membres. Par multi-disciplinaire, on entend que toutes les compétences nécessaires au déroulement d’un projet décisionnel sont présentes au sein d’une équipe et non qu’une personne possède toutes les compétences.
Dans le contexte d’un projet de Business Intelligence nous retrouverons les personnes proches du métier, les experts en modélisation dimensionnelle de données, les experts en ETL (qui sont en charge des processus de préparation et d’alimentation en données), les experts des technologies de stockage (OLAP notamment) et les experts en conception et implantation de tableaux de bord. Vu le nombre de compétences nécessaire, la polyvalence est donc un atout pour être membre d’une équipe de développement agile de projets décisionnels.
Les outils Scrum
Les User Stories et la vision de votre produit
Les User Stories correspondent à une description des fonctionnalités en employant la terminologie de votre client. Ce qui peut faire la difficulté d’un projet Business Intelligence est que le client sait ce qu’il désire : “Je veux améliorer ma vision d’ensemble des produits en stocks” sans toutefois être capable de décrire ce qui pourrait ressembler à une User Story. Le Product Owner est donc en charge d’accompagner le client et l’Équipe de développement dans cette démarche en comprenant les activités du client et en proposant des User Stories (qui peuvent être illustrées par des maquettes de tableaux de bord) visant à répondre à ses besoins en terme de pilotage.
Une User Story comporte les éléments suivants :
- Un identifiant
- Un nom
- Une description courte décrivant une fonctionnalité, de manière indépendante des autres histoires (si possible) :
“En tant que … je peux …” - Une estimation du temps nécessaire pour le développement et les tests
- Une estimation de la valeur pour le projet
- Une description des tests d’acceptation
Les user stories sont focalisées davantage sur le cœur du problème, à savoir la satisfaction de l’exigence fonctionnelle. Elles vous forcent à vous focaliser. Le format de la user story est très clair. Toutefois les user stories peuvent être enrichies de certaines informations complémentaires. Et elles ont besoin de toute manière de critères d’acceptation !
– – Entretien avec Jean-Pierre Berchez
Le Product Backlog
– – Le guide Scrum - Développé et maintenu par Ken Schwaber et Jeff Sutherland
Le Product Backlog est donc composé de User Stories mais peut aussi contenir des éléments plus conceptuels qui sont clairs mais qui manquent encore de détails. Dans tous les cas, le Product Backlog est une liste ordonnée par priorités et valeurs des items du projet à réaliser. Cette liste évoluera au cours du temps, le client pouvant ajouter ou retirer des exigences, les priorités étant revues à la fin de chaque sprint.
Après avoir réalisé le Product Backlog, une étape importante est l’estimation du temps nécessaire pour réaliser les récits utilisateurs. Pour cela, nous vous conseillons de mettre en place un planning poker en vous aidant de cet outil par exemple.
Les événements Scrum
La phase de démarrage
La phase de démarrage appelée également Sprint 0 permet de laisser le temps aux travaux préparatoires au projet : définition des User Stories et du Product Backlog initial notamment.
Selon la maturité de la définition du projet décisionnel par votre client il pourra souvent être nécessaire de passer par une phase d’entretiens afin de comprendre son activité et d’identifier les User Stories qui définiront son besoin en terme de pilotage.
Les tâches à effectuer sont donc les suivantes :
- Exploration du sujet, préparation du guide d’entretien et réalisation de l’entretien (voir le guide Mener un entretien)
- Analyse de l’entretien, création des User Stories, du Product Backlog et définition des tâches
La conception fonctionnelle voire technique d’une fonctionnalité se fait au fil de l’eau dans chaque itération. Ce n’est qu’au moment où on s’apprête à l’implémenter qu’on rentre dans les détails du besoin (pour rappel, le besoin lié à cette fonctionnalité à été abordé dans les grandes lignes lors de la phase amont d’estimation). Cette approche a le mérite de permettre au client d’ajuster ou approfondir son besoin sur les fonctionnalités implémentées plus tard. Elle lui permet aussi (ainsi qu’à l’équipe) de retarder certaines décisions sans risque pour le projet (c’est souvent plus sage quand on manque de visibilité).
– – Florent Lothon, auteur du site L’Agiliste
Réunion de planification du sprint
Le Product Owner dont faire le bilan avec l’équipe sur la vision du produit, les dates de livraisons, l’objectif du sprint et le contenus du Product Backlog. Les exigences que l’équipe se sent capable de réaliser au cours du sprint devront être mises en haut du Product Backlog.
L’Équipe de développement fait ensuite l’inventaire des tâches qui seront à mener au cours du sprint, cela constitue le Sprint Backlog. L’effort de conception doit être suffisant pour mettre en cohérence toutes ces tâches qui sont ajoutées à un tableau des tâches comme un Kanban (voir photo ci-dessous).
Si certaines tâches s’avèrent irréalisables au cours du sprint, les membres de l’équipe doivent réajuster avec le Product Owner la liste des exigences à réaliser.
Réalisation du sprint
En début de sprint vous devrez produire :
- les spécifications fonctionnelles détaillées pour le sprint en cours, c’est à dire :
- la sélection des User Stories à implanter,
- les maquettes des tableaux de bord,
- les éléments de terminologie et de description nécessaire pour lever toutes les ambiguïtés.
- les spécifications techniques détaillées pour le sprint en cours, c’est à dire :
- les tables d’événements BEAM✲,
- les tables de dimension BEAM✲;
- la matrice d’événements BEAM✲,
- un schéma dimensionnel amélioré BEAM✲,
- une spécification de la phase d’ETL au moyen d’une logical datamap et de tous les algorithmes à implémenter.
- un cahier de tests avec pour quelques indicateurs pour un ensemble de valeurs de dimensions fixées, les valeurs exactes à retrouver.
Le suivi de la progression du sprint se fait au moyen d’un graphique d’avancement qui représente l’évolution de la quantité de travail restante par rapport au temps restant avant la fin du sprint.
– – Florent Lothon, auteur du site L’Agiliste
Quotidiennement une réunion d’une quinzaine de minutes maximum doit avoir lieu devant le tableau des tâches afin que chacun puisse faire le bilan :
- des tâches effectuées la veille,
- des tâches à effectuer aujourd’hui,
- des éventuelles difficultés qui pourraient empêcher l’atteinte des objectifs.
Le Scrum Master doit animer cette réunion pour permettre à tous les membres de l’équipe d’être en phase, mais les problèmes nécessitant du temps doivent être traités en dehors.
Rétrospective du sprint
https://paper.dropbox.com/doc/Initiation-Taiga-4tBSCWlvHIZ8sixWoaStQ
– – Florent Lothon, auteur du site L’Agiliste
Questions sur la gestion de projets décisionnels
A l’issu de votre travail de recherche bibliographique vous devrez être capable de répondre aux questions suivantes :
- Quelles tâches faut-il effectuer pour réaliser de bout en bout une fonctionnalité dans un projet décisionnel ?
- Qu’est-ce que l’approche Scrum ? Quel est son principe ? Quels rôles principaux sont identifiés ?
- Quelle sont les avantages/inconvénients d’une approche agile pour un projet Business Intelligence ?