p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Georgia}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Georgia; min-height: 15.0px}

Je pense que les questions que tu te poses tu peux les trouver dans les ouvrages classiques de l’Agilité, comme l’ouvrage de Mike la su planification agile. Je ne fais qu’appliquer la méthode rien de plus, rien de moins. 

Un plan de release, c’est un roadmap de livraison.  Par exemple dans 2 mois, je livre telles fonctionnalités pour que les Admin Sys. puisse réaliser des tests de déploiement ou avoir un premier retour utilisateur avec la méthode de Kano.  Si je me réfère au standish group, les projets classiques finisse à 30 % dans les temps, nous passons à 42 % avec Agile. Ce n’est pas du dé, mais une pratique maîtrisé avec le temps et l’expérience.  Nous savons tous par expérience que personne ne peut en début de projet savoir si nous finirons dans les temps. 

Concernant la technique pour calculer les estimations d’une user story en story point, nous prenons des users story de références qui ont été jugées par l’équipe fiable en terme d’estimation et simple à comprendre même pour un débutant. 

Dans nos équipes nous avons trois US de référence.  Je vais me répéter une dernière fois, mais on mesure un effort. Cela sous-entend que les US sont bien INVEST et qu’une équipe est passée avant pour réaliser une première estimation, ce que nous faisons avec une réunion d’estimation 1 fois par semaine. Je détaillerais rapidement cette réunion sur mon blog. 

Les plannings de sprint sont réalisés de plus en plus souvent en magic estimation, nos équipes possèdent bien les estimations. Notre concentration se porte alors sur 1 ou 2 story qui peuvent sembler complexes. Les équipes ne se posent pas la question de complexité sur 80% des US, les dernières sont dépouillées pour comprendre comment les faire. Une fois la solution trouvée on estime.  Il y a donc plus de complexité, mais simplement la mesure d’un effort pour la réaliser. 

Les équipes réalisent de très bonnes estimations au bout de trois de sprint, les vélocités sont calculées sur l’ensemble du projet. Nous regardons la vélocité à la fin des sprints pour en discuter en rétro.

Je suis actuellement la vélocité de 7 équipes Scrum simultanément, elle varie parfois, elle monte et parfois descendes… Que ce soit pour des congés de maladie, des retours de vacances, un build qui coince sur un Hudson, une montée de version qui a plantée, les maquettes qui ne sont pas arrivées en temps, etc. Mercredi nous avons du restaurer un SVN, la machine a crashé… 

La vélocité ne se mord pas la queue, pour le premier projet la question se pose, si aucune vélocité est connue. Quelle est la vélocité de l’équipe et comment je fais mon planning de release ?

 C’est très simple, durant le sprint 0 nous faisons des réunions d’estimation du backlog et nous préparons avec l’équipe projet un premier planning sur 2 sprints.   Nous obtenons une première estimation qui s’ajuste au bout de trois sprints (retour d’expérience dans la plupart des SM).  Si nous avons un BP de 300 points en début de projet et que nous estimons une vélocité de 50 points par sprint (résultat du planning de sprint). Nous avons 6 sprints. 

Tout au long du projet, nous restimons le BP, plus le projet avance plus notre connaissance de « comment faire cela » est meilleure.  Il n’y a pas de jeu de dé, aucune méthode ne propose cela à part Scrum. Je n’ai jamais vu un projet « classique » on l’on revient chaque semaine sur les estimations des fonctionnalités pour les ajuster. 

Nous savons qu’aucun projet ne peut être estimé de manière juste, il suffit d’entendre parler des retards des sociétés d’avionique ou autre.  La méthode Agile propose de revenir sans arrêt sur nos estimations pour les ajuster et prendre les bonnes décisions. 

Pour terminer et répondre à l’ensemble des questions. Utiliser des story points c’est avant tout pour utiliser une technique simple et compréhensible par tous que je sois ébéniste ou développeurs.  

 Que ce passe t’il si je fais des estimations en heures, les temps d’estimations sont doublés.  Je le test sur chaque nouvel arrivant dans les projets Scrum. En 2010, j’ai fait passer environ 200 personnes sur Scrum en les accompagnant sur des périodes 6 mois à 1 an.  Scrum ça marche. Mais ne garantis pas de faire tout ce que le client veut dans les temps impartis. 

Si cela peut aider, certaines équipes Agile utilise de l’Ideal Days quand les équipes ne sont pas encore familiarisés avec Agile.  Mais cela ne fait que repousser l’apprentissage. 

Les ST c’est déroutant la première fois, comme à peu près tout…