Programmation de la foule

Qu'est-ce que le Mob Programming ?

Le Mob Programming (MP) est une technique d'idéation et de codage de produits de groupe qui consiste à tirer parti des connaissances distribuées lors de la programmation et de la résolution d'un problème avec un seul ordinateur [Pearl 2018]. Cette technique est également connue comme une approche de développement logiciel où tous les esprits brillants travaillent sur la même chose, au même moment, dans le même espace et sur le même ordinateur [Zuill 2018]. La MP est un moyen de constituer un groupe de travail autour d'une histoire d'utilisateur (US).

Le Mob Programming a commencé avec le Pair Programming en 2000, inventé en 2002 [Marchesi 2002] et principalement développé par Woody Zuill qui a expérimenté la technique chez Hunter Industries qui est maintenant leur méthode de travail par défaut.

La programmation par la foule permet une rétroaction et une communication maximales [Marchesi 2002], ce qui est parfaitement en ligne avec la valeur agile "Individus et interactions sur les processus et les outils" [Beck 2001]. 

Depuis sa première version décrite par Marchesi, le MP commence par une réunion de conception du code qui traite de tout aspect du code [Marchesi 2002]. 

• revue de code en groupe : un morceau de code aléatoire est revu pour obtenir un retour sur les décisions de codage et de conception prises dans le passé et les décisions de refactoring sont prises en groupe.
• l'architecture mob : elle peut être réalisée efficacement en mode "Model Storming" [Galiber 2019]. Il est suggéré de faire cette réunion en deux groupes qui confronteront leurs idées et leurs points de vue avec tous les autres membres de l'équipe. Il est important d'éviter les groupes avec beaucoup de personnes pour laisser à chacun la chance d'être impliqué, ce qui est parfait pour une équipe scrum.

Pendant cette réunion, le code peut être modifié à la volée et les discussions peuvent se poursuivre en dehors de cette réunion. La participation de chacun est encouragée afin d'éviter les "spectateurs passifs" ou les "kibitzers" silencieux (ce phénomène est appelé "pensée de groupe") car les commentaires ouverts sont les plus attendus ici ! L'écoute participative est recommandée car elle aide les spectateurs à s'impliquer et à maintenir leur attention [Zenger 2016].

Le rôle du narrateur/dedriver devrait changer au cours de la réunion afin de développer le courage et la participation. Cependant, il semble qu'une certaine préparation de la réunion soit une bonne pratique pour faciliter les discussions et permettre à chacun de participer. En outre, il semble également qu'un seul coach lors de cette réunion ne soit pas une bonne idée, car les participants ont tendance à assimiler le coach à un "député, c'est son bébé", ce qui réduit la participation [Marchesi 2002].

Pendant le codage, comme dans la PP, le dactylo doit être soutenu par le reste de l'équipe et comme dans la programmation Ping-Pong dans la TDD [Hoover 2005], une fois que les tests unitaires sont verts et remaniés, le dactylo écrit un nouveau test unitaire et passe le clavier à quelqu'un d'autre, le nouveau dactylo. Cela permet de garder les gens au courant de ce qui se passe et de libérer les dactylographes et le code. 

Une alternative au ping-pong consistant à passer le clavier à un autre Dev est l'utilisation d'une boîte de temps (5 à 15 minutes - les sessions courtes doivent être privilégiées au départ [Zuill 2018][Pearl 2018]) dont le décompte est clairement visible par tous les participants. Le fait de forcer le timeboxing aidera le reste de la mob à rester au courant de ce qui se passe. Pour limiter la fatigue et favoriser la productivité, la "technique Pomodoro" peut également être utilisée [Cirillo 2017]. Éviter la préemption du clavier aidera également la foule à améliorer ses compétences en communication, ce qui est crucial ici [Pearl 2018].

Quelle que soit votre configuration de programmation Mob, pour aider les non-typistes, les numéros de ligne doivent être affichés afin que les gens puissent savoir quelle ligne spécifique est concernée. Comme toute l'équipe partagera un clavier et un IDE, vous devez vous assurer qu'il convient à la plupart des membres de l'équipe, pour ne pas dire à tout le monde. Vous pouvez regarder un timelapse de Mark Pearl pour voir quelques détails de configuration (clavier multiple, tableau blanc, etc.) et quelques autres recommandations à partager pour un bon départ. Il est également recommandé de faire une rétrospective intermédiaire après quelques sessions pour améliorer le MP et permettre aux gens de se libérer. L'état d'esprit correct concernant la PM est la méthode collaborative Kaizen : amélioration continue dans une attitude irréprochable [Zuill 2018]. Les gens doivent être critiques envers le code, et non envers les personnes. Les personnes introverties doivent également être interrogées en premier pour donner leur avis et une pensée critique ouverte doit être encouragée [Pearl 2018]. Il existe plusieurs recommandations liées au PP et au MP également [Llewellyn 2014] [Pearl 2018], mais la plus importante concerne les égos forts avec un état d'esprit "my way or no way" qui devrait être évité [Williams 2000].

Il est suggéré de commencer le Mob Programming à partir de quelques heures par semaine ou une heure par jour pour laisser les gens se familiariser avec le mobbing, mais lorsque le MP devient la norme, il apparaît que la réunion quotidienne de Scrum pour revoir les objectifs du Sprint est inutile car tout le monde connaît le point de vue du Sprint. Cette réunion est remplacée par une rapide rétrospective quotidienne pour l'amélioration continue [Zuill 2018]. Les alertes sur les objectifs sont remontées et Andon est pris en compte immédiatement par l'ensemble de l'Équipe.

Voici quelques-uns des avantages qu'il y a à laisser les gens travailler en programmation collective :

• En ce qui concerne les interactions, il semble que le travail en équipe de 3 à 5 personnes soit beaucoup plus efficace pour résoudre des problèmes complexes que le travail en binôme et, bien sûr, en solo [Laughlin 2006].
• Les foules sont moins sujettes aux interruptions. Une ou deux personnes peuvent manquer en raison d'un appel téléphonique ou autre, mais pas toute l'équipe. Cela conduit à une plus grande continuité [Pearl 2018].
• Le projet dépend moins des personnes clés car la PM introduit une redondance des compétences et permet aux personnes de T-Shape [Pearl 2018].
• La prise de décision est plus robuste [Mukherjee 2016].
• Beaucoup moins de conflits de fusion sont soulevés puisque toute l'équipe travaille ensemble [Pearl 2018].
• Rendement plus élevé au premier passage en raison de normes de qualité plus élevées grâce aux nombreux yeux [Pearl 2018].

De plus, il y a des avantages à travailler dans les PM qui peuvent être trouvés dans les PP [Williams 2000] [Vanhanen 2007] :

• elle réduit la probabilité de produire une mauvaise conception [Flor 1991].
• il élimine les défauts à la volée comme le propose l'approche Kaizen [Pearl 2018].
• il est également bon pour le partage des connaissances et la formation, en mode pratique pour la dactylo [Pearl 2018].
• il aide les gens à faire face à des tâches difficiles 
• il améliore la satisfaction professionnelle et la confiance globale dans leur travail
• il n'y a plus de retard dans l'attente des réponses [Zuill 2018].

Lorsqu'il s'agit de productivité, il semble évident que la MP est plus coûteuse que la PP ou même la programmation en solo (SP). Il est prouvé que la PP est plus rentable et plus rapide que la PS [Nosek 1998] [Shull 2002]. En ce qui concerne la Programmation Mob, il s'agit principalement de faire un choix entre l'efficacité du "flux" (voir WIP) et celle des "ressources" [Pearl 2018]. Traditionnellement, la direction vise une utilisation des ressources à 100%, ce qui est un piège et un désastre économique [Kniberg 2014][SAFe 2021-37][Reinertsen 2009] qui fait de la MP une solution rentable [Pearl 2018][Zuill 2018].

Cependant, l'introduction de la programmation mafieuse n'est pas si facile car elle implique la gestion, les ressources et les facteurs humains. De plus, dans certaines situations, la rentabilité à court terme et un résultat "suffisant" constituent l'option choisie en matière de prise de décision [Kerr 2004] et d'efficacité des ressources (par exemple, les projets à prix fixe). En effet, l'équilibre est aussi difficile à atteindre que la bonne qualité car il faut d'abord apprivoiser les questions de qualité pour fixer le curseur ; ainsi, en règle générale, la MP est introduite lorsqu'il s'agit de pièces critiques. La MP doit être expérimentée en premier, notamment dans un dojo, une pratique délibérée faite en groupe autour d'une problématique, combinée à une approche TDD sur un kata, une problématique spécifique prise comme exercice [Bache 2010].

Impact du Mob Programming sur la maturité des tests

MP améliore considérablement le niveau de qualité du produit grâce aux nombreux yeux qui collaborent pour chasser les problèmes ici et là. Mais une bonne qualité du code nécessite un refactoring. Ceci implique qu'une bonne couverture de test est nécessaire [Marchesi 2002], notamment grâce aux tests unitaires et aux harnais de test pour éviter les régressions lors du refactoring. Naturellement, si le codage est effectué en mode TDD , le refactoring en sessions MP est beaucoup plus facile. Cependant, pour faciliter le refactoring, produire trop de cas de test ralentira le processus. Tout comme le code de production, les tests doivent être refactorés et nettoyés [Zuill 2018] et un 5S sur les tests de manière régulière est aussi nécessaire que sur le code de production et la documentation; sinon, cela peut ruiner le flux de livraison. Impliquer l'ensemble de l'équipe dans une telle démarche permettrait aux personnes de T-Shape, de partager les connaissances sur les actifs du projet. L'application du MP à cette activité devrait renforcer à la fois le courage et la nécessité de le faire continuellement pour éviter une certaine dette technique sur les actifs en dehors du code et finalement se débarrasser de ce qui est déprécié ou inutile.

Le codage n'est pas la seule partie couverte par le MP ; en fait, l'idéation de groupe commence à partir de les US. Les ateliers "3 Amigos" ou "Cartographie des exemples" organisés dans le cadre du Sprint Refinement constituent un bon point de départ : trois personnes travaillent ensemble sur un site US. Néanmoins, le testeur et le développeur peuvent ne pas avoir suffisamment de connaissances et d'expérience en matière de production en raison de leur propre culture. Par conséquent, il peut être pertinent d'impliquer un gars orienté Ops dans les 3 Amigos, ce qui fait 4 amis. Par extension, le fait d'inviter différents types de profils est quelque chose qui devrait éventuellement se produire pour comprendre les nombreux pièges qu'un US donné pourrait déduire.

Une autre opportunité dans les tests de maturité est l'introduction de l'ATDD pendant une session MP. Ainsi, à partir d'un US

• les critères d'acceptation (CA) seront codés en premier avec des scripts qui vérifient les CA
• l'équipe se concentrera sur le codage du script qui automatise la vérification.
• Ensuite, l'équipe commencera à concevoir le code de production en mode TDD comme décrit précédemment.

D'après ce qui a été compris en termes de tests, des apprentissages en double boucle [Argyris 1977] ont lieu et conduisent l'équipe vers un bon produit plutôt que vers un produit qui serait conforme aux exigences fournies.

‍

‍

Pour permettre aux testeurs purs de participer encore plus au MP, des tests exploratoires peuvent être effectués dès que tous les AC d'un US sont respectés. Les testeurs peuvent également utiliser un outil de cartographie mentale pour prendre des notes pendant que les développeurs purs créent le produit. Ces notes peuvent être générées à partir des questions posées et partiellement résolues pendant les sessions MP et repérer les risques à tester à partir des commentaires des autres Mobbers. Ces réponses partielles peuvent être suspectées à partir des attitudes des autres Mobbers qui participent à une recherche continue de transparence. Ces notes aideront ce profil non-technique à maintenir l'attention et à demander des travaux complémentaires qui renforceront le produit. Ces notes conduiront ensuite à ce que James Bach appelle "Thread-Based Test Management" [Bach 2010] [Gatien 2012].

Pour aider les autres membres à rester au courant de ce qui se passe, quelqu'un dans la foule peut prendre des notes sur les décisions d'architecture. C'est ce qu'on appelle les "enregistrements de décisions d'architecture" (ADR) [De Simone 2020]. Ces ADR facilitent notamment

• l'accueil des nouveaux développeurs
• remettre en question la conception existante
• assumer la variabilité et préserver les options [SAFe 2021-03].
• définition de la piste architecturale [SAFe 2021-38]. 

Les notes pour les questions TBTM ou ADR sont un moyen de pratiquer l'écoute participative et de contribuer à la construction du produit même si vous n'êtes pas le soi-disant dactylo. Cela fait de l'effort commun un Task Force US qui parvient à tout faire en même temps.

Au moment du test, il existe encore une autre technique d'idéation de produits en groupe appelée crowdtesting. Elle consiste à impliquer une foule d'utilisateurs sur une plateforme et à les laisser trouver bugs à partir de leur contexte [Leicht 2017]. Par exemple, vous pouvez inviter un groupe de testeurs à évaluer le produit, tout comme les bêta-testeurs des tests mobiles, afin de vérifier la portabilité de l'application sous plusieurs configurations mobiles [Naith 2018]. Le crowtesting pourrait être mis en œuvre grâce à Canary Releases lorsqu'il s'agit de produits SaaS et qu'il est soutenu par des outils tels que https://testeum.com/ ou simplement par des forums de discussion.

Le point de vue d'Agilitest sur la programmation de la foule

Agilitest peut être un très bon candidat pour ATDD dans MP. Mobbers mettra alors progressivement à jour les scripts de test au fur et à mesure que l'interface du produit sera prête.

Grâce à une mise en place très simple de l'outil et à l'approche #nocode [Forsyth 2021], les Mobbers ne passent pas beaucoup de temps à créer l'environnement MP et à coder les scripts de test. Ils se concentrent simplement sur l'ajout de nouvelles fonctionnalités sur le produit. De plus, comme Agilitest ne requiert pas de compétences techniques fortes, les non programmeurs peuvent se joindre à l'effort de MP, ce qui permet aux personnes orientées vers les affaires de prendre part à l'atelier de MP.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍