Méthodologie Agile/Scrum - Partie 3

Dans le précédent article, nous avons introduit la méthologie Scrum. Dans cette troisème et dernière partie, nous allons détailler  les rôles et les activités Scrum ainsi que les documents utilisés dans cette démarche de gestion de projets.

Commençons par les rôles Scrum : "Product Owner", "Scrum Master" et "Scrum Team Member".

1) les Rôles SCRUM

Rôle Product Owner

Il est le responsable, chez le client, pour fournir un produit réussi en termes de :

• Vision
• Priorités
• Image de marque minimum
• Ensemble des Fonctionnalités
• Dates des livraisons des incréments
• Retour sur Investissement
• Coût

Dans la méthodologie Scrum le Product Owner,

• détermine la feuille de route de développement (planning global)
• fixe les priorités du produit
• maintient un minimum de spécifications pour chaque fonctionnalité, par anticipation sur le prochain sprint (itération). C'est lui qui maintient le Product Backlog.
• est ouvert à la négociation qu'il peut y avoir avec l'équipe de développement
• est orienté métier.
• il valide la définition du "Done" (Terminé).
• ce rôle peut être rempli par le "Directeur de Produit", le "Directeur Marketing", le "Chef de Projet Client" ou le "Vrai Client".
• a accès aux dirigents de l'entreprise pour l'aider à
• définir la feuille de route
•   définir les priorités
•   avoir le feedback et l'acceptation

Le Product Owner est le véritable capitaine à bord du navire du projet. Il est responsable de le mener à bon port, à temps et par le meilleur chemin.

Rôle du Scrum Master

• Affecation des tâches
• Suivre l'état d'avancement
• Gestion des risques : garde un oeil sur le diagramme "burn chart". Explique tout écart, évalue l'impact sur le projet, etc.
• Applanit les difficultés que l'équipe rencontre
• Détecte les conflits entre membres de l'équipe et les résout
• Garde un oeil sur l'état d'avancement des tâches : combien de temps reste-il, y a-t-il des surprises, de nouvelles compréhensions du domaine à partager

L'Equipe projet Scrum

• L'équipe est colocataire du même local , voire tous les membres sont assis autour de la même table.
• L'effectif optimum est 7.
• Elle est pluridisciplinaire comprent un DBA, un architecture, des développeurs, etc.
• Elle est auto-gérée et prend les décisions collectivement. Chacun connaît là où il est bon et chacun sait à qui s'adresser pour un problème particulier. Il n'y a pas de leadership. Chacun peut conduire toute l'équipe le bon moment.
• Elle est responsable collectivement de la livraison en fin de Sprint. Si un membre ne remplit pas ses devoirs, toute l'équipe est responsable.
• Tous les membres collaborent pour résoudre les problèmes collectivement et avancer dans le projet.
• Les membres travaillent ensemble mais s'amusent ensemble également.

2) Les activités Scrum

Release Planning

Le Release Planning est en fait la planification globale  du projet où l'on planifit l'ensemble des sprints du projet.

 

Source : scrumusergroup.ca

Sprint Planning

A l'intérieur d'un sprint (itération), les "user stories" à réaliser (issues du product backlog) sont planifiées dans le temps/ C'est le Sprint Planning :

Source : scrumusergroup.ca

Les "User Stories" sont également groupées en trois colonnes, au fur et à mesure de l'avancement : "Sprint backlog", "En cours" et "Terminé".

Cas particulier : Sprint 0

Ce premier Sprint est un peu particulier. Il englobe les activités suivantes :

• Si nécessaire, former l'équiepe sur les valeurs et pratiques Agile, le processus Scrum, les rôles, les activités et les documents.
• Définition du "Terminé"
• Commencer le travail avec le tableau des tâches et démarrage des scrums quotidiens (réunions quotidienne)
• Préparer le Product Backlog avec le Product Owner.
• Réunion d'estimation
• Planifier le premier Sprint.

Exemple de tableau des tâches

La notion de "Done"/"Terminé" est importante. Voici un exemple de définition de "Terminé" :

• Le code modifié est documenté (inline, javadoc)
• Le code modifié est testé unitairement (Junit)
• L'utilitaire "FindBugs" ne détecte pas de problèmes sévères.
• Le build local réussit
• Les changements ont été mis dans le référentiel de code source (SVN, etc.)
• Le build continu (Hudson CI) est réussi
• le build a été déployé en environnement d'intégration
• Tests Slenium exécuté pour une application Demo
• La qualité a été vérifié par un membre de l'équipe

Réunion de Planification

Celle-ci, d'une durée globale de 4 heures, en général, est divisée en deux sessions de 2 heures, généralement tenues le vendredi avant le démarrage du Sprint. Cette réunion est annimée par le Scrum Master et se déroule de la manière suivante :

Session 1 :

• Engagement global sur les User Stories à réaliser durant le Sprint
• Estimation de la charge, par exemple avec le planning Poker (voire plus loin)
• Tenir compte des priorités définies par le Product Owner.

Session 2 :

• Diviser chaque User Story en tâches (les petits stickers collés sur le tableau des tâches).
• Fixer la ligne rouge du prochain sprint et finaliser l'engagement de l'équipe.
• Affectation des tâches aux membres de l'équipe par volontariat. Chacun dit "moi je prendrai cette tâche ou celle-là"
• Toute tâche restant non affectée doit être affectée par l'équipe.
• Créer le "Radiateur d'Information", la salle de travail de l'équipe devient le tableau de bord pour chacun.

Estimation des user Stories

Généralement, les User Stories que le Product Owner met dans le Product Backlog se voient affectées par l'équipe Scrum des "Points de User Story" correspondant à la charge estimée de réalisation. Si une tâche élémentaire se voit affecter un point, une tâche jugée nécessitant le double du temps pour la réaliser
aura 2 comme points. Au lieu des points, on peut également directement utiliser les heures ou les jours.

Les estimations ne sont pas la responsabilité d'une personne en particulier. Toute l'équipe Scrum s'engage dans les estimations. Il est important de chercher le consensus de toute l'équipe sur les estimations. On peut comparer une tâche à une autre déjà réalisée pour effectuer des estimations. Quant au consensus
de l'équipe, une méthode permettant de l'obtenir est la méthode dite de "Poker Planning", que l'on peut ainsi décrire :

• Chacun note, seul et indépendamment des autres, sur un bout de papier l'estimation qu'il juge bonne pour réaliser la tâche.
• Chacun révèle à tous les autres son estimation.
• Celui ayant l'estimation la plus basse ou la plus haute doit défendre son point de vue.
• Chacun réajuste alors son estimation et on refait un tour jusqu'au consensus.

On peut également utiliser la technique suivante (des 5 doigts) :

• une estimation est déterminée d'une manière ou d'une autre
• chacun doit voter sur cette estimation avec un nombre de 1 à 5 : 1 pour totalement en désaccord et 5 pour entièrement d'accord.
• ceux qui sont en total désaccord ou entièrement d'accord doivent défendre leur point de vue.
• on ajuste la valeur on refait un vote et ainsi de suite jusqu'à ce qu'on arrive à ce que chacun affiche au moins la valeur 3.

Notion de Vélocité

La vélocité est le nombre de Points de User Story que l'équipe peut réaliser en un Sprint. Si les points de user story sont simplement les heures ou les jours de travail, alors la vélocité correspond simplement aux heures effectives de travail de l'équipe lors d'un Sprint. Si on utilise des points autres que les heures, la vélocité est inconnue pour une nouvelle équipe, un nouveau projet ou à chaque fois qu'un membre rejoint ou quitte l'équipe. Dans ce cas, on doit l'estimer.

Attention, pour mesuser la vélocité effective réalisée par l'équipe, on ne doit tenir compte que des User Stories réellement terminées et non partiellement
terminées. Elles doivent vérifier le critère "Done"/"Terminé" pour être comptées dans la vélocité.

Réunion Scrum quotidienne

Animée par le Scrum Master, elle ne doit pas durer plus de 10 à 15 minutes et se résume aux questions suivantes adressées à chaque membre de l'équipe :

• quel est le travail réalisé hier ?
• qu'est-ce qui est prévu dea réaliser ujourd'hui ?
• y a-t-il des empêchements quelconques ?

Et le travail commence pour toute l'équipe dans la salle commune.

Réunions de revue du Sprint

Animées par le Scrum Master et à laquelle assiste le Product Owner, ces réunions ont lieu à la fin de chaque Sprint. L'équipe effectue une démonstration, de toutes les User Stories réalisées, au Product Owner pour validation. Toutes les User Stories ayant échoué reviennent au Product Backlog.

Réunion de rétrospective

Animée par le Scrum Master, on écrit sur un tableau les points positifs et négatifs du précédent Sprint. On utilise ce tableau pour améliorer le prochain sprint.

3) Documents Scrum (Scrum Artifacts)

Product Backlog

Elaboré par le Product Owner, ce document contient l'ensemble des fonctionnalités à réaliser pour le produit, exprimées généralement sous forme de "User Stories".

Exemple de Product Backlog

Les User Stories s'expriment généralement sous forme d'un triplet (Rôle, Résultat,Raison). Rôle : "En tant que X", Résultat : "je veux avoir ceci et cela...", Raison : "ainsi je pourrais vérifier ceci et cela". Les User Stories doivent vérifier les contraintes suivantes :

• Être indépendantes les unes des autres
• Négociables (entre l'équipe et le Product Owner)
• Contenant de la valeur (apporte de la valeur ajoutée au produit)
• Estimables en termes de charges de réalisation (points ou heures)
• Petites
• Testables

Si les "User Stories" se décomposent en "Tâches". Elles même se regroupent pour former des "Epic Stories" ou des "Features". Les User Stories se réalisent en 2 à 4 semaines contre 3 à 6 mois pour les Features et quelques heures/jours pour les tâches.

Liste des obstacles/empêchements

Cette liste maintenue par le Scrum Master et affiché dans la salle de travail à côté du tableau des tâches, regroupe l'ensemble des tâches bloquées et la nature des obstacles ou difficultés empêchant l'équipe de les réaliser. Le rôle du Scrum Master, avec l'aide du Product Owner est de résoudre tous les problèmes recensés dans cette liste. 

Diagramme "burn chart"

Ce diagramme montre le travail restant en cours du temps. La droite en bleu ci-dessus est tracée en fonction de la vélocité théorique de l'équipe. Si la courbe est en dessous de cette droite, l'équipe est en retard par rapport aux prévisions. Au-dessus, elle est en avance. Généralement, une courbe saine connaît des oscillations autour de la droite idéale. Une fois l'équipe est en retard, ensuite elle rattrape son retard, etc. la ligne d'en bas est la "ligne rouge" qui détermine la durée du Sprint. Si on rajoute des User Stories au sprint, cette ligne est décallée vers le bas d'autant de points rajoutées. La durée du Sprint est alors allongée si la vélocité n'a pas changé, c'est-à-dire si l'équipe n'est pas renforcée par exemple.

Source : Target Process Help

Conclusion

Durant ces trois articles nous avons d'abord souligné les insuffisances des méthodologies lourdes de gestion de projet. Ensuite nous avons introduit l'esprit Agile et comment il améliore la gestion des projets informatiques en en minimisant les risques et en augmentant leurs chances de réussite. Ensuite, nous avons fait un zoom sur la méthologie Scrum, une démarche Agile parmi les plus utilisées du marché.