Passer au contenu principal

Processus et méthodologies

BBC-Partners Solutions - Direction Innovation et Technologie

1. Méthodologie Agile Scrum

1.1 Principes adoptés

La DIT applique la méthodologie Agile Scrum pour l'ensemble de ses activités de développement.

Principe Application à la DIT
Livraisons itératives Sprints de 2 semaines
Collaboration continue Daily stand-up quotidien
Adaptation au changement Revue et ajustement à chaque sprint
Équipes auto-organisées Responsabilisation des pôles

1.2 Rôles Scrum

Rôle Titulaire Responsabilités
Product Owner Représentant DPS ou Directeur DIT Définit les priorités, valide les livrables
Scrum Master ALLOU Facilite les cérémonies, lève les obstacles
Équipe de développement Membres des pôles techniques Réalise les développements

1.3 Artefacts Scrum

Product Backlog

  • Liste ordonnée de toutes les fonctionnalités à développer
  • Géré par le Product Owner
  • Priorisé selon la valeur métier
  • Affiné régulièrement (Backlog Refinement)

Sprint Backlog

  • Ensemble des éléments sélectionnés pour le sprint en cours
  • Défini lors du Sprint Planning
  • Engagement de l'équipe pour le sprint

Increment

  • Livrable potentiellement déployable à la fin de chaque sprint
  • Répond à la Definition of Done
  • Démontré lors de la Sprint Review

1.4 Cérémonies Scrum

Daily Stand-up (Mêlée quotidienne)

Attribut Valeur
Fréquence Tous les jours ouvrés
Durée 15 minutes maximum
Participants Équipe de développement, Scrum Master
Horaire 9h00

Déroulement : Chaque membre répond à trois questions :

  1. Qu'ai-je fait hier ?
  2. Que vais-je faire aujourd'hui ?
  3. Ai-je des obstacles ?

Sprint Planning (Planification du sprint)

Attribut Valeur
Fréquence Premier jour du sprint
Durée 2 à 4 heures
Participants Product Owner, Scrum Master, Équipe

Déroulement :

  1. Le Product Owner présente les éléments prioritaires du backlog
  2. L'équipe estime et sélectionne les éléments réalisables
  3. L'équipe décompose les éléments en tâches
  4. L'objectif du sprint est défini

Sprint Review (Revue du sprint)

Attribut Valeur
Fréquence Dernier jour du sprint
Durée 1 à 2 heures
Participants Product Owner, Scrum Master, Équipe, parties prenantes

Déroulement :

  1. Démonstration des fonctionnalités réalisées
  2. Feedback des parties prenantes
  3. Mise à jour du Product Backlog si nécessaire
  4. Discussion sur les prochaines priorités

Sprint Retrospective (Rétrospective)

Attribut Valeur
Fréquence Après la Sprint Review
Durée 1 à 2 heures
Participants Scrum Master, Équipe de développement

Déroulement :

  1. Ce qui a bien fonctionné
  2. Ce qui peut être amélioré
  3. Actions d'amélioration pour le prochain sprint

Backlog Refinement (Affinage du backlog)

Attribut Valeur
Fréquence Hebdomadaire (milieu de sprint)
Durée 1 heure
Participants Product Owner, Scrum Master, Équipe

Déroulement :

  1. Clarification des éléments du backlog
  2. Estimation (Planning Poker)
  3. Découpage des éléments trop volumineux

2. Gestion des sprints

2.1 Paramètres du sprint

Paramètre Valeur
Durée du sprint 2 semaines
Jour de début Lundi
Jour de fin Vendredi (semaine 2)
Capacité nominale 8 jours/personne/sprint

2.2 Calendrier type d'un sprint

Semaine 1
─────────────────────────────────────────────────────────────
Lundi       │ Sprint Planning (matin) + Développement
Mardi       │ Daily + Développement
Mercredi    │ Daily + Développement + Backlog Refinement
Jeudi       │ Daily + Développement
Vendredi    │ Daily + Développement

Semaine 2
─────────────────────────────────────────────────────────────
Lundi       │ Daily + Développement
Mardi       │ Daily + Développement
Mercredi    │ Daily + Développement
Jeudi       │ Daily + Développement + Préparation démo
Vendredi    │ Daily + Sprint Review + Rétrospective

2.3 Definition of Ready (DoR)

Un élément du backlog est prêt à être pris en sprint si :

  • La user story est rédigée au format standard
  • Les critères d'acceptation sont définis
  • Les dépendances sont identifiées et résolues
  • L'estimation est réalisée par l'équipe
  • Les maquettes/spécifications sont disponibles (si applicable)

2.4 Definition of Done (DoD)

Un élément est considéré comme terminé si :

  • Le code est écrit et respecte les conventions
  • Le code est revu par un pair (code review)
  • Les tests unitaires sont écrits et passent
  • Les tests d'intégration passent (si applicable)
  • La documentation technique est à jour
  • Le déploiement en environnement de test est effectué
  • Les critères d'acceptation sont validés
  • Aucun bug bloquant n'est identifié

3. Processus de développement

3.1 Workflow Git

Branches principales

Branche Description Protection
main Code en production Protégée, merge via PR uniquement
develop Intégration continue Protégée, merge via PR uniquement

Branches de travail

Type Convention de nommage Exemple
Feature feature/[ticket]-description feature/MTX-123-ajout-filtre
Bugfix bugfix/[ticket]-description bugfix/MTX-456-correction-calcul
Hotfix hotfix/[ticket]-description hotfix/MTX-789-fix-urgent

Flux de travail

                    ┌─────────────────┐
                    │      main       │ (production)
                    └────────▲────────┘
                             │ merge (release)
                    ┌────────┴────────┐
                    │     develop     │ (intégration)
                    └────────▲────────┘
                             │ merge (PR validée)
         ┌───────────────────┼───────────────────┐
         │                   │                   │
┌────────┴────────┐ ┌────────┴────────┐ ┌────────┴────────┐
│ feature/MTX-123 │ │ feature/MTX-124 │ │ bugfix/MTX-125  │
└─────────────────┘ └─────────────────┘ └─────────────────┘

3.2 Processus de revue de code

Étapes

  1. Création de la Pull Request (PR)

    • Le développeur crée une PR depuis sa branche vers develop
    • Description claire des changements
    • Lien vers le ticket associé

  2. Revue par un pair

    • Un autre développeur examine le code
    • Vérifie le respect des conventions
    • Teste si nécessaire
    • Commente les points d'amélioration

  3. Corrections éventuelles

    • Le développeur traite les commentaires
    • Nouveaux commits sur la branche

  4. Validation et merge

    • Approbation du relecteur
    • Merge dans develop
    • Suppression de la branche de travail

Critères de revue

Critère Description
Fonctionnalité Le code répond au besoin exprimé
Lisibilité Le code est clair et compréhensible
Conventions Les standards de codage sont respectés
Tests Les tests sont présents et pertinents
Performance Pas de régression de performance évidente
Sécurité Pas de faille de sécurité introduite

4. Gestion des versions et releases

4.1 Versionnement sémantique

La DIT applique le Semantic Versioning (SemVer) : MAJOR.MINOR.PATCH

Composant Incrémentation si... Exemple
MAJOR Changements incompatibles (breaking changes) 1.0.0 → 2.0.0
MINOR Nouvelles fonctionnalités rétrocompatibles 1.0.0 → 1.1.0
PATCH Corrections de bugs rétrocompatibles 1.0.0 → 1.0.1

4.2 Processus de release

┌─────────────────┐
│ 1. Gel du code  │  Arrêt des merges sur develop
└────────┬────────┘
         │
┌────────▼────────┐
│ 2. Création     │  Branche release/vX.Y.Z depuis develop
│    branche      │
└────────┬────────┘
         │
┌────────▼────────┐
│ 3. Tests        │  Tests complets en environnement de staging
│    de recette   │
└────────┬────────┘
         │
┌────────▼────────┐
│ 4. Corrections  │  Bugfixes sur la branche release si nécessaire
│    éventuelles  │
└────────┬────────┘
         │
┌────────▼────────┐
│ 5. Merge et tag │  Merge dans main + tag vX.Y.Z
└────────┬────────┘
         │
┌────────▼────────┐
│ 6. Déploiement  │  Déploiement en production
│    production   │
└────────┬────────┘
         │
┌────────▼────────┐
│ 7. Merge retour │  Merge de la release dans develop
└─────────────────┘

4.3 Changelog

Chaque release est accompagnée d'un changelog documentant :

  • Nouvelles fonctionnalités
  • Améliorations
  • Corrections de bugs
  • Changements incompatibles (si applicable)

5. Gestion des incidents et bugs

5.1 Classification des bugs

Sévérité Description Délai de traitement
Critique Application inutilisable, perte de données Immédiat (hotfix)
Majeur Fonctionnalité importante indisponible Sprint en cours
Mineur Dysfonctionnement avec contournement possible Sprint suivant
Cosmétique Problème d'affichage sans impact fonctionnel Backlog

5.2 Processus de gestion des bugs

┌─────────────────┐
│  1. Détection   │  Signalement (utilisateur, test, monitoring)
└────────┬────────┘
         │
┌────────▼────────┐
│ 2. Qualification│  Reproduction, classification, priorité
└────────┬────────┘
         │
┌────────▼────────┐
│ 3. Assignation  │  Attribution au pôle/développeur concerné
└────────┬────────┘
         │
┌────────▼────────┐
│ 4. Correction   │  Analyse, correction, tests
└────────┬────────┘
         │
┌────────▼────────┐
│ 5. Validation   │  Revue de code, tests de non-régression
└────────┬────────┘
         │
┌────────▼────────┐
│ 6. Déploiement  │  Mise en production
└────────┬────────┘
         │
┌────────▼────────┐
│ 7. Clôture      │  Notification, documentation
└─────────────────┘

5.3 Processus de hotfix

Pour les bugs critiques nécessitant un déploiement immédiat :

  1. Création d'une branche hotfix/[ticket]-description depuis main
  2. Correction et tests
  3. Revue de code accélérée
  4. Merge dans main avec tag de version (patch)
  5. Déploiement en production
  6. Merge retour dans develop

6. Estimation des charges

6.1 Méthode d'estimation

La DIT utilise le Planning Poker avec des story points basés sur la suite de Fibonacci : 1, 2, 3, 5, 8, 13, 21.

Story Points Complexité Durée indicative
1 Très simple < 0.5 jour
2 Simple 0.5 - 1 jour
3 Modérée 1 - 2 jours
5 Significative 2 - 3 jours
8 Complexe 3 - 5 jours
13 Très complexe 5 - 8 jours
21 Épique (à découper) > 8 jours

6.2 Vélocité

La vélocité de l'équipe est mesurée en story points par sprint. Elle sert à :

  • Prévoir la capacité des sprints futurs
  • Identifier les tendances (amélioration ou dégradation)
  • Communiquer sur les délais prévisionnels

Documents connexes

Document maintenu par la DIT - BBC-Partners Solutions

Aucun commentaire à afficher

Retour en haut