Aujourd'hui, je n'ai pas passé une minute seul devant mon ordinateur; nous sommes actuellement trois développeurs dans l'équipe et j'ai travaillé avec tout le monde, sur chaque ordinateur.La matinée a commencé avec un de mes collègues avec l'étude de Simian un outil qui permet de détecter les duplications de code. Nous avons travaillé une bonne heure ensemble avec pour conclusion que l'outil n'était pas forcement le plus approprié à notre langage de programmation Delphi mais que sur le principe, ça serait très intéressant d'intégrer cette métrique à Hutson, notre moteur d'intégration continue.
Puis, un collègue de l'équipe support en déplacement chez un client pour l'installation de notre logiciel sur plusieurs serveurs a appelé pour que nous cherchions la cause d'une erreur que notre client reproduisait facilement. L'équipe a mobilisé toute son énergie pour d'une part reproduire le problème, d'autre part trouver la solution. Pour l'anecdote, nous n'avons pas eu besoin de modifier notre logiciel car l'erreur provenait d'un champ de la base de données qui était mal dimensionné! La satisfaction collective était extraordinaire; quel plaisir de montrer à notre client que nous savons répondre très rapidement à ses problèmes; de plus, sortir un collègue d'un potentiel embarra renforce grandement le plaisir partagé!
La journée a continué avec la création d'un nouveau programme d'installation en pair-programming et s'est terminée sur l'automatisation de sa construction. Nous ne créons pas très souvent de nouveau programme de ce type alors le fait d'être en paire nous a permis de ne pas rester bloqué car les idées arrivent beaucoup plus vite à deux que seul.
La pratique du pair-programming n'est pas naturelle. Elle demande que les membres de l'équipe se fassent confiance car programmer en paire, c'est s'exposer. Il faut donc faire un petit effort au début puis très vite, on se rend compte qu'un travaille réalisé en paire permet d'obtenir des très bons résultats et pour un temps total probablement inférieure au temps qu'une même activité aurait demandé à une personne seule. On peut très vite préférer travailler à plusieurs plutôt que seul.
Le partage qui résulte du pair-programming a de multiples avantages. Il permet d'aquérir des compétences, d'avoir une bonne propriété collective du code, de trouver les meilleures solutions, d'avoir du fun en partageant les "micro-succès" et j'en oubli !
Le travail collaboratif est une très bonne étape. Le pair-programming demande encore plus de relations et d'interractions entre les membres d'une équipe; il permet de soutenir la première valeur du Manifeste Agile :
"L’interaction avec les personnes plutôt que les processus et les outils".
Aucun commentaire:
Enregistrer un commentaire