Dans les projets Agile, en Scrum notamment, nous démarrons par un sprint 0. D’une durée d’environ 1 à 2 mois, il s’agit de mettre en place l’environnement de travail, de construire le backlog et de préparer la montée en charge de l’équipe.
Dans le cadre d’un projet de grande ampleur, dit « large scale », (~100 personnes sur 3 ans) la durée du sprint 0 n’est pas suffisante, il faut plus de temps. Pour garder le coté inspection et adaptation, il ne faut pas augmenter la taille du sprint 0 mais plutôt faire une release 0 incluant plusieurs sprints.
Les premiers sprints sont consacrés aux activités plutôt techniques visant à couvrir les risques, c’est la « vision de départ ». Dans ce contexte, les équipes sont autonomes sur la création de leurs user stories. L’élaboration du premier backlog s’étant faite lors d’un atelier de démarrage du projet (détaillé dans un prochain billet)
En parallèle, il faut préparer le backlog côté « vision métier ». Le produit étant organisé autour de grands thèmes, le découpage des équipes s’effectue par « area » couvrant ces thèmes. Il y a un Product Owner et des Area Product Owners.
On retrouve en quelque sorte la branche en Y chère à Pascal Roques.
Tout cela piloté par les valeurs fonctionnelles et techniques édictées par le PO. Les approches Bottom-up et Top-down combinées, mais toujours priorisées par la plus value.
Au final, les deux visions se rejoignent. J’estime cette jointure autour de 3- 4 sprints, ce qui équivaut à une release : c’est la release 0.
5 commentaires:
L'idée est interessante mais c'est quoi exactement les "activités plutôt techniques visant à couvrir les risques" ?
Tu parles de prototypage (au sens strict : du code que l'on va jeter et garder la vision) ou d'architecture, c'est à dire des fondations pour batir le reste en ayant cadré des décisions technologiques ?
Salut Olivier,
Ce n'est pas du prototypage, pas du jetable. Je n'ai pas précisé qu'il s'agissait d'un portage d'abord à iso fonctionnalités. En ce sens, le besoin est déjà connu des équipes qui peuvent être à même de définir des user stories sans "aide" du product owner dans un premier temps. C'est plus de la mise en place de l’environnement, adaptation des builds, puis prémices d'architecture.
Aussi, attention, même si je parle de la branche en Y, ce n'est pas du RUP pour autant. Le sprint 0 existe bien en tant que tel, des user stories fonctionnelles sont prêtes pour le sprint 1 et 2, mais le renversement de proportion entre fonctionnel et technique devrait être plus long qu'un seul sprint 0.
A+
Merci Laurent pour adresser ce suejt qui me tient particulièrement à coeur
Mon commentaire ici :
http://www.davidbrocard.org/node/107
Généralement un t sur les projets de cette ampleur on fait un pré-projet ( maquette ou prototype) pour valider la faisabilité du projet. La méthodologie doit être spécifique à chaque projet et pas forcément une méthode agile. La notion de sprint n'a pas beaucoup de sens quand on parle uniquement de lever les risques d'un projet
Oui, généralement, mais généralement aucun projet n'est pareil qu'un autre. Donc, en Agile, on a une sorte de méta-process que l'on adapte à chaque contexte. Et c'est justement très efficace pour lever les risques. Les sprints y prennent tout leur sens.
C'est ce que nous avons appliqué sur ce projet et ça porte ses fruits. Nous sommes bien en train de construire le produit, et non pas de vérifier si cela sera réalisable en faisant du jetable. Nous avançons petit à petit en réajustant les solutions en fonction des contraintes que nous rencontrons. L'architecture est éprouvée tout au long du process, par de la mise en oeuvre réelle.
On ne reste pas dans du conceptuel.
Je sans doute mal choisi le nom de ce billet, même Claude Aubry s'y est laissé prendre! J'aurais du l'appeler "Comment démarrer un projet avec 70 personnes en 2 jours et fournir un livrable opérationnel au bout de 4-5 itérations", ça faisait un peu long :-)
Enregistrer un commentaire