Une fois la partie cadrage ou Framing agile se termine, l'équipe de développement est déjà constituée, nous avons bien identifié et mis en place les règles de jeu et de travail (Charte de Travail, D.o.D, D.o.R, ...Etc.), alors c'est le moment pour commencer les cycles itératifs ou Sprints, et produire un produit de qualité répondant aux exigences de notre client.
Il faut favoriser dès le départ l'auto organisation de l'équipe, il faut penser à la meilleure façon de travailler et collaborer ensemble, alors parmi les Patterns qu'on peut utiliser dans ce cas de figure, c'est le "PATTERN FOURMILLEMENT".
Notre objectif principal c'est d'éliminer ou disant limiter le "Multi-tâches", ou plus précisément ce qu'on appelle "Multi-Stories", car lorsque un développeur par exemple travaille sur plusieurs tâches ou User Stories à la fois cela augmente ce qu'on appelle "Le Délai d'Immersion", surtout quand il sera amené à arrêter un travail et aller commencer un autre.
Prenant le cas d'une équipe qui a des Sprints de 4 semaines, un développeur a réalisé une tâche ou une User Story la première semaine du Sprint, alors qu'un test ou une anomalie vient d'être déclenchée par le testeur au cours de la fin de la troisième semaine ou voire la quatrième semaine en liaison avec l'US en question, pour cela le développeur aura besoin d'un temps (Délai d'Immersion) pour arrêter son travail en cours, et revenir au contexte de ce qu'il a fait lors de la première semaine.
Si on a une petite équipe de développement, alors il faut favoriser le fait que plusieurs développeurs travaillent au même temps sur l'User Story la plus prioritaire, le temps pour la finir et on passe au suivante, ainsi de suite.
Dans le cas d'une équipe de plusieurs personnes, le PATTERN FOURMILLEMENT ou "SWARMING" en anglais consiste dans ce cas de figure à s'inspirer du comportement des abeilles en divisant l'équipe en 2 ou 3 sous équipes selon le contexte de chaque projet et en tenant compte des compétences des ressources, et chaque sous-équipe va s'occuper d'une User Story le temps pour la finaliser et la mettre en statut "DONE".
Cette division et ce découpage reste bien sur temporaire, et à revoir à chaque Sprint, comme ça on peut à chaque fois changer les participants de chaque sous-équipe en leur permettant de monter en compétence sur d'autre types de tâches et demandes, ce qui favorise en fin de compte l'auto-organisation de l'équipe en totalité.
Conclusion :
L'objectif principal de ce Pattern, est de bien pousser chaque développeur à travailler et se focaliser sur un seul travail à la fois, et une fois on termine une User Story on passe à une autre, comme ça le temps ou le délai d'Immersion sera très faible, voire Null parfois, et tout ça c'est pour le but de produire le maximum de la valeur métier à la fin de chaque Sprint d'une part, et favoriser l'auto-organisation de l'équipe d'autre part.
Vous pouvez même profiter de l'occasion pour désigner un responsable pour chaque User Story, celui qui peut aussi la présenter ou la démontrer devant les parties prenantes lors de la cérémonie de "Sprint Review".
Bien noté, merci
Bonsoir,
Le rôle du PO est de bien présenter et expliquer les User Stories à l'équipe de développement, il intervient sur le côté fonctionnel et pilote le projet en terme de valeur métier apportée par chaque US.
le développement c'est la cuisine interne des développeurs, c'est eux de trouver la bonne manière et combinaison pour plus d'autonomie et auto-organisation.
l'essentiel pour l'équipe de développement est de s'assurer de la bonne compréhension du besoin, et livrer à la fin de chaque sprint un incrément produit de qualité répondant aux exigences et attentes du PO et client (Parties prenantes).
Merci pour le partage, dans ce cas c'est le PO qui intervient pour déléguer les développeurs sur une US, ou bien on laisse l'équipe s'auto-organise?