i

Description

Une mêlée de rugby sur un terrain brumeux, vue d'ensemble

Source

auteur non indiqué · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Scrum appliqué à la data, à la BI et au datamart

Vous saurez adapter Scrum à un projet data / BI / datamart : écrire des stories de données, planifier des spikes d'exploration, définir un Incrément sur une chaîne source → ETL → modèle →…

En bref

• Vous saurez adapter Scrum à un projet data / BI / datamart : écrire des stories de données, planifier des spikes d'exploration, définir un Incrément sur une chaîne source → ETL → modèle → rapport.
• Vous saurez bâtir une Definition of Done data (qualité, recette sur chiffres, performance, sécurité, documentation, rejouabilité).
• Vous saurez équilibrer sprints de données et sprints de visualisation, gérer la dette de données, la dépendance aux sources et les jeux de données de test.
• Vous saurez cadrer le rôle du Product Owner data et organiser la recette métier sur les chiffres.
• Vous aurez un tableau forces/faiblesses et des notes /5 d'adéquation de Scrum à la data, avec une section IA.

Fil rouge illustratif (anonyme). Un datamart SQL Server alimenté par une application de force de vente (SFA) terrain, avec des rapports Power BI multilingues, versionné en TFVC et livré en kits d'installation. Les chiffres donnés sont des ordres de grandeur illustratifs.

Sur cette page

1. 🟢 Novice — Pourquoi Scrum et la data se frottent
2. 🟢 Novice — Qu'est-ce qu'un Incrément en BI ?
   1. Incréments de niveaux différents
3. 🟢 Novice — L'équipe data pluridisciplinaire
4. 🟡 Pratique — Écrire des stories de données
   1. Modèle de story data
   2. Cinq types de stories data
   3. La story « technique » en BI : quand est-ce légitime ?
5. 🟡 Pratique — Spikes d'exploration de données
   1. Spikes typiques en data
   2. Règles d'un bon spike
6. 🟡 Pratique — Un Sprint sur la chaîne source → ETL → modèle → rapport
   1. Le défi du découpage
   2. Un Sprint type de deux semaines
   3. Traitements longs et boucle de retour
7. 🟡 Pratique — Sprints de données ou sprints de visualisation ?
   1. Quand séparer se justifie
8. 🟡 Pratique — La Definition of Done data
9. 🟡 Pratique — Jeux de données de test
   1. Règles
10. 🟡 Pratique — Dépendance aux sources
    1. Traiter la dépendance comme un item
    2. Contrats de données
11. 🟡 Pratique — Le Product Owner data
    1. Où trouver ce PO ?
12. 🟡 Pratique — Recette métier sur les chiffres
    1. Les cinq niveaux de contrôle
    2. Déroulé
13. 🔴 Expert — Dette de données
    1. Gérer la dette dans Scrum
14. 🔴 Expert — Rejouabilité, idempotence et historisation dans le Sprint
    1. Idempotence
    2. Historisation
    3. Planifier le « rejouable » dans Scrum
15. 🔴 Expert — Migrations, versions de modèle et kits
    1. Version produit contre Sprint
16. 🔴 Expert — Coordination DataOps et gouvernance
17. 🔴 Expert — Quand Scrum est-il le mauvais choix pour la data ?
18. Forces et faiblesses
19. Métriques : notes /5 d'adéquation
    1. Adéquation par type de travail data
20. Contribution de l'IA
21. Voir aussi

Niveau : 🟢→🔴

🟢 Novice — Pourquoi Scrum et la data se frottent#

Scrum est né du développement logiciel, où l'on peut livrer un petit incrément fonctionnel en deux semaines : une fonction, un écran. La data a trois différences qui créent des frottements (voir Fondamentaux : spécificités data) :

Ces frottements ne rendent pas Scrum inapplicable. Ils obligent à adapter le découpage, la DoD, la planification et le rôle du PO — c'est l'objet de ce fichier. Les alternatives et compléments (CRISP-DM, DataOps, Kimball pour la modélisation) sont dans Méthodes spécifiques à la data ; le comparatif global dans Comparatif des méthodes.

🟢 Novice — Qu'est-ce qu'un Incrément en BI ?#

Le Guide exige un Incrément utilisable (Scrum, le cadre). En BI, « utilisable » veut dire : un utilisateur peut prendre une décision à partir d'un chiffre fiable. Cela impose une tranche verticale minimale à travers toute la chaîne.

Incréments de niveaux différents#

🟢 Novice — L'équipe data pluridisciplinaire#

Une équipe BI autonome sur la chaîne complète réunit les compétences suivantes (une même personne peut en porter plusieurs) :

Scrum parle de Developers au sens large : ceux-ci incluent donc les ingénieurs data et les développeurs BI. Quand une compétence n'existe que hors de l'équipe (DBA central, équipe sécurité, propriétaire de la source), chaque item qui en dépend crée un goulot : c'est un facteur de risque à traiter explicitement (accords de service, créneaux réservés, membre « de liaison »), ou une raison d'élargir l'équipe.

🟡 Pratique — Écrire des stories de données#

Les user stories (Scrum en pratique) s'appliquent, avec une adaptation : le « je veux… » est souvent une capacité de décision, et le « afin de… » porte la valeur. Il faut ajouter des éléments propres à la donnée.

Modèle de story data#

Cinq types de stories data#

La story « technique » en BI : quand est-ce légitime ?#

Le Scrum pur évite les stories sans valeur. En BI, certains travaux sont prérequis et indivisibles (créer une dimension partagée). Règle de bon sens :

1. Tirer le travail technique par une story consommateur (« voir le CA par client » tire la dimension client).
2. Si le travail sert plusieurs stories futures (dimension commune, calendrier), le porter explicitement avec une justification (« prérequis de 4 stories du Q2 ») et le limiter au strict nécessaire.
3. Ne pas laisser la part de stories techniques grimper sans en discuter en rétro (aucun seuil universel : l'équipe fixe le sien et le recalibre).

🟡 Pratique — Spikes d'exploration de données#

Un spike est un travail de recherche timeboxé dont le livrable est de la connaissance (une décision, une estimation, une preuve de faisabilité), non du code de production. C'est l'outil privilégié contre l'incertitude des données.

Spikes typiques en data#

Règles d'un bon spike#

• Question explicite, au départ ; critère de sortie (« nous saurons dire si… »).
• Timebox stricte (heures ou jours) ; si non conclu, l'incertitude restante est elle-même le résultat.
• Livrable écrit (une page : question, méthode, constat, décision recommandée) archivé près du backlog.
• Code jetable par défaut : si le spike a produit du bon code, on le reconstruit avec la DoD.

-- Spike : profil d'un champ candidat (exemple générique)
SELECT
    COUNT(*)                                             AS nb_lignes,
    SUM(CASE WHEN segment IS NULL OR segment = '' THEN 1 ELSE 0 END) AS nb_vides,
    COUNT(DISTINCT segment)                              AS nb_valeurs,
    CAST(100.0 * SUM(CASE WHEN segment IS NULL OR segment = '' THEN 1 ELSE 0 END)
         / NULLIF(COUNT(*), 0) AS DECIMAL(5,2))          AS pct_vides
FROM stg.client;

-- Unicité de la clé annoncée
SELECT code_client, COUNT(*) AS nb
FROM stg.client
GROUP BY code_client
HAVING COUNT(*) > 1;

🟡 Pratique — Un Sprint sur la chaîne source → ETL → modèle → rapport#

Le défi du découpage#

Découper verticalement en BI est difficile car les couches sont interdépendantes : pas de rapport sans mesure, pas de mesure sans modèle, pas de modèle sans données. La solution est de réduire la dimension de chaque tranche, pas la profondeur : peu de données, peu de mesures, une page — mais toute la chaîne.

Un Sprint type de deux semaines#

Chaque jour combine une brique et son test, jamais « tout construire puis tout tester ». Les tests de chiffres sont écrits avec ou avant la brique (esprit TDD appliqué à la donnée), comme décrit dans Tests et fiabilité des chiffres.

Traitements longs et boucle de retour#

Quand une consolidation ou un rechargement complet dure des heures, la boucle « modifier → tester » s'allonge. Parades :

Ces points sont détaillés côté livraison dans CI/CD pour la data. Pour la cadence de Sprint : si le cycle de test complet dure plus d'un jour, le Sprint de deux semaines est un minimum raisonnable ; une semaine devient irréaliste sauf si le chargement partiel est maîtrisé.

🟡 Pratique — Sprints de données ou sprints de visualisation ?#

Une tentation répandue consiste à séparer les Sprints : d'abord des « sprints de données » (préparer toutes les données), puis des « sprints de visualisation » (faire les rapports). C'est le mini-cascade dans lequel la valeur n'arrive qu'à la fin et où le métier découvre tard que le chiffre n'est pas celui qu'il attendait.

Quand séparer se justifie#

• Fondations lourdes réellement indivisibles (ex. migration de plateforme), à borner et à relier à un jalon utilisateur.
• Spécialités rares réparties entre équipes : alors, synchroniser les Sprints et partager un backlog.
• Phase d'exploration visuelle (UX) distincte, en amont, avec prototypes sur données factices, à condition de valider ensuite sur données réelles.

La séparation modèle sémantique / rapports a, elle, un vrai intérêt technique : plusieurs rapports consomment un même modèle. Dans ce cas, le modèle est un produit avec son propre backlog et son propre versionnement (voir Modèle sémantique et Versionnement et industrialisation des rapports).

🟡 Pratique — La Definition of Done data#

La DoD fait la qualité d'un projet BI. Elle doit couvrir bien plus que « le rapport s'affiche ». Gabarit à adapter (chaque ligne est binaire) :

-- Réconciliation du CA mensuel entre la source et la table de faits (échantillon : région pilote)
WITH src AS (
    SELECT EOMONTH(f.date_facture) AS mois, SUM(f.montant_ht) AS ca
    FROM   src.facture AS f
    JOIN   src.client  AS c ON c.code_client = f.code_client
    WHERE  c.region = 'PILOTE'
    GROUP  BY EOMONTH(f.date_facture)
), dwh AS (
    SELECT d.fin_de_mois AS mois, SUM(v.ca_ht) AS ca
    FROM   dwh.fact_ventes AS v
    JOIN   dwh.dim_date    AS d ON d.id_date = v.id_date
    JOIN   dwh.dim_client  AS c ON c.id_client = v.id_client
    WHERE  c.region = 'PILOTE'
    GROUP  BY d.fin_de_mois
)
SELECT COALESCE(s.mois, w.mois) AS mois,
       s.ca AS ca_source, w.ca AS ca_dwh,
       COALESCE(w.ca,0) - COALESCE(s.ca,0) AS ecart
FROM   src s FULL OUTER JOIN dwh w ON w.mois = s.mois
WHERE  COALESCE(w.ca,0) <> COALESCE(s.ca,0);   -- attendu : 0 ligne

Les thèmes correspondants dans les matrices : Qualité des données, Recette et validation métier, Sécurité, confidentialité, conformité, Métadonnées, lignage, documentation, Sécurité RLS et accès.

🟡 Pratique — Jeux de données de test#

Sans données de test représentatives et stables, on ne peut ni tester, ni itérer vite, ni reproduire un défaut. Stratégie par niveau :

Règles#

1. Jeu de référence versionné avec ses valeurs attendues (le CA du client X en mars vaut Y) ; ces valeurs sont le test de non-régression des chiffres.
2. Anonymisation / pseudonymisation avant tout usage hors production ; ne pas déplacer de données personnelles vers un environnement de test sans base légale et contrôle d'accès.
3. Cas limites documentés et couverts : client fusionné, avoir, devise, fuseau horaire, langue, valeur extrême, historique tronqué.
4. Environnements dédiés : une recette ne se fait pas sur un environnement qui bouge sous les pieds.
5. Évolution : quand la source change, le jeu de référence est rafraîchi consciemment, avec diff visible et validation.

🟡 Pratique — Dépendance aux sources#

La source (ici, l'application SFA) est un tiers : son schéma, sa qualité et son calendrier ne dépendent pas de l'équipe. Les conséquences pour Scrum :

Traiter la dépendance comme un item#

Une dépendance n'est pas « ce qui bloque un item » : c'est un item de backlog qui a son propre cycle et que l'on ordonne (« obtenir l'accès » doit être prêt avant que les items qui en dépendent soient sélectionnés). Cartographier : source, propriétaire, mode d'accès, fréquence de changement, contact, SLA.

Contrats de données#

Formaliser avec le propriétaire de la source un contrat : schéma garanti, sémantique des champs, fraîcheur, qualité attendue, procédure de changement (préavis), versions. Même léger (une page + des tests automatisés), il transforme une relation de dépendance en relation gérée. Détail : Sources et contrats de données.

🟡 Pratique — Le Product Owner data#

Le PO data a les responsabilités du PO (Scrum, le cadre), avec des exigences supplémentaires. C'est généralement la personne la plus difficile à trouver, car il faut un profil rare : proche du métier, à l'aise avec les chiffres, capable d'arbitrer des définitions.

Où trouver ce PO ?#

🟡 Pratique — Recette métier sur les chiffres#

La recette d'un rapport BI n'est pas une vérification d'écran : c'est la vérification que les chiffres sont justes et compris.

Les cinq niveaux de contrôle#

Déroulé#

1. Préparer : jeu de référence figé ; périmètre ; attendu (source de vérité nommée : le système source, un état comptable, un Excel validé).
2. Exécuter les contrôles automatisés (SQL de réconciliation) ; consigner les écarts.
3. Expliquer chaque écart : bug, règle différente, donnée sale, différence de calendrier (date de facture contre date d'expédition), arrondi, fuseau horaire.
4. Trancher avec le PO : corriger, accepter (avec trace), ou documenter une différence assumée (« notre CA exclut les avoirs de type X »).
5. Signer : fiche de recette (date, périmètre, version, résultats, réserves, signataire). Cela protège l'équipe et crée la confiance.

La recette est un événement du Sprint de fait, même si le Guide n'en prévoit pas : intégrez-la dans la DoD, planifiez-la dans le Sprint (jours 8–9 dans l'exemple ci-dessus) et ne la repoussez pas à un « Sprint de recette » final. Les matrices traitent ce point dans Recette et validation métier et Qualité et recette.

🔴 Expert — Dette de données#

La dette technique (Ward Cunningham) désigne les raccourcis de conception qui accélèrent aujourd'hui et ralentissent demain. En data, une forme voisine, la dette de données, mérite son propre suivi.

Gérer la dette dans Scrum#

1. La rendre visible : items « dette » dans le Product Backlog, étiquetés, avec coût d'attente (ce que ça nous coûte chaque mois).
2. Réserver une capacité (une part fixe du Sprint, à calibrer selon l'ampleur de la dette ; il n'existe pas de norme établie) ; ne pas dépendre d'un hypothétique « Sprint de nettoyage ».
3. Dette consentie : un compromis volontaire et daté (« on accepte un import complet pour le MVP, remboursement prévu au Sprint N ») vaut mieux qu'une dette cachée. Le PO signe.
4. Règle de non-aggravation : toute modification d'une zone fragile améliore au moins un point (règle du boy-scout).
5. Rembourser en priorité la dette qui bloque un objectif prioritaire.
6. Mesurer : ancienneté, nombre d'items, temps passé en contournement.

Voir le thème des matrices Dette technique et maintenabilité.

🔴 Expert — Rejouabilité, idempotence et historisation dans le Sprint#

Ces propriétés ne se « testent » pas à la recette : elles se conçoivent, donc se planifient comme exigences dans le Sprint.

Idempotence#

Un traitement est idempotent si l'exécuter plusieurs fois avec les mêmes entrées produit le même état final qu'une seule exécution. C'est la condition d'un chargement rejouable après incident, et de la sérénité en production.

-- Chargement idempotent d'une dimension : MERGE sur clé naturelle
MERGE dwh.dim_client AS cible
USING stg.client_propre AS source
   ON cible.code_client = source.code_client
WHEN MATCHED AND (cible.libelle <> source.libelle OR cible.region <> source.region) THEN
     UPDATE SET libelle = source.libelle, region = source.region, date_maj = SYSUTCDATETIME()
WHEN NOT MATCHED BY TARGET THEN
     INSERT (code_client, libelle, region, date_maj)
     VALUES (source.code_client, source.libelle, source.region, SYSUTCDATETIME());
-- Rejouer deux fois : mêmes lignes, pas de doublon.

Pour une table de faits : pattern « supprimer la fenêtre puis réinsérer » (par période) dans une même transaction, ou swap de partition, plutôt que « ajouter sans condition ».

Historisation#

Les attributs qui changent (région d'un client) posent la question du type de dimension (SCD type 1 : écraser ; type 2 : versionner). Choisir tôt, car le changement tardif est coûteux. Le test de la DoD doit vérifier le comportement attendu face à un changement (jeu avec deux versions du même client).

Planifier le « rejouable » dans Scrum#

• Critère d'acceptation systématique : « un double chargement ne modifie pas le résultat ».
• Story de reprise : « après un échec à mi-chargement, la reprise ne laisse pas de données partielles ».
• Jeu d'essai avec événements de retard de données (données arrivant après la période).
• Journalisation du lot (identifiant, heure, nombre de lignes) pour le diagnostic.

🔴 Expert — Migrations, versions de modèle et kits#

Un datamart livré à plusieurs clients, en versions successives, est un produit : chaque nouvelle version doit pouvoir s'installer sur une base neuve et migrer une base existante sans perte de données. Scrum le permet à condition de traiter ces aspects comme des exigences de l'Incrément, non comme du « post-traitement ».

Version produit contre Sprint#

Un Sprint produit des Incréments internes ; une version du produit (kit) regroupe plusieurs Sprints et passe par une DoD de livraison plus lourde. Ne pas confondre ni rythmer la version sur le Sprint. Pour la gouvernance de version et la livraison, voir CI/CD pour la data, Choisir et hybrider et, côté outils, Stratégies de branches et GDS et données SQL/BI.

🔴 Expert — Coordination DataOps et gouvernance#

Scrum répond à « comment organiser le travail d'équipe ». Il ne couvre pas, seul :

Les points de rencontre :

• Gouvernance ↔ DoD : les exigences de gouvernance (classification, rétention, accès) deviennent des critères de DoD.
• DataOps ↔ Sprint : plus les contrôles sont automatisés, plus la DoD est peu coûteuse et le Sprint court.
• Architecture ↔ Product Backlog : les décisions d'architecture (choix de plateforme) sont des items explicites, parfois des spikes, avec un propriétaire.

🔴 Expert — Quand Scrum est-il le mauvais choix pour la data ?#

Cette typologie se prolonge dans Choisir et hybrider et Comparatif des méthodes.

Forces et faiblesses#

Métriques : notes /5 d'adéquation#

Appréciations d'expert, contextuelles (voir Notation). Contexte : équipe de 4 à 8 personnes sur un datamart d'entreprise évolutif (source applicative, rapports Power BI), livraisons par versions. À recalibrer pour un projet data science ou une équipe d'une personne.

Adéquation par type de travail data#

Ces notes sont des repères de discussion, pas des mesures : elles reflètent l'avis d'un praticien sur un contexte type et ne remplacent pas votre propre auto-évaluation (matrice conduite projet data).

Contribution de l'IA#

Exemples de prompts :

• « Voici le schéma de ma table de faits et de ma dimension client (sans données). Écris des requêtes T-SQL de contrôle : unicité de la clé, orphelins de clé étrangère, valeurs négatives, dates hors plage. Explique chaque contrôle. »
• « Voici trois critères d'acceptation. Propose pour chacun un test de réconciliation SQL et un cas limite que je n'ai pas prévu. »

Ce que l'IA ne remplace pas : la définition de la valeur et des règles de gestion (PO), la recette métier signée, la responsabilité des chiffres, la décision sur la dette consentie, la gouvernance des accès. Risques propres à la data : requêtes syntaxiquement correctes mais sémantiquement fausses (mauvaise jointure qui multiplie des lignes, filtre perdu) donnant un chiffre plausible ; fuite de données si l'on colle des données réelles dans un service non autorisé ; dette cachée de code généré non compris par l'équipe. Règle : tout test généré par l'IA est lui-même testé (sur un cas dont on connaît le résultat). Voir IA et conduite de projet et IA et outils.

Voir aussi#

• Cadre et pratique : Scrum, le cadre, Scrum en pratique, Fondamentaux.
• Méthodes dédiées et comparaison : Méthodes spécifiques à la data, Agiles et Lean, Comparatif, Choisir et hybrider.
• Livraison : CI/CD, CI/CD pour la data, Pièges et bonnes pratiques.
• Outils : GDS et données SQL/BI, Azure DevOps / TFS, Métriques et reporting.
• Matrices : Conduite de projet data, Délais et industrialisation DataOps, Développement BI.
• Reporting Power BI : Bonnes pratiques Power BI transverses, Checklist de projet reporting.
• Glossaire : Glossaire.

✻ Rédigé par Claude Sonnet 5.5