Scrum, XP et TFS 2010

Teneur de la réunion

Comme son nom l’indique, cette réunion qui se déroule avant chaque nouveau sprint à pour but de planifier le sprint à venir.

Cette réunion est donc critique pour le bon déroulement de tout le sprint. A l’issue de cette réunion l’équipe devrait disposer d’assez d’informations pour travailler sereinement pendant plusieurs semaines.

Lors de cette réunion, l’équipe au complet et le directeur de produit vont donc débattre, en se basant notamment sur le backlog de produit afin de déterminer:

• Un but à atteindre pour le Sprint
• Un certain nombre « d’histoires » et de « tâches » qui découpent le travail à effectuer
• La durée du sprint ainsi qu’une date précise pour la démonstration de fin de sprint
• Une heure et un lieu pour la mêlée quotidienne

Il s’agit là de concepts qui méritent d’être précisés.

Le but du sprint

Définit par le directeur de produit, et résumé en début de réunion, il s’agit bien sûr de l’objectif à viser et à atteindre dans le prochain sprint.

Attention: Le but reste totalement fonctionnel et doit pas entrer dans les détails techniques!

Exemples de but:

« Implémentation d’un outil d’analyse des retour clients », « Implémentation d’un moteur de recherche », etc…

Les histoires et les tâches

Il est important de distinguer les histoires des tâches:

• Les histoires cadrent une fonctionnalité désirée de manière globale.
• Les tâches sont des sous-entités d’histoires qui découpent ces dernières en tâches unitaires

Exemple:

Pour l’histoire: « Recherche d’utilisateurs »

Nous auront les tâches:

• Écriture des scénarios de test
• Implémentation de la liste de utilisateurs
• Test, intégration et débogage
• Implémentation du formulaire de requête

Durée du sprint et date de démonstration

La durée des sprints est fixe en théorie cependant, au début de l’application de Scrum vous tatillonnerez pour trouver la durée qui vous convient le plus.

Il n’y a pas de règle dans ce domaine. En réalité cela va dépendre du type de projet sur lesquels vous travaillez, sur la taille de votre (vos) équipe(s) et surtout de votre expérience acquise au fil des sprints.

• Des sprints courts entraînent des livraisons plus fréquentes, donc des retours plus rapides du clients ce qui permet de perdre moins de temps pour les modifications et corrections. On a donc une entreprise plus réactive et plus agile.
• Des sprint longs permettent à l’équipe de mieux monter en puissance, de passer plus de temps sur l’implantation et la correction pour plus de qualité et cela entraine de surcroit une baisse de la charge de réunions et de démonstrations.

Les deux stratégies présentent donc leurs avantages et c’est à vous de trouver le bon compromis dans votre situation. Une valeur moyenne et acceptable pour les sprint semble être de 3 semaines mais encore une fois cela seras différent dans chaque entreprise.

Une fois la longueur du sprint fixée, il est important de tout de suite planifier la date et l’heure précise de démonstration pour le travail effectué lors du sprint. Cette date reste fixe et la démonstration aura lieu quelque soit l’état d’avancement.

L’heure et le lieu de la mêlée quotidienne

La mêlée quotidienne doit avoir lieu tous les jours à une heure et dans un lieu fixes. Il convient de décider d’une heure qui convient à tous les membres de votre équipe cependant on préfèrera programmer celle-ci le matin le plus tôt possible.

En effet il est plus simple d’effectuer cette réunion tôt le matin car chacun y fait un feedback sur le travail effectué la veille et annonce ce qu’il va faire dans la journée à venir.

Le Backlog de sprint, Quésaco?

A la base de tout projet mettant en œuvre la méthode Scrum, il y a la création du backlog de produit.

Le backlog de produit est le document cadre qui servira à la planification de tout le projet et qui servira de référence fonctionnelle sur les exigences du client.

Il se présente sous la forme d’une liste priorisée d’exigences, d’histoires et de caractéristiques décrites par le client. Ce document sera rédigé par le client, en la personne du Directeur de produit puis présenté et completé avec toute l’équipe de développement notamment pour l’estimation du temps..

Ce document, qui peut se présenter sous la forme d’un fichier Excel accessible mis à disposition de l’équipe sur le portail Sharepoint du projet ou dans un dossier partagé.

Structure du backlog

Le backlog comprend les champs de base suivants:

• Le champ Importance, qui définit comme son nom l’indique l’importance contractuelle de la réalisation de cette partie du projet.
• Le champ ID qui détermine un identifiant unique pour l’histoire en question.
• Le champ Nom, ou Description qui décris de manière claire et succincte la fonctionnalité désirée par le client
• Le champ Estimation qui estime en « points » la charge de travail. (L’unité de point fixée au début du projet correspond à des « Jours/Homme idéaux »: 1 point = 1 jour/homme idéal)
• Le champ Comment démontrer qui fait office de spécification de test ultra simplifiée (1 à 2 phrases succinctes).
• Le champ Notes qui permet d’ajouter toute information complémentaire indispensable à la bonne compréhension de l’histoire.

backlog de produit

Bien sûr chaque projet est différent et ce tableau doit pouvoir s’adapter au contexte, à l’organisation, et à toute sortes de paramètres qui peuvent être important de préciser dans le backlog. C’est pourquoi vous êtes libres d’ajouter à ces champs d’autres champs que vous pourrez juger utiles tels que:

• Un champ Catégorie qui fera la distinction entre les nouveau développements et les optimisations par exemple.
• Un champ ID de suivi de bug si vous utilisez un système de suivi de bug.

On peut donner de nombreux exemple, et c’est à vous de juger si la nécessité de tel ou tel champs se justifie. N’oubliez pas cependant que ce document n’as qu’un rôle de cadre et qu’il ne doit en aucun cas être surchargé afin de rester lisible.

L’Importance

Le champs importance est déterminé selon une échelle totalement libre. En effet une histoire avec une importance à 80 ne seras pas forcément 4 fois plus importante qu’une histoire avec une importance de 20.

Simplement, il est important que chaque histoire ait une importance unique afin de créer une hiérarchie claire entre celles-ci et il est également important de laisser un écart suffisant entre chacune d’elle à la création du backlog. Il faudra être en mesure de pouvoir insérer de nouvelles histoires que l’on aurait pas forcément prévu.

Pour aider à déterminée l’échelle que l’on va utiliser, on peut se fixer 3 seuils avec un code couleur:

• >= 50: (Rouge) Histoire indispensable à la release. Si elle ne sont pas livrées à temps, cela entraînera des pénalités.
• 20 < x < 50: (Jaune) Histoire indispensable mais qui autorise un petit délai de livraison sans pénalité.
• <= 20: (Vert) Histoire secondaire qui pourront être livrées dans une version mineure suivante.

Une fois ceci effectué, on complètera le backlog avec le code couleur choisit pour une meilleur lisibilité du document.

backlog de produit avec code couleur

A retenir

Garder bien en tête que le Directeur de produit doit rester focalisé sur les objectifs métier et ne pas se soucier des aspects techniques. C’est également le cas pour ce document qu’il rédige et qui ne servira que de cadre fonctionnel à l’équipe.