Le CRM prêt à l'emploi pour les petites entreprises et les startups.
Logiciel CRM
Productivité et qualité sont-ils antinomiques ?
3 minutes de lecture · Listen
Chez Square, 15 % des ingénieurs travaillent en binôme à plein temps
Il est humain de penser que 2 personnes qui travaillent sur le même sujet, ce soit anti productif. Mais qu’en est-il de la qualité ? Le pair programming est une des bonnes pratiques de l’extrem programming, méthode agile axée sur la réalisation d’un logiciel ou d’une application. Certains comme Facebook ou Square ont déjà adopté cette pratique outre Atlantique. Mais elle semble difficilement acceptée en Europe.
Est-il plus intéressant de programmer en binôme ou bien de faire de la revue de code a posteriori ? Gagne-t-on vraiment en temps et en qualité en programmant à deux ?
Une prise de conscience à retardement
Les développeurs cherchent constamment à optimiser leur code, développer plus vite et produire. Malheureusement pour les entreprises cela n’est pas forcément synonyme de qualité. Cependant, les cycles de développements courts ne signifient pas qu’il y ait négligence. Ainsi les méthodes agiles sont apparues et plus particulièrement le pair programming qui consiste à développer en binôme.
Si cette méthode semble avoir fait ses preuves du côté de la Silicon Valley, les entreprises françaises sont réticentes à la mise en place de cette pratique. Mais nous observons peu à peu une prise de conscience et une mise en œuvre qui tend à se répandre.
Le travail en binôme est-il réellement une perte de temps ?
Le concept du pair programming est qu’il y a un driver et un observer. Le driver est celui qui écrit le code et l’ observer celui qui vérifie. Autant dire deux personnes pour faire le travail qu’une seule serait en mesure de faire.
Eh bien non, ce n’est pas vraiment cela ! Le driver écrit bien le code, mais l’observer ne se contente pas uniquement de regarder.
L’observer a un œil critique, pose des questions, vérifie s’il n’y a pas d’erreurs. Le driver est challengé sur ses choix d’implémentation et le binôme se rend donc mutuellement responsable des décisions prises. Donc tout le temps qui serait passé a posteriori et nécessiterait un temps d’implication plus allongé est réduit du fait de la double vérification.
Et la qualité dans tout ça ?
La revue de code a depuis longtemps fait ses preuves quant à l’amélioration de la qualité des logiciels. Mais selon la forme adoptée, elle intervient malheureusement parfois trop tard dans le cycle de développement. Le pair programming intègre la revue de code tout au long du processus de développement. Cela permet d’accroitre la qualité du code produit.
Quelques conseils
Afin de tirer le meilleur parti de cette pratique, Pivotal Labs nous donne quelques conseils comme permuter régulièrement les rôles de driver et observer afin que chacun reste impliqué totalement dans sa tâche ; de courtes réunions organisées en début de journée où tout le monde se tient debout et en cercle pour favoriser les échanges ; et surtout tester au maximum et plus encore.
Attention à éviter certains pièges comme se laisser déconcentrer, discuter, et ainsi perdre le niveau d’implication et l’efficacité. Penser à faire des pauses pour éviter la surchauffe. Être un observer inactif, le manque d’échange au sein du binôme fait perdre tout l’intérêt du pair programming.
Malgré le développement des méthodes agiles, les pratiques de ces méthodes comme le pair programming s’imposent plus difficilement. Néanmoins certaines entreprises se lancent et commencent à en tirer les bénéfices.
En savoir plus :
