Scrum Methode

doit aussi veiller à ce que les valeurs de Scrum soient appliquées.

L'équipe ne comporte pas de rôles prédéfinis, elle est auto-gérée. Il n'y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises ensemble et personne ne donne d'ordre à l'équipe sur sa façon de procéder.

L'équipe s'adresse directement au directeur de produit. Il est conseillé qu'elle lui montre le plus souvent possible le logiciel développé pour qu'il puisse ajuster les détails d'ergonomie et d'interface par exemple.

On parle parfois d'équipe étendue, qui intègre en plus le ScrumMaster et le directeur de produit. Ce concept renforce l'idée que client et fournisseur travaillent d'un commun effort vers le succès du projet.

Le fonctionnement de la méthode SCRUM

Le cycle de vie SCRUM

A partir des exigences du client, le directeur de produit avec L'équipe établirent une liste de fonctionnalités à implémenter, que l'on appelle backlog de produit. Les priorités sont définies par le Product Owner.

Scrum est un processus itératif : les itérations sont appelées des sprints et durent en théorie 2 à 4 semaines.

Au début de chaque sprint, des fonctionnalités sont ajoutées dans le backlog du sprint et qui devront être réalisées pendant ce sprint.

A la fin de chaque sprint, une version du produit, utilisable peu être fournie au client. Le produit est délivré en forme de plusieurs releases. Un release est une version du logiciel susceptible d'être mise en exploitation. Le release consiste en un ou plusieurs Sprints.

L’équipe prépare les taches nécessaires pour chaque sprint pendant un sprint dédier pour le planning qui s’appelle Sprint 0 pendant le quel on choisit quels items du backlog de produit seront réalisés dans ce sprint.

L'équipe décompose ensuite chaque item en liste de tâches élémentaires. Ensuite les membres de l’équipe commencent à estimer la durée en volume horaire de chaque tâche à l’aide de l’outil « Scrum planning poker ». Chaque tâche étant estimée en heures et ne devant pas durer plus de 16 heures (2jours de travails) pour constituer ainsi le backlog de sprint.

A la fin de chaque sprint, le « Burn Down Chart » est tracé permettant de suivre l’avancement du projet. Ce diagramme compare le temps réel de réalisation des tâches contre le temps idéal précisé lors du planning du départ. Un écart considérable entre les deux courbes nécessite une répartition des heures restantes sur les prochains sprints.