Qu'est-ce que "l'essaimage"?
J'ai entendu essaimage mentionné dans le contexte de la programmation agile ou extrême. Cela semble être un complément au jumelage.
C'est quoi exactement? Quand faut-il l'appliquer? Comment le faites-vous bien?
L'idée est que tout le monde dans votre équipe travaille sur la même histoire en même temps. Au lieu que tout le monde se concentre sur différentes tâches, tout le monde se concentre sur une tâche à la fois jusqu'à ce qu'elle soit terminée. Ensuite, ils passent à la chose suivante, où ils travaillent tous ensemble.
Cela aide les équipes qui ont du mal à terminer les histoires avant la fin du sprint. Souvent, les équipes terminent 80% de toutes les histoires, mais aucune n'est complète. C'est moins utile que de terminer complètement 80% des histoires, car les histoires inachevées n'ont (effectivement) aucune valeur pour un utilisateur final. Il est plus facile de terminer les histoires lorsque tout le monde dans l'équipe se concentre sur une histoire à la fois. Telle est la motivation derrière l'essaimage.
Il y a quelques difficultés ici. Par exemple, le contrôle qualité ne peut pas toujours tester les choses avant qu'elles ne soient construites (ou même conçues). Dans ce cas, vous devez établir une conception ensemble dès le début, puis le contrôle qualité peut écrire (initialement un échec) des tests par rapport à la conception et non à l'implémentation réelle.
L'essaimage se réfère simplement au fait que plusieurs personnes travaillent ensemble pour terminer une tâche ou une histoire. D'après mon expérience, ce n'est pas quelque chose que vous faites souvent.
En règle générale, chaque membre de mon équipe travaille sur une tâche différente et/ou une histoire différente. Si quelqu'un prend du retard ou si vous souhaitez terminer une tâche ou une histoire plus tôt, d'autres personnes cesseront de travailler sur d'autres tâches et "essaieront" pour terminer la tâche, ce qui signifie qu'elles travaillent toutes ensemble sur une seule tâche ou histoire jusqu'à ce qu'elle soit terminée. est terminé.
Nous avons récemment eu un petit nombre d'histoires qui étaient un travail assez ennuyeux et sans intérêt. J'ai donné à l'équipe une petite incitation (pizza) et un délai (fin de la journée) pour terminer le travail, alors ils ont essaimé l'histoire et assommé au moins quelques jours de travail en un après-midi. Ils ont fait le travail et l'ont éliminé tôt, puis chaque membre de l'équipe est retourné à ce sur quoi il travaillait. Ils ont eu un déjeuner gratuit, j'ai fait du travail tôt qui aurait pu se prolonger en raison de sa nature terne, et l'équipe a devancé son sprint. Gagnant-gagnant-gagnant.
"Swarming" n'est rien d'autre qu'un terme de fantaisie pour "hé, laissez-nous vous aider avec cela".
L'essaimage est en fait un concept central de l'agilité. Ce n'est pas quelque chose qui se fait "quand il y a des problèmes". L'essaimage, dans sa forme la plus simple, signifie que les équipes travaillent en collaboration sur des éléments (histoires) et les travaillent jusqu'à la fin. Le concept de base est de "quitter le début et commencer la fin". En d'autres termes, au lieu que chaque développeur travaille de manière indépendante sur une histoire, l'équipe se concentre sur un ensemble plus limité d'histoires/tâches ensemble et termine chaque élément plus tôt. Considérez-le comme la différence entre un système à un seul thread et un système à plusieurs threads. Si une User Story a 10 tâches à effectuer, et chacune dure 8 heures, en supposant qu'il n'y ait pas de complications, un développeur peut travailler chaque tâche séquentiellement et terminer l'histoire en 80 heures, ou environ deux semaines (compte tenu d'un sprint de 10 jours de 8 heures de développement par jour). Et si deux développeurs divisaient les tâches et les travaillaient simultanément? Les 80 mêmes heures de travail peuvent ainsi être accomplies en une semaine. Ajoutez un troisième, et vous pouvez voir maintenant que cela pourrait être fait en 3 à 4 jours.
L'essaimage peut se faire de plusieurs manières:
- Programmation par paires (deux développeurs assis côte à côte pour travailler sur le code, l'un est le "pilote" qui écrit le code, l'autre est le navigateur, en gardant à l'esprit l'orientation à long terme et en aidant à la révision du code simultanément.
- Travail en binôme: un développeur et un testeur travaillent simultanément sur le même travail, l'un codant et l'autre testant, l'automatisation de l'écriture, etc.
- Essaimage comme je l'ai mentionné ci-dessus, ce qui est très courant. Habituellement, les membres de l'équipe fourmillent une histoire, mais chacun possède des tâches individuelles dans cette méthode.
- Programmation Mob: toute l'équipe se concentre sur une histoire (ou même une tâche) à la fois.
Les équipes qui donnent une histoire à chaque développeur ont tendance à avoir trop de "travaux en cours" ou de travaux en cours, et souvent de nombreuses histoires commencent mais ne sont pas terminées. Il s'agit d'un ANTI-MOTIF et ce n'est PAS les meilleures pratiques.
Les équipes qui pullulent ont généralement moins de WIP et terminent plus d'histoires - et par fait, je veux dire développées, testées, approuvées, prêtes à être déployées. Ainsi, c'est une pratique qui est au cœur de l'agilité.
Ce qui suit article sur InfoQ décrit une approche de l'essaimage:
- L'équipe utilise la programmation mob pour la plupart de ses tâches de codage
- Une partie de l'équipe ou des membres individuels de l'équipe se séparent souvent et se joignent à l'équipe à de courts intervalles
- Tout le monde fait tout (pas de rôles)
- L'équipe n'utilise pas d'estimations, WIP en est toujours une, pas besoin de standups ou de cérémonies similaires
Lisez l'article pour l'explication détaillée.