pair programming

pair programming : Travail à deux sur le même code, efficace pour transmettre un savoir ou traverser une partie particulièrement risquée.

Famille « Développement ». La définition ci-dessus suffit pour suivre une réunion. La suite sert à écrire une exigence que personne ne pourra interpréter à sa façon.

À quoi sert pair programming

pair programming fait partie des notions invisibles à l’usage et bien réelles dans la facture. Ce point décide de la facilité avec laquelle une équipe reprendra le code dans deux ans, avec d’autres développeurs.

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

La traduction en exigences

Le cahier des charges gagne à formuler « pair programming » en résultat attendu plutôt qu’en solution : ce que l’application doit savoir faire, à quel moment, et comment on le vérifiera à la recette.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les versions minimales d’iOS et d’Android supportées, qui décident des API disponibles.
• Le sort du code : dépôt remis, licences des bibliothèques, cession des droits à la livraison.
• Les bibliothèques tierces autorisées, et qui paie leurs licences dans la durée.
• La procédure de mise à jour de l’application une fois qu’elle est publiée.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Ce que ça change au moment de la recette

À la recette, pair programming se contrôle avec les mêmes gestes à chaque version. Ce sont ces gestes qu’il faut écrire une fois pour toutes.

• Demander à voir le dépôt de code et son historique, pas une capture d’écran.
• Lancer l’application sur un appareil ancien, pas seulement sur le dernier modèle.
• Suivre soi-même, une fois, la documentation d’installation remise.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Erreurs fréquentes

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Imposer une technologie dans le cahier des charges sans écrire le besoin qu’elle sert.
• Accepter un devis où le développement iOS et le développement Android tiennent dans une seule ligne.
• Repousser les tests automatisés à la fin du projet, c’est-à-dire ne jamais les écrire.
• Changer de socle technique en cours de route sans rechiffrer le reste du planning.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• JSI
• Trafic de recherche
• Flutter
• React Native
• Swift

Questions fréquentes

Qu’est-ce que « pair programming » ?

Travail à deux sur le même code, efficace pour transmettre un savoir ou traverser une partie particulièrement risquée. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Faut-il l’imposer dans le cahier des charges ?

Écrivez le besoin et la contrainte, pas la solution. Si un choix technique précis est indispensable, à cause de l’existant ou des compétences internes, justifiez-le en une phrase : un prestataire pourra le respecter, ou proposer mieux avec un argument.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.