Qu'est-ce que "l'essaimage"?

J'ai entendu parler de l' essaimage dans le contexte de la programmation agile ou extrême. Cela semble être un complément à l'appariement.

C'est quoi exactement? Quand devrait-il être appliqué? Comment le fais-tu bien?

L'idée est que tous les membres de votre équipe travaillent sur la même histoire au même moment. Au lieu que chacun se concentre sur des tâches différentes, chacun se concentre sur une tâche à la fois jusqu'à son achèvement. Ensuite, ils passent à l'étape suivante, où ils travaillent tous ensemble.

Cela aide les équipes qui ont du mal à terminer les histoires avant la fin du sprint. Les équipes terminent souvent 80% de toutes les histoires, mais aucune n'est complète. Cela est moins utile que de terminer complètement 80% des articles, car les articles inachevés n’ont (en réalité) aucune valeur pour un utilisateur final. Il est plus facile de terminer des histoires lorsque tous les membres de l'équipe se concentrent sur une histoire à la fois. C'est la motivation derrière l'essaimage.

Il y a quelques difficultés ici. Par exemple, l'AQ 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 (au début, échouer) des tests sur la conception et non sur la mise en œuvre réelle.

L'essaimage fait simplement référence au fait que plusieurs personnes travaillent ensemble pour mener à bien 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 est à la traîne ou s'il souhaite terminer une tâche ou une histoire plus tôt, d'autres personnes cesseront de travailler sur d'autres tâches et «essaieront» de mener à bien la tâche, ce qui signifie qu'elles travailleront toutes ensemble pour une tâche ou une histoire jusqu'à ce qu'elles le soient. est terminé.

Nous avons récemment eu quelques histoires qui étaient assez ennuyeuses et inintéressantes. J'ai donné à l'équipe un petit stimulant (pizza) et une échéance (fin de journée) pour terminer le travail. Ils ont donc explosé et ont assommé au moins deux jours de travail en un après-midi. Ils ont fait le travail rapidement et rapidement, puis chaque membre de l'équipe est retourné à la tâche sur laquelle il travaillait. Ils ont eu un repas gratuit, j'ai commencé tôt le travail qui aurait pu durer à cause de sa nature terne, et l'équipe a pris de l'avance sur son sprint. Gagnant-gagnant-gagnant.

"Essaimage" n'est rien de plus qu'un terme sophistiqué pour "hé, laissez-nous vous aider avec ça".

Le swarming 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". Essaimage, dans sa forme la plus simple, signifie que les équipes travaillent en collaboration sur des éléments (histoires) et les achèvent jusqu'à leur achèvement. Le concept de base est de "cesser de commencer et de terminer". En d’autres termes, au lieu que chaque développeur travaille indépendamment sur une histoire, l’équipe se concentre sur un ensemble plus limité d’histoires / de tâches et effectue chaque élément plus rapidement. Considérez-le comme la différence entre un système mono-threadé et multi-threadé. Si une user story contient 10 tâches à effectuer, et que chacune dure 8 heures, en supposant qu’il n’ya pas de complications, un développeur peut travailler chaque tâche de manière séquentielle et terminer l’histoire en 80 heures, ou environ deux semaines (avec un sprint de 10 jours). de 8 heures de développement par jour). Et si deux développeurs séparaient les tâches et les travaillaient simultanément? Les mêmes 80 heures de travail peuvent être complétées de cette manière en une semaine. Ajoutez un troisième et vous pouvez voir maintenant que cela pourrait être fait dans 3 à 4 jours.

L’essaimage peut se faire de plusieurs manières:

1. Programmation en binôme (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 la direction à plus long terme et en aidant à réviser le code simultanément.
   2. 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, écrivant de manière automatisée, etc.
   3. Essaimage comme je l'ai mentionné ci-dessus, ce qui est très commun. Habituellement, les membres de l'équipe fourmillent une histoire, mais chacun possède des tâches individuelles dans cette méthode.
   4. 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 généralement trop de "travaux en cours" ou de travaux en cours, et souvent de nombreuses histoires commencent mais ne sont pas terminées. Ceci est un anti-modèle, et ne sont pas les meilleures pratiques.

Les équipes qui essaiment ont tendance à avoir moins de travaux en cours et à compléter plus d'histoires - et c'est ce que je veux dire, c'est-à-dire développées, testées, approuvées, prêtes à être déployées. C'est donc une pratique qui est au cœur de l'agilité.

L' article suivant sur InfoQ décrit une approche de l'essaimage:

• L'équipe utilise la programmation par mob pour la plupart de ses tâches de codage
• Une partie de l'équipe ou des membres individuels de l'équipe se divisent souvent et rejoignent l'équipe à intervalles rapprochés
• Tout le monde fait tout (pas de rôles)
• L’équipe n’utilise pas d’estimations, les en-cours d’essai en sont toujours une, pas besoin de stand-ups ou de cérémonies similaires

Lisez l'article pour l'explication détaillée.