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.

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.

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.

En lisant mes flux rss, je suis tombé sur un article de Brett Schuchert, rédacteur sur le blog Object Mentor qui nous fait part d’un concept original pour la réunion d’avancement quotidienne.

Pour rappel, la réunion d’avancement a pour but de faire le point sur l’avancement et décider des objectifs du jour de manière très succincte. Pour s’assurer que ces réunions ne tirent pas en longueur et que chacun aille à l’essentiel, il nous propose de les effectuer tous debout et d’en profiter pour effectuer quelques exercices.

La personne qui a la parole pourra par exemple porter un poids, d’abords léger, puis au fur de plus en plus lourd au fil du temps afin de profiter de cette réunion afin d’offrir une séance sportive quotidienne à votre équipe.
Cependant afin de ne pas se retrouver rapidement avec des développeurs aux bras de culturistes sur des corps de poulets, il est important de suivre un programme varié à la semaine.

Voici donc une proposition de programme que vous pourrez adapter à votre convenance (commencer avec des poids léger tout de même).

• Lundi haut du corps: avec haltères, bras le long du corps, levez le bras vers l’avant ou le côté.

• Mardi cardio: trottiner sur place, sautez en ramenant les genoux le plus haut possible.

• Mercredi bas du corps: haltère sur les épaules, flexion de haut en bas.

• Jeudi cardio: trottiner sur place, sautez en ramenant les talons aux fesses.

• Vendredi abdominaux: mains sur la taille, jambes légèrement écartées et tourner le buste de gauche à droite avec le plus d’amplitude possible.

Une idée vraiment pas bête tant l’exercice fait défaut dans notre métier. Qu’en pensez-vous?

Principes

• Projet découpé en plusieurs itérations (Sprints) de 2 à 4 semaines. Chacune correspond à une partie de l’application mais doit être complète (fonctionne à 100%).

• 1 réunion initiale pour chaque itération pour définir les tâches.

• 1 réunion finale pour faire le point + 1 démo.

• 1 courte réunion d’avancement tous les jours.

• Génération régulières de tableaux de bords.

• Le client est au cœur du projet.

• Privilégier au maximum les interractions au sein de l’équipe.

Les acteurs

• Le chef de projet (ou ScrumMaster) est un organisateur qui facilite le travail de l’équipe.

• Le responsable fonctionnel (ou directeur de produit) définit et priorise les fonctionnalités de l’application.

• L’équipe définit le planning et l’attribution des tâches.

• Les clients sont concernés et consultés

• Eventuellement des Intervenants (StakeHolders) externes à la réalisation mais souhaitant avoir une vue sur l’évolution.

Découpage du projet

Les BackLogs

Le BackLog de produit

Liste des fonctionnalités désirées sous la forme de backlog items fournissant chacun une estimation de points arbitraires et une valeur client (ROI,…). Leur teneur et l’ordre de leur réalisation sont définis par le directeur de produit.

• Release Burndown Chart : points restants à réaliser.

Le BackLog de sprint

Choix des items à réaliser pr le sprint puis decoupage en tâches estimées en heures (<2j) mis à jour au fur et à mesure de la réalisation des tâches.

• Sprint Burndown Chart : heures restantes à réaliser

Estimations

• Les backlog items : Users stories (XP programming) estimées en points selon suite de Fibonacci (1,2,3,5,8,13) => Donne une idée du travail à fournir sans donner d’estimation exacte en heure (flexibilité)

• Calcul de vélocité : après un sprint terminé et pour estimer la valeur en temps du point

Vélocité = Temps réalisation Sprint / Points du Sprint

Vue d’ensemble