Le canal du midi est agile
Qu’est ce que le canal du midi a à voir avec l’agilité?
Ce sont les écluses, qui régulent le trafic. Comme les sprints d’une release.
Entre deux écluses, pas plus de bateaux que la capacité possible.
Vous allez me dire, sans écluses plus de fluidité. Dans certain cas, oui, mais elle ne serait plus contrôlée, et l’on arriverait vite à saturation.
Je vous renvoie à la métaphore de l’autoroute par Alexandre Boutin : à 80% de capacité, l’autoroute est saturée, les bouchons commencent à se former, et le cycle est en accordéon.
Il est souvent difficile de choisir la taille d’un sprint, de 2 à 4 semaines.
J’ai même fait des sprints d’une semaine, sur des projets en phase de correction de bugs.
Lorsque l’équipe est trop grande, plus de 6 personnes, et les sprints trop longs, 4 semaines, il est difficile d’effectuer un planning meeting sur 1 journée seulement. Il y trop de user stories à étudier et donc trop de tâches à identifier, détailler et chiffrer. La visibilité d’un sprint est liée à la capacité et la taille du sprint.
Un sprint de 4 semaines avec une équipe de 10 personnes, soit 10 * 20 * 8h = 1600h.
A 4,5h (entre 1 et 8) en moyenne par tâche, Il faut donc identifier 355 tâches. C’est trop pour notre petit cerveau.
Je privilégie maintenant des sprints de 2 semaines.
Un sprint de 2 semaines et des équipes plus petites permettent de répartir la vélocité dans le temps. D’avoir une capacité ayant un niveau d’appréhension plus aisée. Cela facilité le calcul du reste à faire et permet de réellement bloquer le contenu d’un sprint, sans trop retarder la prise en compte des changements ou des « urgences ».
1 équipe de 5 en 2 semaines : 5 * 10 * 8 = 400h, soit 88 tâches. Beaucoup plus tangible.
Le nombre de tâche par sprint peut s’apparenter à la sensibilité qu'a notre cerveau à appréhender, comprendre, assimiler et visualiser dans le temps.
La sensibilité d’un sprint est le nombre de tâches qu’une équipe peut « comprendre ». Elle est la dérivée de la vélocité sur le sprint.
Inscription à :
Publier les commentaires (Atom)
2 commentaires:
Ah, le canal du midi ! La photo a été prise à quelle écluse, je ne reconnais pas ?
Dans les 400 heures, il faut garder du mou et aussi enlever les réunions Scrum, il va rester 320 heures environ. Et la moyenne que tu prends est bien basse pour une tâche. En plus toutes les tâches ne sont pas forcément identifiées au début. 40-50 tâches dans un sprint de 2 s. à 5, c'est encore plus facile à appréhender.
Salut Claude,
Je ne sais pas de quelle écluse il s'agit. Photo prise peut-être un peu trop au hasard de... Google.
Ok pour ton calcul. Le mien était volontairement simpliste!
Ok aussi pour le fait de ne pas avoir toutes les tâches définies "avec précision" en début de sprint, puisque Ken le dit! Tout en respectant le scope prévu du sprint en terme de user stories à faire.
Enregistrer un commentaire