ClientSurSite

Un article de Agora2ia.

Idéalement, le client XP est une personne de l'équipe client. Concrètement, il peut être un développeur qui abandonne le développement pour embrasser le rôle de client XP.

Durant le planning game le client a comme fonction d'exposer les scénarios qu'il souhaite voir réalisés durant l'itération. En fin de planning game, le client doit leur attribuer des priorités, une fois ces scénarios estimés par les développeurs, afin d'identifier ceux qui tiennent dans l'itération.

Durant l'itération, le fait qu'il soit sur site (dans le même espace que l'équipe, dans ce que l'on appelle la « war room »), lui permettra d'être directement accessible par les développeurs pour des questions, et donc les réponses. Cela implique que le client XP ait à la fois la connaissance pour répondre, mais aussi le pouvoir de prendre des décisions (ne pas faire telle fonctionnalité, la faire autrement, la faire après telle autre...).

Idéalement le client écrit les tests release avec un binôme de développeur. En pratique, il les conçoit et se sont les développeurs qui les écrivent.

Il faut bien comprendre que cette pratique a pour but d'améliorer le feedback, de raccourcir le délais entre une remarque du client et la prise en compte par l'équipe (dans un sens) ou une question de l'équipe et la réponse du client (dans l'autre sens).

XP n'est pas opposée à la rédaction de documents. Elle la considère simplement comme un d'atteindre un but : la capture et le transfert de la connaissance. Mais XP lui préfère d'autres moyens : le client sur site en est un. Maintenant si le client a un réel besoin de documentation, on pourra toujours identifier une tâche à cet effet, la documentation devenant alors, et dans ce cas seulement, une partie intégrante de ce qu'il faut livrer au client, de son besoin réel.

Il faut également avoir à l'esprit que le travail de réflexion et d'appropriation du métier qui se fait d'habitude pendant la réalisation du document de spécifications fonctionnelles, mais aussi celui d'élaboration au cours de la rédaction des spécifications techniques, est dans le cas d'une équipe XP un travail de tous les instants. Il n'y a rien de figer et d'irrévocable, tant sur le plan fonctionnel que sur le plan technique. Il est donc difficilement envisageable d'avoir un client sur site qu'une partie du temps. Une question pouvant émerger à tout instant, il est optimal que le client soit constamment sur site.


Paul et Mick dans l'eXtreme

Par contre, le client n'étant pas sollicité en continue, 100% du temps, mais étant une ressource comme les autres, il serait un luxe de l'affecter 100% de son temps au rôle de client. Par expérience, une configuration qui fonctionne bien est de donner la casquette de client au chef de projet. Il a bien souvent la connaissance métier. Il ne reste plus qu'à lui obtenir le pouvoir de décision. Il pourra ainsi Il pourra ainsi consacrer et donc imputer, à juste titre, un pourcentage, seulement, de son temps au rôle de client, mais être disponible à tout instant.

Toujours par expérience, il est a mon avis souhaitable que le client n'ait pas de compétences techniques, cela afin de garantir un cloisonnement des compétences, une séparation des responsabilités. Ainsi: Le client ne sera pas tenté de s'investir dans la conception ou le développement, pour ne pas dire être directif. Le développeur devra, pour se faire comprendre, vulgariser ses dire, ce qui implique d'abord de les maîtriser mais aussi de les remettre en question en les abordant sous un autre angle : nous sommes très proche de la pratique de la Métaphore. Enfin, cela renforce le fait que les tests release doivent aborder l'application comme une boite noire.

Toujours dans l'idée de favoriser la communication, le client participe au stand-up meeting quotidien. J'ai parfois entendu dire qu'une trace écrite via un document de spécifications fonctionnelles validée ou un mail avec les bonnes personnes en copie, sont impératifs pour se prémunir d'un « mauvais coup ». Cela est un « bad smell » qui traduit une déviance dans la notion de contrat gagnant-gagnant. Cette problématique, dépasse le cadre de cette pratique. En effet, les deux parties peuvent se prémunir d'un échec bilatérale, de manière contractuelle, et établir ainsi un meilleur état d'esprit, de confiance: c'est le « Optional Scope Contract ».