Comment s’organise l’équipe projet ?
Le cadre de développement SCRUM est basé sur le principe des interactions fortes entre les personnes de l’équipe. Il existe deux rôles bien déterminés : Le Product Owner et le SrcrumMaster.
Quel est le rôle du Product Owner ?
- Création d’une release
- Définition de la vision du produit
- Identification des features
- Acceptation des stories
- Changement des priorités dans le backlog
- Déclaration d’une story finie
Quel est le rôle du ScrumMaster ?
- Activation des sprints
- Clôture des sprints finis
Les membres de l’équipe vont pouvoir créer les stories, estimer la charge de développement des stories et créer des tâches dans le plan de sprint.
Le rôle de chef de projet que vous connaissez bien est remis en cause.
Quels sont les rituels mise en œuvre au cours d’un projet ?
- La planification du sprint
- Le SCRUM quotidien
- La revue de sprint
- La rétrospective de sprint
Comment planifier le sprint ?
La planification du sprint s’appuie sur la planification de la release réalisée en amont.
La première réunion du sprint ne se limite pas à planifier. On y trouver les activités suivantes :
- Valider les stories du backlog pris en compte dans le sprint
- Concevoir collectivement les solutions
- Identifier et estimer les tâches
- Prendre des tâches par chacun des membres de l’équipe
- S’engager collectivement
Les tests font partie intégrante des sprints. Ils sont définis en même temps que les solutions aux stories. Les tests unitaires et d’acceptation permettent de statuer sur la notion de « FINI ».
« Il n’y a pas de story finie à 90% ou de story à moitié finie.»
La planification du sprint permet de répondre aux exigences de :
- Planification de la conception (ISO 9001)
- Eléments d’entrée de la conception et du développement (ISO 9001) : les stories
- Eléments de sortie de la conception (ISO 9001) : les tâches identifiées et estimées
- Vérification de la conception (ISO 9001)
Comment animer le sprint ?
Le SCRUM Quotidien permet à l’équipe de réactualiser les tâches à faire et d’ajouter de nouvelles tâches dans le sprint. Chaque statut est géré selon trois statuts : en cours, à faire, fini.
La méthodologie SCRUM ne s’intéresse pas du tout au temps passé. Il est inutile passer du temps à se justifier. L’objectif est de finir l’ensemble des tâches prévues dans le sprint afin de pouvoir présenter le résultat du développement au client.
Le SCRUM Quotidien dure un quart d’heure au maximum. Il mobilise toute l’équipe. Ceci correspond à un rituel identique à celui que l’on peut trouver dans le milieu industriel, à travers la réunion de production quotidienne.
Le SCRUM Quotidien va répondre aux exigences de revue de conception (ISO 9001).
Comment revoir le sprint ?
Cette étape se retrouve à la fin de chaque sprint. Elle permet de montrer les résultats du développement effectué au cours du sprint. Seule une version opérationnelle est montrée. Ceci correspond à des stories finalisées (notion de FINI).
Un retour (feedback) permet d’identifier les demandes d’évolution qui seront validées ultérieurement à travers de nouvelles stories. Ceci permet d’adapter le périmètre fonctionnel au cours du développement logiciel : gestion des modifications.
Les défauts éventuels y seront également identifiés. Ils seront corrigés par l’équipe elle-même lors du prochain sprint. Il n’y a pas de différentiation entre équipe projet et équipe maintenance !.
Le calcul de la vélocité du sprint est une métrique permettant d’améliorer la planification des futurs sprints : capacité de l’équipe à prendre en charge les stories.
Les stories non finies ne sont pas présentées au client. Elles sont automatiquement reportées au sprint suivant.
La vélocité est un élément de comparaison entre les différents sprints réalisés, basée uniquement sur des stories terminées.
La revue de sprint permet de répondre aux exigences de
- Validation de la conception (ISO 9001)
- Maîtrise des modifications de conception (ISO 9001) : identification
Comment s’améliorer après chaque sprint ?
La rétrospective fait suite à chaque revue de sprint. C’est la phase au cours de laquelle l’équipe va faire son retour d’expérience :
- Capitaliser les connes pratiques
- Partager afin d’éviter les mêmes erreurs dans le futur
- Echanger l’expérience vécue
Cette phase permet de mettre en œuvre l’amélioration continue. Les améliorations retenues seront traitées lors du prochain sprint. Les tâches nécessaires seront définies.
En conclusion
Pour des développements logiciels plus efficients, il faut radicalement modifier l’organisation du processus « Conception » :
- Un fonctionnement par équipe intégrant le représentant des clients et des utilisateurs : le Product Owner
- Des périodes fixes pour les sprints et les releases
- Des réunions de travail « ritualisées » : planification de sprint, SRUM quotidien, revue de sprint, rétrospective
- Des outils de travail : plan de release, plan de sprint, backlog, stories, tâches, reste à faire
Il s’agit de remettre en cause un certain nombre de nos pratiques actuelles :
- MOE / MOA : maîtrise d’ouvre et maîtrise d’ouvrage
- Rôle de chef de projet
- Diagramme de Gantt / Pert
- Mesure du temps consommé
- Gestion de la maintenance opérationnelle
- Contrat au forfait
Le dernier point concerne les indicateurs de surveillance et de mesure du processus « Conception ».
Les outils définis dans le cadre de la méthodologie SCRUM permettent, par consolidation, de piloter le processus « Conception » :
- Vélocité du sprint
- Suivi du backlog
- BurnUp de sprint en nombre de points
- Utilité cumulée sprint par sprint (idem release par release) en nombre de points
