Programmation collective - 5 développeurs sur un seul ordinateur !

La réalisation d'expériences pour améliorer nos processus fait partie de notre travail quotidien. Ainsi, lorsque j'entends parler de quelque chose qui pourrait nous aider à nous améliorer, je veux l'étudier. Au début de l'année 2019, j'ai rejoint la convention Domain Driven Design Europe. Pendant les pauses, j'ai beaucoup discuté avec d'autres participants, principalement des développeurs.

Mob Programming de la convention de l'année précédente est revenu sur le tapis. Les développeurs étaient vraiment, vraiment enthousiastes à propos de la programmation mob : plusieurs développeurs travaillant dans la même pièce sur un seul PC. Ils ont expliqué à quel point ces sessions leur avaient permis d'apprendre et d'évoluer en tant qu'équipe. C'était un signal clair qui m'a incité à en savoir plus. Après cela, j'ai décidé que nous allions l'expérimenter.

L'hypothèse est un élément essentiel d'une expérience. Sans elle, vous ne pouvez pas savoir si l'expérience a réussi. Ma théorie était que la programmation collective nous aiderait à partager les connaissances entre les développeurs tout en construisant un code propre.

J'ai planifié et préparé notre première session de programmation collective, ce qui n'était pas si difficile :

• Mettez un ordinateur relié à un grand écran

• Placez une table devant l'écran.

• Ajoutez cinq sièges à la table.

• Mettez quelques collations et fournitures sur la table.

Et nous étions là, cinq développeurs dans une pièce avec un seul ordinateur :

Que s'est-il passé lors de notre première session de programmation mob ?

Wesley s'assied près du clavier (nous utilisons son PC) et se voit automatiquement attribuer le rôle de driver. Le pilote est un dispositif d'entrée intelligent : il peut taper mais n'est pas autorisé à prendre des décisions. Les autres développeurs se voient attribuer le rôle de navigateur. Ce sont eux qui discutent de ce qui doit se passer et qui disent au conducteur ce qu'il doit faire.

Le conducteur est un dispositif d'entrée intelligent : il peut taper mais n'est pas autorisé à prendre des décisions

Nous commençons à travailler sur une simple histoire d'échauffement où nous devons supprimer un contenu obsolète dans le pied de page du site.

Les navigateurs indiquent à Wesley de démarrer Docker. Nous voyons immédiatement un message d'erreur. Wesley explique que cela arrive parfois, mais que c'est toujours résolu avec quelques tentatives. Nous ne réessayons pas, mais les navigateurs nous expliquent quels paramètres modifier. Désormais, Docker démarre toujours sans erreur.  ;

Wesley écrit sur une note autocollante ce qu'il a appris sur Docker. Il place cette note autocollante sur la grande feuille de papier appelée Learnings.

J'écris sur une note autocollante que le fait que Docker ne démarre pas nous empêche d'avancer. Je l'envoie au Waste Snake, une grande feuille de papier sur laquelle est dessiné un serpent. Sur cette feuille, vous placez des notes autocollantes décrivant tout ce qui retient la foule de la programmation réelle :

Après 12 minutes, un signal sonore retentit. Tout le monde doit se déplacer vers la droite. Le conducteur devient navigateur, et l'un des navigateurs devient conducteur. C'est un peu compliqué et il faut un peu de temps pour se remettre en route. Mais après quelques changements, on s'y fait beaucoup mieux.

Nous terminons l'histoire et commençons à travailler sur la suivante : Yii2 view causes bogus comments in HTML, which causes HTML invalidation. Une histoire intéressante. Elle a déjà été reprise deux fois par des développeurs différents, mais ils sont restés bloqués. Tout le monde apporte sa pierre à l'édifice. Finalement, nous résolvons le problème d'une manière qui satisfait tout le monde.

Après deux heures, la session se termine.

Qu'avons-nous appris de notre première session de programmation collective ?

Nous organisons une réunion rétrospective pour discuter de ce qui s'est bien passé et de ce que nous pouvons améliorer. L'essentiel est que nous ayons corrigé l'histoire mieux et plus complètement en une seule itération que lorsqu'une seule personne aurait travaillé dessus.

Nous avons corrigé l'histoire mieux / plus complètement en une seule itération que lorsqu'une seule personne aurait travaillé dessus.

Tout le monde se sent stimulé pendant la rétrospective. Nous avons tous aimé l'expérience. Il devient évident que la programmation collective nous aide à partager nos connaissances tout en construisant un code propre.

La plupart des apprentissages étaient assez évidents, comme lorsqu'un raccourci était inconnu du pilote, ou la configuration d'outils pour vous aider à être plus efficace. Il est devenu évident qu'il est facile d'ajouter du gaspillage à votre propre processus de développement en utilisant des solutions de contournement si un système se comporte de manière inattendue. Cela confirme la nécessité d'adopter le Kata d'amélioration.

D'autres apprentissages ont été plus subtils. Par exemple, trouver des moyens de diviser un problème difficile en problèmes plus petits. Ou les suggestions sur la manière de travailler réellement en fonction des tests en créant d'abord un test qui échoue au lieu d'ajouter simplement un test par la suite.

L'expérience a réussi ! La prochaine session est immédiatement planifiée

Le niveau de communication entre les navigateurs et le conducteur a été l'un des points les plus délicats à régler. Il n'est pas nécessaire de tout expliquer, surtout pour les développeurs les plus expérimentés, mais il ne faut pas non plus qu'un développeur débutant ait l'impression d'être plongé dans le bain. Mais il ne faut pas non plus qu'un développeur débutant ait l'impression d'être jeté dans le grand bain. Au fil du temps, la foule apprend à s'adresser à chaque conducteur de la bonne manière.

Programmation de la mob à distance

Aux Pays-Bas, nous sommes actuellement en lockdown. Nos bureaux sont fermés et tout le monde travaille à distance. Cela rend impossible la programmation collective telle que décrite ci-dessus, car nous ne pouvons pas être dans la même pièce.

Cependant, nous voulions toujours organiser des sessions de programmation en équipe. En procédant par essais et erreurs, nous avons trouvé les éléments suivants pour une excellente session de programmation de foule à distance :

• Tout le monde a une webcam, et tout le monde l'allume pendant une session.

• Nous utilisons Whereby pour héberger nos réunions parce que vous pouvez partager votre écran tout en voyant les flux de caméra des autres.

• Le conducteur se connecte sur un ordinateur dédié par le biais d'une connexion de bureau à distance (nous avons créé un compte d'utilisateur mob sur le réseau interne pour cela).

• Nous avons créé un compte d'utilisateur mob distinct pour Git. Il est ainsi très facile de changer de rôle.

Comment puis-je expérimenter cela dans mon propre environnement de travail ?

De tous les articles, blogs et livres électroniques que j'ai lus sur la programmation mobile, je ne peux que conseiller de lire ces deux-là :

• Le Mob Programming Guidebook (récemment renommé Ensemble Programming Guidebook) par Maaret Pyhäjärvi.

• Mob Programming - A Whole Team Approach par Woody Zuill.

Ensuite, il vous suffit de choisir une date avec votre équipe et de l'essayer. Bonne chance !