Salut et bienvenue dans ce nouvel épisode de Code Garage. Je m'appelle Nicolas
Bonnard Bernard et aujourd'hui on va parler du Per Programming. Le Per
Programming, qu'on peut appeler programmation en binôme, en français,
c'est une méthode de travail qui consiste à faire travailler deux
développeurs ou développeuses ensemble sur une même machine et un même écran
plutôt que de les faire travailler en parallèle sur des postes de travail
différents. C'est une méthode qui rentre dans le cadre du développement agile
comme c'est indiqué justement dans le manifeste pour le développement
logiciel agile et qui résonne à la phrase les individus et leurs
interactions plus que les processus et les outils. Alors pour celles et ceux qui
ne sont pas parfaitement familiers avec le concept d'agile, ça arrivera dans un
prochain épisode de Code Garage donc voilà il faudra juste être un peu
passion. Mais en tout cas oui effectivement c'est une forme de
collaboration qui est bien plus étroite que ce qu'on a l'habitude de voir dans
le monde du développement en général et qui pousse on va dire les participants
à échanger et à transmettre leurs idées et leurs solutions de manière plus
récurrente et plus fluide. Mais évidemment malgré les avantages que ça
apporte, c'est une pratique qui a encore du mal à rentrer dans les mœurs des
entreprises, des éditeurs de logiciels, d'entreprises de services etc. Et c'est
pour ça qu'on va voir aujourd'hui les avantages que ça peut apporter et comment
faire pour que la mise en place de ce perprogramming, ça se fasse
dans les meilleures conditions tout simplement. Donc le principe il est
simple, on a bien compris que ça consiste à faire travailler deux
développeurs sur une même machine mais comment ça se passe exactement sur une
session de travail concrète. En fait en perprogramming on va retrouver deux
rôles bien distincts pour chacun des développeurs. On a le driver, le
conducteur et l'observer, l'observateur en français. En gros aucun des deux rôles
est à négliger parce que c'est un peu comme dans la navigation d'un packbo.
Les deux métiers sont complémentaires. Il y en a un qui va observer les
éventuels écoils, les problèmes à éviter et en essayant de trouver la
meilleure route à prendre et l'autre va tourner le governornail pour suivre la
route qui est tracée on va dire par l'observateur et en ressentant la force
du vent etc en jetant un œil sur l'état des machines pour être sûr que tout se
passe bien. Alors évidemment contrairement à la conduite d'un bateau,
les deux développeurs ils doivent échanger fréquemment de rôles pour
profiter d'une session efficace, et pas tomber dans des travers pour avoir
plus tard. Et on va maintenant détailler chacun de ces rôles donc le
driver, le conducteur, son rôle c'est d'écrire majoritairement du code et du
code propre. Il peut travailler très efficacement parce que justement il a
l'appui de l'observateur qui va lui pouvoir lui servir de guide et lui va
pouvoir se concentrer. Évidemment c'est lui qu'à entre les mains le clavier et la
souris, on lui attribue plutôt le côté tactique qu'on oppose au côté
stratégique et il doit pouvoir justement se concentrer sur l'optimisation
du code, la documentation et tout ce qui touche au code pur on va dire mais
surtout au code propre et bien organisé. L'observateur lui son rôle ça va être
de réfléchir à la structure du projet dans son ensemble, de faire justement les
choix stratégiques ça peut être en matière de design mais aussi faire une
review un peu continue des lignes de code au fur et à mesure qu'elles sont tapées
par le driver. Alors le problème c'est que ce rôle là il est souvent pris à la
légère alors qu'en réalité il est indispensable à l'équilibre du binôme et
à la qualité du logiciel du logiciel final quoi. Donc on va voir un
petit peu les bonnes pratiques, quelques conseils pour que la mise en place du
parcours gaming ça se fasse sans douleur dans votre projet, dans votre
entreprise et que vous en bénéficiez justement que vous voyez les
bénéfices de ça. La première bonne pratique c'est justement de changer
ses perspectives. La plus grosse peur qui freine les entreprises à mettre en
place cette pratique ça reste la rentabilité jour homme du développement
du projet mais en fait ça c'est un problème de perspective parce que si on
fait travailler deux développeurs sur une même machine on écrira
potentiellement effectivement deux fois moins de code dans le même temps. Je dis
bien potentiellement parce qu'en réalité les gains de cette pratique ils peuvent être
gigantesques si on sait où et quoi regarder parce que mettre en place un bon
pair programming ça permet d'écrire du code plus robuste et plus efficace, de
diminuer les coûts liés au support et au débegage, d'avoir évidemment une
base de code plus facilement réutilisable et plus propre parce qu'elle
est mieux réfléchie mais surtout de former ses développeurs en continu,
développeurs et développeuses évidemment, en continu et beaucoup plus
efficacement. Après il y a des effets de bord on va dire ça permet d'améliorer
la communication et le team building au sein des équipes et aussi de faire
rentrer la patience et la pédagogie dans les valeurs de l'entreprise parce que
on a des entreprises où c'est pas forcément des valeurs prédominantes
et donc ça permet de les faire rentrer encore un peu plus en douceur. Une autre
bonne pratique ou en tout cas un conseil c'est de l'introduire progressivement.
Si vous êtes développeur, développeuse ou serve de projet on va pas forcément
imposer le pair programming comme quelque chose d'exclusif on va pas faire
que ça. Vous pouvez très bien proposer de le mettre en place un jour par semaine
pour commencer par exemple et ensuite si la méthode fonctionne bien au sein de
vos équipes et de votre entreprise, essayez d'augmenter progressivement le
nombre de jours dans la semaine par exemple jusqu'à arriver à votre point
d'équilibre ça peut être deux jours, trois jours, quatre jours, cinq jours, ça
peut être que pour certaines équipes, c'est à vous de voir.
Et on peut aussi penser à le mettre en place ponctuellement pour certaines tâches
sensibles qui requièrent une plus grande vigilance, une qualité de code
encore plus élevée, ça peut être quand on touche à des systèmes financiers ou peu
importe. Évidemment la règle principale, je dirais que c'est de pas forcer les
développeurs et les développeuses. Il y a certains devs qui sont très patients,
très pédagogues de nature et il y en a d'autres qui ne sont pas du tout.
Donc le but c'est pas d'imposer le pair programming à des devs qui ne seraient pas
à l'aise avec le concept. Vous pouvez commencer à faire germer l'idée,
ok, mais laissez-leur le temps de voir les résultats de la méthode et peut-être
qu'ils changeront d'avis à la longue. Vaut mieux pas de pair programming qu'un pair
programming qui se passe mal évidemment. La avant-dernie conseil c'est de mélanger
les niveaux. L'apprentissage et la montée en compétence c'est des vrais points positifs
de cette méthode, c'est pour ça qu'on la valorise et mélanger différents niveaux,
c'est encore plus bénéfique. Faire travailler un développeur expérimenté avec un développeur
junior par exemple, ça va permettre à l'un de progresser plus rapidement et d'acquérir les
bons réflexes plus vite. Et en même temps les interrogations du développeur junior ou de la
développeuse, ça permettra de remettre en question peut-être les procédés établis des fois un
petit peu par dogmatisme depuis trop longtemps et qui ont plus forcément lieu d'être aujourd'hui
ou tout simplement de remettre le développeur senior encore plus dans un mood un petit peu
d'apprentissage et en tout cas de transmission de connaissance. Alors ce qu'il faut faire attention
juste quand on mélange les niveaux c'est à ce que le binôme fonctionne bien et que le junior
soit pas simplement relégué au rôle d'observateur à de vitamétard d'âme parce que sinon c'est
vrai que c'est annul tout bénéfice du pair programming, on n'a plus l'intérêt à ce moment-là,
c'est juste quelqu'un qui regarde. Et donc pour compléter ça évidemment c'est d'alterner les
rôles, c'est le dernier conseil que je vais donner parce que l'alternance des rôles c'est
capital et ça doit se faire normalement sur des périodes relativement courtes. Quand je dis
relativement courtes ça veut dire moins d'une demi journée sans être trop court non plus,
on va pas faire des sessions d'un quart d'heure. En fait ça permet aux conducteurs d'avoir le temps
d'accomplir une ou plusieurs tâches et en même temps à l'observateur de garder une stimulation
suffisante parce que effectivement c'est un rôle légèrement plus passif, en tout cas physiquement
et plus passif. Moi mais c'est un choix très personnel, je dirais que la période d'optimale ça
doit être entre peut-être une demi heure et une heure mais évidemment chaque binôme va trouver son
rythme de croisière, son idéal pour que la session soit la plus efficace, stimulante et agréable
possible, évident. J'espère que cet épisode vous aura plu, vous aura été utile et peut-être qu'il
aura permis à certains développeurs et certaines développeuses de commencer à mettre en place
le perprogramming dans leurs équipes, dans leur entreprise. Sur ce je vous souhaite une très bonne
journée et à la semaine prochaine pour un nouvel épisode. Salut !