1 + 1 = 3, le « pair programming » appliqué au web
Par Mathieu Pillard et Stéphane Angel
- Mini-conf (15 mn) :
Liens connexes
Le sujet
Depuis la nuit des temps, de Laurel et Hardy à Olive et Tom en passant par Stone et Charden, les hommes et les femmes ont compris que l'union faisait la force. Pour autant, le sujet reste relativement tabou dans l'informatique et les métiers du web en particulier, et bon nombre d'entre nous n'osent pas franchir le pas et continuent de travailler chacun dans leur coin.
Cette mini-conférence a pour but de présenter les attraits du « pair programming », et de montrer ce que le concept apporte au quotidien quel que soit le métier, mais aussi ses limites.
Présenté par
Transcription
(Merci à Tanguy Lohéac pour la transcription.)
Stéphane Angel (SA) : Bonjour Stéphane Angel, avec moi Mathieu pillard.
Développeurs à Libé.
Aujourd’hui on va vous parler de pair programming.
Mathieu Pillard (MP) : alors en fait, on a deux versions de nos slides. On a la version propre qu’on va donner aux organisateurs après, et puis on a celle qu’on va vous montrer. [Rire]
Alors sachez qu’on n’a pas du tout honte d’avoir laissé du comics sans ms, c’était impossible de trouver la bonne font pour faire la marque jaune. On présente nos excuses à tous les ayants droits des images qu’on a repiquées, trafiquées etc. mais l’occasion était vraiment trop belle vue le nombre de duos qu’il y a dans les BD, dans les films etc.
SA : beaucoup d’ayants droit. [Rire]
Donc le pair programming, pour résumer en deux mots, quelques mots, travailler ensemble à deux sur un même ordinateur.
Donc le pair programming c’est un sous-ensemble de l’extreme programming. Une série de méthodes et pratiques agiles.
Pair programming c’est un peu comme le rallye : c’est un pilote et un copilote. La seule différence c’est que dans le pair programming on change tout le temps… On échange tout le temps de place.
Donc aujourd’hui c’est un peu un retour d’expérience. On est venu au pair programming un peu par hasard, sans connaître la théorie.
Donc on va vous présenter tout ça aujourd’hui.
Mais pourquoi le pair programming ?
MP : alors pour faire simple, 1 + 1 = 3. Grosso modo en associant nos forces on va réussir, non pas aller plus vite, enfin pas forcément en tout cas, mais aller plus loin, entre guillemets. Bon, après cette slide promis on arrête le bullshit marketing etc. et on se concentre sur le vrai contenu. [Rire]
Et donc, les bénéfices :
SA : donc les bénéfices. Premier bénéfice la productivité. Forcément vous êtes deux sur un écran, vous allez pas passer votre temps sur diaspora, app.net, euh pardon, Facebook, Twitter, Gmail etc. Vous êtes obligés quelque part de travailler.
MP : et en plus, s’il y en a un qui a un petit coup de fatigue ou quoi, ben forcément il y a l’autre qui peut le motiver, ou qui peut juste prendre la main temporairement pour donner un petit coup de boost, voilà. Donc on comble un peu les faiblesses de chacun comme ça.
SA : autre avantage : l’inspiration. Des fois on cherche une solution, on trouve pas.
Le fait d’être à deux et de communiquer permet de trouver. Un certain nombre d’études montre que les programmes réalisés, le code réalisé en pair programming, est plus efficace, moins bugué, plus facile à lire.
MP : plus simple aussi souvent. Et surtout en plus, c’est un peu à l’épreuve du futur en fait. Parce que quand vous êtes deux à avoir bossé sur quelque chose et que vous devez revenir six mois après dessus, ben si vous êtes deux avoir bossé dessus, forcément vous êtes deux à connaître le code, et vous aurez moins de soucis que quelqu’un d’autre qui débarque totalement sur le code que vous avez écris tout seul pendant six mois, et qui n’a aucune idée du coup de ce qui se passe. Et en fait, quand on disait que c’était un retour d’expérience, on a eu le problème entre guillemets.
Mais bien après avoir fait du pair programming, où dépendant de comment on compte, on a la moitié ou les deux tiers de l’équipe qui sont partis, puisqu’on a deux développeurs qui sont partis.
Et en fait, vu qu’on avait fait la majeure partie du code ensemble, finalement, on n’a pas eu trop de problèmes à reprendre après.
SA : alors comment on fait du pair programming ? C’est super simple ! Tout d’abord pour commencer pas d’interférence. Comme on l’a dit tout à l’heure pas de Twitter, pas de Gmail, pas de Facebook.
Si possible pas le téléphone, l’idée c’est vraiment de s’isoler, si possible dans une salle séparée.
Juste rester joignable en cas de souci.
MP : donc il faut 2 personnes, [sourire] un ordinateur. Donc on a mis deux interfaces chef clavier, donc c’est vous.
SA : c’est vous !
MP : et c’est tout. C’est extrêmement simple.
SA : juste pour revenir, au niveau de l’ordinateur, un portable ça marche bien.
On peut bouger. L’idéal : un poste, deux écrans miroirs, clavier, souris sans fil comme ça.
MP : en fait ça c’est si vous êtes riches.
SA : voilà.
MP : sinon le portable ça marche.
SA : bon, quant au déroulement, donc un pilote, un copilote, comme on le disait au début.
Le pilote, la seule différence c’est qu’il a juste les doigts sur le clavier. Car les deux personnes en même temps travaillent. C’est pas un qui bosse l’autre qui regarde et chacun son tour.
Il y a un échange permanent sur ce qui se fait, ce qui va être fait, pourquoi c’est fait.
MP : donc, comme on disait aussi c’est important de ne pas avoir quelqu’un qui serait coincé dans le rôle du pilote au clavier. Il faut faire tourner, il faut faire revenir, ou changer quand vous le sentez.
Comme je le disais quand quelqu’un a un coup de fatigue ou quoi, ou juste quand vous comme ou juste quand vous changez de concept, quand changez de petites tâches. Hop ! Vous inversez vos deux chaises ou alors vous passer le clavier et voilà.
SA : et voilà ! c’est prêt, vous savez faire du pair programming
MP : et alors en plus, ce qui est… Enfin, en le faisant, vous arriverez à cette étape-là. Cette étape-là c’est quand vous êtes tous les deux dans la zone, entre guillemets, et que vous êtes à fond dedans, vous voyez pas le temps passer.
vous vous rendrez pas compte tout de suite, mais après vous aurez l’impression d’avoir juste travaillé comme des dieux quoi. C’est vraiment… [Rire]
c’est vraiment exceptionnel !
SA : en fait le moment ultime, c’est quand vous finissez les phrases de l’autre.
MP : voilà. [rires]
SA : ou quand… [Rire et applaudissements] ce que vous êtes en train d’écrire l’autre est en train de le penser en même temps. Ça peut arriver.
MP : bon, tout n’est pas complètement rose.
Il y a des difficultés.
SA : la fatigue. Parce que bon, contrairement à ce qu’on pourrait croire, le pair programming c’est assez fatigant. Parce qu’il y a pas de distraction.
Vous êtes vraiment en permanence concentré, en train de travailler sur votre écran. Vous aurait peut-être moins tendance à faire des pauses. Donc, c’est plutôt épuisant.
La solution ben…
MP : prendre des pauses.
SA : ne pas hésiter à prendre des pauses. C’est pas parce que…
Alors le temps peut passer très vite mais c’est vraiment très important.
MP : faites un peu attention ! Allez de temps en temps prendre un café ! Pas forcément à deux, vous faites comme vous voulez.
Un autre problème qui peut arriver classiquement c’est que vous vous entendez pas avec la personne, ou vous commencez à vous engueuler sur un truc ou etc. donc keep cool !
C’est de la discussion etc. effectivement il y a des fois où ça se passera pas bien la personne en face, ou plutôt à côté, vous la sentez pas du tout. Tant pis ! C’est pas grave. Comme disait Thibault hier, apprendre l’art de la fuite.
Ben on peut changer de pair programmeur si vraiment ça se passe mal.
SA : il faut pas hésiter, s’il y a un malentendu à moment donné, à se séparer, aller bosser chacun dans son coin et se revoir après pour voir les pistes qui ont été choisies. C’est une solution qui peut résoudre votre problème.
MP : vas-y tu veux le faire ?
SA ouais ! Du coup pour continuer sur ces fameux moments où vous avez des désaccords. Des fois il est pas résolvable. Ou alors vous n’avez pas forcément d’idées sur quelle piste prendre.
Donc il faut pas hésiter à faire appel à un arbitre, une troisième personne qui va trancher pour vous.
D’où ce slide.
MP : voilà ce qui est important en tout cas, c’est de pas perdre de temps, rester coincé sur un débat où chacun campe sur ses positions, parce que ça ça sert à rien effectivement.
Et quand vous êtes tout seul vous avez moins le problème.
Donc pas hésiter vraiment à faire trancher.
En fait le plus gros problème, et c’est un peu le cœur de notre présentation, c’est que le pair programming n’est pas non plus adaptable à tous les projets, toutes les situations etc.
en fait, il est plus indiqué pour un gros projet, ou alors un projet où vous savez pas trop où est-ce que vous allez arriver à la fin en fait, plus qu’une petite tâche répétitive que vous avez déjà faite 20 fois. Ça c’est pas vraiment la peine d’appeler quelqu’un en renfort quoi.
C’est vraiment quand vous sentez que tout seul vous allez avoir du mal quoi.
SA : ça peut servir pour. vous avez une idée dans l’équipe, et partir sur un proof of concept, ou un algorithme un peu complexe et on sait pas trop exactement vers où on veut aller. Pour ça c’est vraiment pas mal d’être à plusieurs.
MP : un autre problème, c’est le travail à distance. On a honnêtement assez peu d’expérience nous avec le travail à distance. Donc on peut pas vraiment vous en parler beaucoup. Mais ce qu’on peut vous dire c’est que vraiment de base c’est effectivement plus compliqué.
Vous êtes pas à côté de la personne. Maintenant il y a des gens qui ont fait les outils sympas.
Sinon il y a les solutions de partage d’écran etc. mais honnêtement on est pas vraiment compétent pour en parler donc on va faire comme si le problème n’existait pas.
SA : le risque est vraiment du coup, comme il n’y a pas la personne exactement à côté, c’est de se laisser… d’être plus distrait et d’être moins impliqué quand on n’est pas le maître ou pilote sur le moment.
Une autre difficulté c’est quand ben vous débarquez, vous revenez de vacances, vous venez d’être embauché sur un gros projet. C’est pas évident de s’y mettre.
Mais ça doit pas empêcher le pair programming.
Dans ce cas-là le pilote va avoir un peu plus la maîtrise et l’autre va suivre.
Ou alors la solution peut être de mettre celui qui n’est pas au courant du projet aux commandes et en étant guidé par…
MP : l’épreuve du feu.
SA : ça marche… Ça peut être pratique pour quand un débutant vient d’arriver dans la boîte pour le faire rentrer dans le projet.
MP : voilà si vous avez un projet énorme etc. pour faire rentrer un débutant ça peut être extrêmement pratique de faire des petites séances de pair programming comme ça. Pour le mettre dans le bain.
Pour essayer de le dégoûter aussi on sait jamais enfin comme vous voulez. [Sourires]
SA : oui et il y a un autre cas.
On se dit pourquoi le pair programming dans ce cas-là ?
Des fois, il peut arriver que vous bossiez seul, de chez vous par exemple, qu’il y ait personne qui veuille bosser avec vous.
MP : tout le monde est en vacances.
SA : en vacances… Typiquement le genre de cas où ça peut se présenter c’est… Où là vous avez vraiment besoin de quelqu’un, on a tous connu ça :
on tombe sur un truc compliqué, on y passe des heures, on trouve pas la solution, on prend une pause, on va manger, et on revient le lendemain, et d’un seul coup en deux minutes ça se règle. Et du coup, l’autre solution est d’en parler à quelqu’un.
Mais quand vous êtes seul… Il y a le canard.
MP : le concept du canard. [sourires]
SA : voilà, donc normalement.
MP : bon pour ceux qui connaissent pas. Ben je sais pas, t'en n’as pas un ?
SA : j’ai oublié le petit canard en plastique dans mon sac…
MP : On avait un super petit canard en plastique. dommage ! Vous le verrez pas !
SA : dommage !
MP : Le concept du canard en plastique ou du canard en caoutchouc, au choix, c’est en fait que quand vous avez un problème et que vous ne savez pas… Vous êtes sur un bug depuis 1h, vous vous arrachez les cheveux, vous en pouvez plus. Vous essayez de l’expliquer à un canard en plastique, un ours en peluche, ou éventuellement un collègue si vous en avez un.
SA : ou un tigre des neiges. [Rires]
MP : moi personnellement j’ai un tigre des neiges en peluche voilà. Et en fait rien que le fait de réexpliquer depuis zéro à quelqu’un comme s’il n’avait pas suivi le truc, vous allez trouvé le problème tout seul dans 90 % des cas. En fait.
Et à tel point que quand vous avez un humain en face, des fois ça change rien En fait.
Il va rien vous dire.
Et juste vous vous aller faire : merde ! voilà.
SA : typiquement moi ça m’arrive souvent d’appeler Mat sur un problème :
Dit, là j’ai un souci.
voilà j’essaie de faire ça.
Ah c’est bon merci. [Rire]
parce que juste le fait de le penser, de sortir du processus dans lequel on est engagé permet souvent de trouver une solution.
MP : voilà donc c’est un peu le pair programming quand vous êtes tout seul.
SA : voilà ! Ça marche ! [Rires]
MP : bon c’est pas tout ça mais… il faut…
SA : Maintenant vous savez pourquoi, comment, et résoudre les problèmes. Si vous voulez pratiquer va falloir…
MP : il va falloir le faire.
Pour ça il va falloir convaincre a priori, sauf si vous êtes votre propre boss, tant mieux pour vous, enfin si vous trouvez deux personnes qui sont leur propre boss. Le premier argument vous pouvez donner à vos boss c’est que vous allez travailler mieux.
En fait, généralement, le fait d’être à deux etc. donc on a vu que ça motivait, inspirait etc. mais surtout, vous allez vous sentir mieux et du coup il y a des chances que le projet se passe mieux aussi quoi.
Je sais pas si tu…
SA : non désolé ! [rire]
MP : c’est pas grave.
SA : désolé j’ai vu apparaître le panneau 5 mn ça m’a perturbé.
Un autre argument pour convaincre c'est Agile. En fait je vais pas détailler parce que juste le mot agile, votre patron il sait pas ce que c’est, mais il sait que c’est bien. [Rires] Donc vous lui dites que le pair programming c’est agile… [applaudissements]
MP : c’est à la mode en tout cas.
SA : ça devrait marcher.
MP : sinon en fait, un argument sympa c’est que c’est juste super facile à tester quoi ! Vous avez forcément un ordinateur, a priori.
Donc vous vous mettez 5 minutes, 1h, 2h, une journée, une semaine, à deux sur un truc est juste vous voyez ce que ça donne.
Ou si votre patron est vraiment un radin, vous faites ça un week-end, sur votre temps libre, avec un pote. Comme ça au moins vous, vous serez convaincu de l’intérêt déjà. Donc vraiment, c’est hyper facile à mettre en place.
Ça coûte pas grand-chose de tester et de voir ce que ça donne.
SA : donc, nous notre expérience bon…
MP : j’ai tout spolié.
SA : t’as tout spolié tout à l’heure. donc bon voilà. C’est le fait que la moitié de l’équipe est partie et on en a pas vraiment pâti au niveau de notre travail puisqu’on connaît le code en question.
MP : on a beaucoup souffert au niveau émotionnel.
SA : voilà juste l’émotionnelle. On souffre encore.
MP : On souffre encore. Seb, si tu nous regardes…
Pour finir… [Rires applaudissements]
Vous avez sûrement tous faim.
Le pire c’est que je ne me souviens même plus ce que cette slide disait donc ça tombe bien.
SA : si ! tu disais que… Non ça je sais plus… Que vous voyez si vous voulez vraiment convaincre vous pouvez montrer cette vidéo à votre patron.
MP : ah oui c’est pour ça je m’en souviens plus oui. Peut-être que vous devriez pas la montrer. De toute façon on va donner des slides, voilà. Et surtout, on s’en est rendu compte à la fin, après avoir écrit tout le texte.
Mais Wikipédia a un super article sur le pair programming en anglais. [Rires]
Avec une tonne de liens vers les études etc. qui… Bon, il y en a qui disent tout et leur contraire. mais grosso modo, pour donner des arguments c’est pas mal. Et donc, Wikipédia plus nos slides propre, entre guillemets, sans les mêmes et les trucs comme ça, ça peut être pas mal quoi.
SA : voilà ! [Applaudissements]
MP : stop stop stop stop stop !
Nan c’est pas fini ! [rires]
SA : une dernière petite chose.
MP : non parce qu’en fait on a pas du tout parlé de web. Pourquoi ?
Parce qu’en fait, le pair programming s’applique au Web comme il s’applique à n’importe quel autre domaine.
Le Web a plein de spécificités.
Mais dans le contexte du pair programming en fait ça revient au même que vous écriviez du CSS, du JS, du PHP ou du Python côté serveur ou du Ruby pour les plus fous d’entre vous, voire du Java. Ça marchera tout aussi bien. Et en fait notre propre expérience le prouve puisque nous c’est ce qu’on a fait sur tous ces domaines-là.
Que ce soit du front, du back etc. on la fait et, ça marche très bien. Donc il y a vraiment aucune raison de ne pas s’y mettre. Voilà
SA : cette fois c’est vraiment fini. [Applaudissements]
Question 1 :
Intervenant salle (IS) : tu as parlé de… Quand tu accueilles un débutant, enfin un débutant niveau projet, donc ça peut être intéressant soit de lui donner la main soit qu’il regarde dans un premier temps. Moi ma question c’est plus quand tu as un vrai gap technique entre les deux pilotes, est-ce que ça peut quand même fonctionner ? Ou est-ce qu’on se retrouve pas dans un cas où le senior va devoir dicter en permanence au junior ce qu’il doit coder ? Est-ce que ça va faire progresser le junior, ou est-ce qu’il faut éviter qu’il y ait une trop grosse différence de niveau entre les deux ?
MP : alors, déjà, si le senior il commence à trop dicter au junior, il faut que le junior il prenne un marteau et lui tape sur la main ou quelque chose.
Parce que c’est effectivement absolument ce qu’il faut éviter dans le pair programming. Donc, vous, en tant que senior, entre guillemets, vous devez essayer d’éviter sa. Et en tant que junior, si jamais vous êtes en train de pair programmer, vous devez lui dire non ! Mais non ! Laisse-moi essayer de trouver ! On trouve ensemble, mais tu trouves pas tout seul.
SA : il faut que le senior ait conscience du gap, qu’il l’aide, tout en sachant que c’est pour le bien quoi.
IS : ouais mais c’est humain. Quand tu vois quelqu’un qui va te coder une fonction en 50 lignes de code alors que tu sais qu’on peut le faire en 5 lignes.
A un moment tu vas vouloir lui dire.
MP : tu vas lui dire ! Tu vas lui dire ! Tu commences à lui laisser le truc. Petit à petit etc. tu… Même tu peux le laisser commencer à coder en 50 lignes. Et lui dire bon, je t’ai laissé 5 minutes faire ton truc. [sourires]
Je veux pas faire de mal mais… Non mais… C’est de l’humain effectivement.
SA : pour ce genre de gap en fait il faut que les deux aient vraiment conscience que ça peut ne pas marcher. Que les deux soient prêt.
MP : nous, quand on l’a fait, il y avait des fois où l’un d’entre nous connaissait beaucoup mieux le sujet, beaucoup mieux le langage, la techno etc… ça marche très bien si effectivement les deux ont conscience du gap et qu’ils travaillent tous les deux à résoudre le problème au lieu d’avoir un qui dicte tout à l’autre. Voilà.