Certain d’entre-vous ont-ils déjà expérimenté le Mob Programming au sein d’une de leurs équipes ?
C’est une méthode de développement logiciel où toute l’équipe travaille sur le même sujet, en même temps, dans le même espace et sur le même ordinateur.
Ouaip. J’ai expérimenté, et aussi fait avec une team en tant que facilitateur.
C’est :
Pas facile à organiser ! Beaucoup de croyances sur le mob prog’, « c’est fatiguant », « ça marche que si tout le monde est hyper chaud », « ça ne sert que pour les tickets complexes »…
En tant que pilote, c’est pas facile de « juste être la personne qui tape ce que les autres disent », car on a pas le temps de vraiment réfléchir quand on a le clavier. Faut juste accepter que c’est le process qui veut ça et lui faire confiance.
Hyper puissant et sous côté.
Le besoin d’un facilitateur avec un minimum de connaissance technique (encore mieux s’il est vraiment bon techniquement…) peut permettre de lancer la machine, après l’équipe n’en aura plus besoin !
Il a, semble-t-il, beaucoup d’expériences sur le sujet et sa conférence était très inspirante.
Son LinkedIn est dispo sur la page du programme de l’agile tour.
Bonjour,
Expérimenté et même beaucoup utilisé dans mon équipe.
Ça marche bien, et même très bien, si tout le monde adhère, et est convaincu.
En revanche, à distance ça perd de son intérêt et ça devient très fatigant.
Je vous consille me REX d’un des membres de cette équipe, sur cette vidéo, à partir de la 30ieme minute.
Quand je disais « c’est fatiguant », mon intention c’est de montrer que la croyance utilisée c’est « c’est fatiguant donc j’ai la flemme de le faire » C’était pas clair en effet ! C’est effectivement fatiguant haha.
Et +1 sur Woody Zuil. C’est un peu la référence sur ça !
On en fait quelques fois dans l’équipe, les retours sont très positifs. Ca permet de torcher en 1h à 4 un dev qui aurait pris 1 ou 2 jours tout seul en attendant à chaque fois les réponses des collègues.
On l’utilise surtout lors de développements « cross techno », pour traverser la stack de l’enfer du back au front.
Pour le Mob en remote, l’extension LiveShare est excellente :
Comment ça s’organise concrètement en full-Time, tu as du Rex a ce sujet ? Comment les dev acceptent ça ? J’avoue c’est pas facile à vendre aux développeurs, le pair ça passe plutôt bien mais considérer que l’équipe va bosser en mob pendant tout un sprint c’est chaud non ?
En plus de cette la question de l’acceptation, comment pourrait-on savoir comment dimensionner une équipe qui va faire du Team Programing en permanence ?
Si tu as un Architecte/TechLead et un Dev par exemple qui sont bon. Il en ait de même pour les QA et autres Business Analystes ?
J’ai envie de dire que je prends que quelques très bon profils et hop?
Mis à part la montée en compétences de l’équipe (du reste de l’équipe), si je peux disposer d’une équipe resserrée et compétente, je les fais bosser en Team Programing et le tour est joué ou ai-je raté quelque chose ?
Faut varier. Le mob n’est pas un golden hammer, c’est un outil qui marche bien dans certain cas et pas dans d’autre. Le problème du pair/mob programming est que parfois (souvent oserai-je dire même), on monopolise un groupe pour finalement obtenir la productivité de l’élément le plus lent du groupe.
Tout dépend du référentiel dans lequel tu te poses. Si tu prends le référentiel Scrum, tes architecte/techlead/business analyst/QA sont des Dev. A partir de là, je sais pas si ta question se pose encore.
Mais allons plus loin: Qu’est-ce qu’on recherche avec le team-programming ?
La productivité ? Oui, sûrement, sur des problèmes complexes, 4 têtes valent mieux qu’une. Sur des points plus simples, ce n’est pas forcément ça qui fait que le teaming est aussi précieux.
La montée en compétence ? Bien sûr. Et d’où donc l’intérêt d’avoir une équipe multi-profil. D’une part parce que tout le monde fait profiter à tout le monde de ses connaissances, mais aussi parce que même si @Tan l’a bien dit, parfois, la vitesse est celle du plus petit dénominateur commun, la mécanique de groupe entraine que le groupe cherchera justement à former les personnes qui manquent d’informations pour augmenter la vitesse plutôt que de laisser les gens sur le bas-côté. Et ça, en EQUIPE.
Le partage de connaissance ? C’est là tout le nœud du truc, et même plus encore sur des domaines complexes : la difficulté du développement, c’est d’avoir à la fois la connaissance technique et la connaissance du domaine dans un seul cerveau. Si ce cerveau commence à être déporté au niveau d’un groupe, on commence à voir le réel intérêt de pouvoir pallié aux « méconnaissances » de certain·es par les « connaissances d’autres »'.
La cohésion d’équipe et le bonheur de créer quelque chose ensemble ? Alors là, oui. Tu peux faire tous les team building que tu veux, ça vaudra pas un groupe de personne qui se frotte ensemble et se responsabilisent ensemble sur un même problème. Et ça, c’est hyper-puissant. De tous les points précédents, c’est personnellement mon préféré. J’ai rarement eu de moments plus gratifiants dans ma vie de dev que quand j’ai pair/team sur des sujets en équipe, et qu’à la fin, tout le monde était foutrement content du boulot accompli. Pas pour la difficulté du truc, non. Simplement parce qu’on avait fait cette activité ensemble, qu’on avait fait corps, et qu’au final, ce truc là était commun et nous rapprochaient. Et si je peux avoir ce genre de sensation de manière récurrente parce qu’on team tous les jours, je signe tout de suite.
C’était pas clair en effet ! C’est effectivement fatiguant haha.
