Dans un article précédent, j'ai essayé d'introduire le Pair Programming.
Ceux qui s'essaient à cette formidable pratique professionnelle, se sont sûrement demandés à quel moment il fallait permuter les binômes.
Peut-être même certaines équipes ne permutent quasiment jamais leurs binômes.
Je vais essayer de vous montrer comment, en introduisant la pratique de Revue de Pair, nous pouvons rythmer le binômage dans une équipe.
Le procédé est simple.
Imaginons une équipe de 4 personnes, 2 fois 2 binômes.
Chaque binôme part sur une histoire utilisateur distincte.
Dès qu'un binôme a fini une histoire utilisateur, il demande un "Pair Programming Swapping" :
Chaque binôme échange un de ses membres.
Celui du binôme ayant fini l'histoire utilisateur passe dans le binôme qui n'a pas encore fini et ensemble continuent le travail en cours. L'autre rejoint l'équipe qui a fini l'histoire utilisateur et engage une revue de pair (peer review) avec l'aide du développeur resté "sur place". Une fois la revue de pair effectuée, ils partent sur une nouvelle fonctionnalité.
Cette pratique a deux avantages :
- elle rythme le travail des binômes d'une équipe
- elle permet un partage du code plus étendu, par le changement régulier de binôme et les revues de pair effectuées régulièrement.
Cette revue de pair apporte "l'oeil neuf" de la personne n'ayant pas participée au codage de cette histoire utilisateur, mais ne prend pas trop de temps car elle est guidée par un des membres du binôme ayant codé cette fonctionnalités.
Cette pratique met aussi en évidence qu'un nombre pair de développeurs est plus approprié pour une équipe voulant s'adonner à la pratique du pair programming.
Aucun commentaire:
Enregistrer un commentaire