Sprint 0 - un plan pour la période exploratoire du projet

Auteur : Brad Newman
Source : Sprint 0: A Plan for Project Discovery
Date : 01/06/2012

---

Traducteur : Fabrice Aimetti
Date : 12/09/2012
Merci à : Henrik Larsson

---

Traduction :

Quand un projet démarre, les équipes Scrum sont mises au défi de transformer la chrysalide qu'est une charte ou un appel d'offres en un papillon qui est le Backlog de produit. La pression est encore plus grande lorsque la prestation est un projet au forfait. La dernière chose dont une équipe a besoin, c'est de passer du temps à expliquer la mécanique de Scrum à des partenaires métier tels que le Product Owner. Par conséquent, il est impératif qu'un plan clair pour le Sprint 0 (ou la période exploratoire) soit aménagé de telle sorte que tous les participants connaissent bien leurs rôles et que le processus de réduction du cône d'incertitude soit entrepris dès que possible.
MATRICE DE PARTICIPATION AU SPRINT 0
Lors de la planification du Sprint 0, nous utilisons une matrice comme celle ci-dessous pour aider nos clients à comprendre quel sera leur niveau de participation au cours de la période exploratoire et qui a besoin d'être invité aux réunions. (R = obligatoire, O = Optionnel).
Activités du Sprint 0

	Lancement	Planning Projet	Exigences	Planning Equipe	Échantillon Produit	Revue
Partie prenante	O	O				O
Expert	R		O	O		O
Product Owner	R		R	R		R
Chef de Projet	R	R				R
Scrum Master	R		R	R	R	R
Equipe Projet	R		R	R	R	R
Exploitation / Infrastructure	O				R	O

DÉTAIL DES ACTIVITÉS DU SPRINT 0
Réunion de lancement
Nous démarrons le Sprint 0 avec une réunion de lancement. C'est là que l'équipe présente la mécanique, les artefacts, les rôles et les cérémonies de Scrum aux parties intéressées. Cette réunion est importante pour aider les parties prenantes à se familiariser non seulement avec les personnes qui réalisent le logiciel, mais aussi avec une terminologie que ne leur est pas très familière.

Durée	Activités	Livrables
0,5 jour	Présentation des participants Présentation de Scrum Personnes associées aux rôles	Liste des personnes assignées aux rôles

Planning Projet
Il arrive souvent que le projet soit mené avec des partenaires qui ne sont pas familiers de Scrum. Dans ces cas, nous intercalons une "couche de traduction" pour que les cérémonies et les artefacts produits par Scrum soient traduits et communiqués sous une forme plus traditionnelle (commande et contrôle). Lors de ces activités, nous cherchons à informer nos partenaires métier sur la façon de recevoir l'information produite par l'équipe projet (un Burndown Chart par exemple) et l'utiliser pour piloter les jalons et l'avancement global du projet.

Durée	Activités	Livrables
~3 jours	Énoncé des travaux revu Création d'un plan pour la communication, le suivi du budget et la gestion des risques	Documentation des plans de gestion du projet

Exigences
Scrum réussit quand l'équipe projet est en mesure de montrer la valeur aux parties prenantes et récupérer du feedback sur ce qui a été produit plus tôt dans le projet. Par conséquent, il est très important que le Product Owner comprenne bien sa responsabilité dans la priorisation du Backlog de Produit afin que la fonctionnalité la plus importante soit réalisée en premier.

C'est pourquoi les user stories du backlog de produit sont uniquement exprimées en termes de valeur métier. L'équipe projet travaille avec le Product Owner pour s'assurer que les user stories ne contiennent que des énoncés courts de fonctionnalités aidant les utilisateurs à atteindre leurs objectifs. Nous nous assurons également que les user stories soient de la bonne taille afin d'éviter que des epics soient présentes en haut du backlog de produit. Les user stories présentes en haut du backlog de produit doivent toujours être dimensionnées de sorte qu'elles soient bien comprises par l'équipe pour commencer à les construire lors du prochain sprint.

Durée	Activités	Livrables
3 à 5 jours (projet de taille moyenne)	Formation du Product Owner à la maintenance du backlog de produit Backlog produit initialisé Exigences non fonctionnelles identifiées (temps de réponse, charte ergonomique, etc.) Besoins exploitation, infrastructure et réseau identifiés	Backlog de produit initialisé Charte ergonomique Document des exigences techniques Topologie réseau

Planning équipe

Scrum requière un état d'avancement sans aucune ambiguïté en ce qui concerne la réalisation d'une fonctionnalité. Par conséquent, dès le début du projet, l'équipe doit définir ce que signifie être "fini". Cela implique de travailler avec le métier et l'informatique afin de comprendre à la fois les exigences fonctionnelles et techniques requises pour considérer qu'un morceau de fonctionnalité est potentiellement déployable.

Une fois cette définition en place, l'équipe peut commencer à estimer la taille relative de chaque user story dans le backlog de produit. Nous utilisons typiquement l'estimation en points de story et, quand il y a un grand nombre de stories, la meilleure façon de s'y prendre est de faire une comparaison relative. Ce processus commence par établir une story de petite, moyenne et grande taille, puis continue en comparant chaque story suivante aux stories échantillons pour décider si elles sont plus grandes ou plus petites.

Durée	Activités	Livrables
2 jours	Estimation du Backlog de produit en points de story Définition du contrat de service de l'équipe qui comprend notamment : la Définition du "Fini" la longueur du Sprint le lieu et l'endroit de la Mêlée la date des réunions de Planification / Revue Estimation des tâches sur une fonctionnalité échantillon Identification des risques techniques	Nombre de points total estimé pour le Backlog de Produit initial Documentation du contrat de service de l'équipe Tâches du Backlog de Sprint pour la fonctionnalité échantillon Liste de "Spike"

Échantillon Produit

L'étape finale du Sprint 0 pour l'équipe projet est de produire un échantillon de fonctionnalité. Cette activité a plusieurs objectifs. Elle prépare l'équipe au Sprint 1 et lui permet de "partir sur les chapeaux de roue" en s'assurant que tous les éléments sont en place pour réussir le lancement. Elle montre aux parties prenantes que l'équipe est capable de produire un logiciel opérationnel. Et plus important encore, elle permet d'établir la vélocité initiale de l'équipe.

La vélocité est exprimée en nombre de points de stories terminées au cours d'une période de durée fixe (timebox). Alors que les équipes ont tendance à s'améliorer à mesure qu'elles travaillent sur un ensemble de problèmes, une vélocité définie en sortant du Sprint 0 leur permet de commencer à répondre à la question de savoir combien elles peuvent finir de choses dans un temps et un budget fixés. Si, par exemple, une équipe finit toujours 20 points de story sur un sprint de trois semaines et qu'il reste un total de 200 points de story dans le backlog de produit, nous pouvons prédire avec un niveau acceptable de risque qu'il lui faudra 10 sprints soit 30 semaines pour finir l'ensemble de ces fonctionnalités.

Toutefois, si le budget ne prévoit que 15 semaines, le Product Owner peut commencer à marquer d'une "ligne rouge" l'engagement de l'équipe à terminer les 100 points de story. Même si la ligne rouge peut être une déception pour certains Product Owners, il est important de leur rappeler que, puisque les fonctionnalités les plus intéressantes ont été développées en premier et que plus de 60% des fonctionnalités d'un logiciel sont soit rarement soit jamais utilisées, on aura souvent un ensemble suffisant de fonctionnalités prêtes à être déployées.

Durée	Activités	Livrables
7 à 14 jours	Mise en place de l'environnement de développement Développement de l'architecture de haut niveau Mise en place de l'environnement d'intégration Mise en place de l'Intégration Continue Mise en place du déploiement automatisé Modèle de données initialisé Développement d'une fonctionnalité échantillon Test de la fonctionnalité échantillon Correction et vérification des bugs de la fonctionnalité échantillon Rédaction de la documentation requise pour la fonctionnalité échantillon	Définir la "ligne rouge" Documentation de l'architecture du projet Une fonctionnalité échantillon opérationnelle déployée sur les environnements de DEV et de TESTS Documents de conception initiaux (diagrammes entités/relations, diagrammes UML de haut niveau)

Revue

Le dernier événement du sprint 0 est une Revue de Sprint en miniature montrant les réalisations de la période exploratoire.

Durée	Activités	Livrables
0,5 à 1 jour	Démonstration de la fonctionnalité échantillon Revue initiale des documents d'architecture Revue de la charte ergonomique Revue du plan de gestion du projet Revue de la priorisation du Backlog de produit	Fonctionnalité échantillon déployée sur l'environnement de tests d'intégration