Le client sur place

XP préconisait à l'origine un client sur place — un véritable utilisateur ou son représentant, physiquement présent avec l'équipe.

Pourquoi une telle exigence?

Le développement logiciel est une prise de décision constante :

• Comment ce cas limite devrait-il se comporter?
• Lequel de ces deux designs est meilleur pour les utilisateurs?
• Ce bogue vaut-il la peine d'être corrigé ou est-ce une limitation connue?
• Qu'est-ce qui est plus important : la fonctionnalité A ou la fonctionnalité B?

Si le client n'est pas disponible, les développeurs devinent. Ils devinent mal. Ils construisent la mauvaise chose. Ou ils attendent, bloquant les progrès jusqu'à ce qu'ils puissent obtenir une réponse.

Des clients disponibles :

• Débloquent les décisions en quelques minutes, pas en quelques jours
• Détectent les malentendus tôt
• Prennent des décisions de priorité en contexte
• Bâtissent la confiance grâce à une collaboration étroite

Le rôle de client XP comporte à la fois des droits et des responsabilités.

Droits du client :

• Connaître le coût estimé de chaque story
• Connaître la vélocité de l'équipe et quand les choses seront terminées
• Changer les priorités à tout moment (dans les limites de l'itération)
• Annuler le projet et obtenir un système fonctionnel (tout ce qui a été fait)
• Voir les progrès à travers un logiciel fonctionnel, pas seulement des rapports

Responsabilités du client :

• Être disponible pour répondre rapidement aux questions
• Prendre des décisions de priorité lorsqu'on le demande
• Fournir des critères d'acceptation pour les stories
• Accepter les compromis lorsque la portée dépasse la capacité
• Donner rapidement des commentaires sur le logiciel livré

C'est un partenariat. Le client n'est pas un intervenant distant qui lance des exigences par-dessus le mur. C'est un membre de l'équipe qui prend des décisions quotidiennement.

En pratique, le « vrai client » est souvent indisponible. Il a un emploi. Il ne peut pas rester assis avec les développeurs toute la journée.

Voici le représentant du propriétaire de produit — quelqu'un qui représente le client :

• Gestionnaires de produit
• Analystes d'affaires
• Propriétaires de produit (terminologie Scrum)
• Experts internes en la matière

Le modèle de représentant fonctionne lorsque :

• Le représentant comprend vraiment les besoins des utilisateurs
• Le représentant a l'autorité de prendre des décisions
• Le représentant est vraiment disponible (pas surbooké)
• Les vrais clients fournissent des commentaires réguliers (démos, séances de rétroaction)

Le modèle de représentant échoue lorsque :

• Le représentant ne comprend pas le domaine
• Le représentant ne peut pas prendre de décisions sans escalade
• Le représentant est trop occupé pour être disponible
• Les vrais clients ne voient jamais le logiciel

Les tests d'acceptation sont la façon dont les clients et les développeurs vérifient qu'ils se comprennent mutuellement.

Pour chaque story, le client définit des critères d'acceptation :

• Étant donné [ce contexte]
• Lorsque [cette action se produit]
• Alors [ceci devrait être le résultat]

Ceux-ci deviennent des tests exécutables. Lorsque les tests réussissent, la story est terminée. Aucun débat sur le fait qu'elle soit « vraiment terminée ».

Avantages :

• Exigences sans ambiguïté (si le test réussit, ça fonctionne)
• Documentation vivante (les tests décrivent ce que le système fait)
• Sécurité de régression (les tests détectent quand le comportement change)
• Engagement du client (écrire des critères nécessite de réfléchir)

Dans XP moderne, les tests d'acceptation sont souvent écrits en collaboration entre le client et les développeurs. Le client décrit le comportement; les développeurs aident à traduire sous forme testable.

Les équipes modernes sont souvent distribuées. Le client « sur place » est un canal Slack, un appel Zoom ou un message asynchrone.

Pour que ça fonctionne à distance :

• Surcommuniquer (ne rien supposer d'évident)
• Utiliser la vidéo pour l'interaction face à face lorsque possible
• Créer des moyens à faible friction pour poser des questions (clavardage plutôt que courriel)
• Enregistrer les décisions pour qu'elles soient retrouvables plus tard
• Respecter les fuseaux horaires (ne pas s'attendre à des réponses instantanées à 3 h du matin)

Implication asynchrone du client :

• Écrire des questions claires avec du contexte
• Offrir des options plutôt que des questions ouvertes
• Établir des attentes pour le temps de réponse
• Utiliser des documents pour les décisions complexes (plus facile à réviser en asynchrone)

Le principe demeure : minimiser le temps entre la question et la réponse. Le travail à distance rend cela plus difficile mais pas impossible.