SQL Server chez les clients – BI & Agilité
L’adaptation au changement constitue aujourd’hui un facteur de compétivité décisif dans un environnement économique en perpétuelle évolution.
En effet, dans le monde du développement logiciel, la popularité des méthodes « Agiles » va croissant. Ces approches partagent les mêmes objectifs : améliorer la visibilité au sein de l’équipe de projet et l’interactivité entre les membres de l’équipe tout en augmentant le flux de valeur pour le client. Beaucoup de bonnes pratiques sont associées aux méthodes Agiles. Ces pratiques peuvent être adoptées progressivement et appliquées à presque n’importe quel projet ou type de processus, et nous vous proposons un retour d’expérience sur des projets décisionnels. L’objectif de ce billet est de partager la mise en œuvre sur le terrain de cette méthode.
Problématique
- Eviter l'effet tunnel, et réduire les délais de mise à disposition.
- S'adapter à une évolution du périmètre.
- Assurer une mise en adéquation entre les attentes et le livrable final.
Bénéfices
- Une solution en phase avec les attentes.
- Un planning maitrisé.
- De la souplesse dans la mise en œuvre.
L'analyse Post mortem des projets classiques
L’analyse post mortem des projets classiques, par exemple avec la méthode « Waterfall » ou encore avec l’approche « Cycle en V », remonte assez fréquemment les écueils ci-dessous :
- Un métier qui rencontre des difficultés pour formaliser les besoins
- Une longue phase de design et/ou une durée restreinte pour un code de qualité.
- Identifications des anomalies majeures tardives
- Incompréhension des développeurs
- Données de mauvaises qualités
- Evolution des besoins en cours de projet.
Les différentes étapes d'un projet agile dans la BI
Bien que l’objectif de ce document ne soit pas de présenter la méthode agile, et en particulier le Scrum, je vous propose de repositionner les principales étapes de ce type de projet. Nous verrons par la suite comment décliner cette approche sur des projets décisionnels, et comment le mettre en œuvre avec Visual Studio.
Scrum définit un jeu d'activités qui permet aux clients d'étudier, de guider et d'influencer le travail de l’équipe de développement au cours de sa progression. L’équipe travaille par courtes itérations (appelées aussi sprints) et affine son plan à mesure qu'elle avance dans son travail. Ces différents sprints ont une durée fixe, toujours identique, et fixée à l’ origine du projet.
L’approche traditionnelle dans le décisionnel, consiste à développer les différentes couches techniques du projet les unes après les autres. Par exemple en développant le module d’alimentation (ETL), l’entrepôt de données (datawarehouse), puis les modules d’analyse (un cube) et de reporting. L’ordre de développement des différentes strates est variable selon la méthodologie sélectionnée Top Down vs Bottom Up.
Figure 1 - Kimball DW/BI Lifecycle Methodology
Etape 1: Le backlog
Une étape incontournable : la création d’un backlog
Dans le cadre d’un projet Scrum, l’objectif est d’avoir une approche par fonctionnalité, puis de construire des fonctionnalités que des utilisateurs peuvent tester.
Ces choses à développer sont appelées stories en Scrum. Il s’agit de la liste des besoins exprimés par l’utilisateur. Cette liste est maintenue par le Product Owner. Avant un sprint, il est décidé de ce que l’équipe s’engage à réaliser.
L’équipe participe à ce choix pour :
- S’assurer que tous les membres ont bien compris l’ensemble des stories planifiées
- S’assurer que tous les membres sont d’accords sur le fait que la liste soit réalisable sur la durée d’un sprint
Au sein d'une équipe Scrum, le rôle de chef de projet et remplacé par celui de Scrum Master. Celui-ci n’est pas là pour diriger l’équipe, mais pour s’assurer que la méthode est appliquée comme il se doit. C’est l’animateur de l’équipe, le facilitateur qui permet de fluidifier l’avancement du travail.
Comment formaliser le backlog ?
Ces histoires doivent être :
- Des histoires claires et synthétiques
- Formaliser afin d'éviter de de donner lieu à de l’interprétation
Enfin ces histoires doivent répondre aux 3 questions :
- En tant que Utilisateur / Rôle ("Qui ?")
- Je souhaiterai avoir cette fonctionnalité ("Quoi ?"),
- Pour en avoir l'utilisation suivante. ("A quelle fin ?")
Voici quelques exemples d'histoires dans le cadre d’un projet BI :
« En tant que responsable marketing, je souhaite analyser mes ventes par catégorie de produit et par client, ainsi je pourrai connaitre mes principaux clients »
« En tant que gestionnaire d’application, je souhaite retrouver mes fichiers en anomalies dans le répertoire des rejets, je pourrai ainsi contacter les responsables de ces fichiers pour demander des correctifs »
« En tant que responsable de la qualité des données, je souhaite qu’un produit n’appartenant à aucune sous-catégorie soit rattaché à une sous-catégorie par défaut »
Au sein de l’équipe, le Product Owner (PO) est la personne qui fait le lien entre l’utilisateur final (i.e. la personne quiutilisera l’application) et l’équipe Scrum. Le Product Owner est là principalement pour :
- Récolter les besoins de l’utilisateur, les comprendre et les transcrire sous forme de stories
- Ordonner les stories en fonction de l’importance qu’elle représente pour l’utilisateur
Comment mettre en oeuvre le backlog avec Visual Studio ?
La création du backlog va permettre de lister l’ensemble des tâches et le travail à réaliser par l’ensemble de l’équipe. Visual Studio vous permet de couvrir non seulement ces besoins, mais aussi le suivi des tests d’acceptation, d’archivages et d’autres éléments de travail dont dépend chaque élément du backlog.
Une fois le projet crée dans Visual Studio, ouvrez le journal des travaux :
Vous pouvez ensuite ajouter de nouveaux éléments et ainsi constituer un backlog complet.
Pour ajouter un nouvel élément, de cliquer sur « New », puis sur « Add » pour l’ajouter au projet :
Pour plus de détail sur l’ensemble des opérations, n’hésitez pas à consulter la page web suivante :
https://www.visualstudio.com/get-started/create-your-backlog-vs
Etape 2 : Plannifier le Sprint
Le projet est constitué de plusieurs sprints, ou itérations. Le Product Owner doit définir quels sont les éléments qui doivent constituer la prochaine itération.
L’objectif de l’équipe est de vérifier dans un premier temps sa capacité à livrer le contenu de l’itération sur un unique sprint. En effet, l’équipe de développement va détailler les différentes phases de toutes les histoires retenues.
Imaginons que nous ayons l’histoire suivante:
« En tant que responsable de la segmentation client, je souhaite conserver l’historique du statut marital de mes clients, je pourrai ainsi identifier l’impact d’un changement de statut sur mes ventes.»
D’un point de vue de la modélisation BI, nous sommes face à un SCD de type 2. Cette demande est donc notre unité d’œuvre, l’équipe va donc devoir détailler l’ensemble des tâches relatives à cette mise en œuvre.
Il est essentiel que l’équipe arrive à un consensus sur le planning de livraison. L’objectif est de partager les risques, les difficultés et/ou le besoin de cette mise en œuvre. Il est important que le planning soit réaliste, car n’oublions pas que l’objectif est d’avoir une vision aussi juste que possible du projet.
Comment mettre en oeuvre le sprint avec Visual Studio ?
Avec Visual Studio, il est possible à tout moment d’afficher le contenu d’une itération :
Mais aussi, toutes les activités classiques relatives à la vie d’un projet, qu’il s’agisse de l’affectation des tâches, ou encore du suivi des différentes activités.
Etape 3 : Exécuter le sprint
Organisation de l'équipe
L’équipe va décider de l’affectation des tâches, et suivre l’ensemble des actions tout en partageant la même date butoir. L’objectif est de laisser le soin à l’équipe de créer ou d’adapter les outils en fonction des besoins.
Le « Daily Scrum », d’une durée comprise entre 10 et 15 minutes, a pour objectif de laisser toutes les personnes de l’équipe présenter le résultat de son travail. L’objectif est de faire le point non seulement sur les actions terminées, mais aussi sur celles qui sont en cours de réalisation, tout en partageant les difficultés rencontrées.
Comme indiqué précédemment, nous travaillons avec une approche fonctionnelle, et non pas par strate technologique. Par conséquent, la synchronisation entre les équipes est essentielle. Enfin, le partage des problèmes, bugs ou autres anomalies est aussi l’occasion d’échanger sur les pistes et solutions pertinentes. D’ailleurs les bugs sont à corriger dans le cadre du sprint.
Etape 4 : Le besoin de feedback
Feedback de produit
Lors de la revue de sprint, le moment où le Product Owner démontre les différentes stories, il est important qu’il récolte le plus de retours possibles. Ceci permet de s’assurer d’avoir une version correspondant toujours à ce dont l’utilisateur a besoin. Si un feedback intéressant est proposé pendant la réunion, il est possible d’ajouter un élément de travail de type Feedback et de l’associer à l’élément du backlog correspondant.
Feedback client
Le terme « agile », dans la méthode de développement du même nom, décrit une certaine souplesse et une réactivité plus élevée que dans une méthode plus classique. Etre réactif, cela nécessite d'avoir la possibilité de comprendre ce que l’utilisateur final de l’application souhaite. Cela passe évidemment par le backlog et le détail des différents scénarios d’utilisation, mais également par les retours que font les utilisateurs clés.
Les principaux retours que nous recevons à ce moment du projet, en particulier lors des démonstrations, sont le plus souvent :
- Afficher le libellé de l’attribut et non pas son code (ou vice versa)
- Modifier le typage des mesures
- Adapter la charte graphique d’un rapport Reporting Services
Globalement il s’agit d’ajustement, et non pas d’une remise en cause du produit. C’est d’ailleurs l’une des raisons qui nécessite la participation du métier aux différentes phases du projet.
Synthèse
Ce billet qui illustre comment la méthode agile peut être appliquée sur un projet décisionnel, met également l'accent sur le fait qu'une présence fonctionnelle forte est nécessaire, conjuguée à une certaine souplesse de la part de l'équipe de réalisation.
L'une des specificités de cette méthode étant que l'expression de besoin se fasse lors des différentes discussions avec les acteurs du projet.
Pour une approche complète et détaillée de l’approche Scrum en s’appuyant sur Visual Studio, je vous invite à lire le livre blanc de Stéphane Goudeau, Vivien Fabing et Etienne Margraff : Une bonne dose d'agilité au cœur de votre équipe. La recette Visual Studio 2012 pour des projets maitrisés : https://download.microsoft.com/documents/France/visual_studio/2012/Livre_Blanc_Agilite_350x240_BD.pdf.
Pour plus d’informations sur les offres packagées Microsoft Consulting Services, rendez-vous sur https://www.microsoft.com/france/services
Plus d’informations sur les blogs « SQL Server chez les clients ».
Comments
- Anonymous
April 30, 2014
Trés bon article, on sent une vrai expertise du mode agile.
Merci à l'auteur.