Pratique N°1 : Client sur site

Et bien nous sommes vernis, le client a demandé XP dans le "contrat" et connaissait déjà en partie les pratiques XP.
Le fait d'avoir le client sur site lui semblait une évidence autant que le choix de l' eXtreme Programming.
La société (client) est née à la suite d'une scission d'une plus grosse société, et donc la connaissance métier s'est partagée entre les deux nouvelles entités. Le choix d'une méthode agile, itérative a donc émergé. Il était difficile voire impossible pour la direction de l'époque de condenser dans un "cahier des charges" ce qu'elle attendait d'un développement aussi gros.

Difficulté à noter toutefois, le projet a commencé en fin 2005 avec une direction (Mr X), la direction a changé (Mr A). Mr A débarque et voit un projet qui dure depuis déjà 2 ans et ne voit pas où il s'arrêtera. La demande d'avoir un périmètre clair et identifié nous a été faite, le périmètre nous a été fournis sous la forme de procédure QUALIGRAM. Nous devons estimer la "charge" de ce périmètre. Nous avons utilisé COCOMOII (cocomo 2).
La fin du projet est prévue pour mi-2011. Donc nous sommes face à un projet agile complet (pas un ensemble de petits projets) de +- 6 ans?.

Revenons au client sur site :

les +

+ réponses rapides dans les 2 sens, nous vers le client et le client vers nous
+ transparence relative sur notre boulot
+ empreinte de l'ambiance qui reigne chez le client, sur un projet longue durée cela est assez important
+ impression de faire partie de la société cliente (impression partagée)
+ le client se familiarise avec notre façon de travailler
+ la proximité amène des questionnements plus profonds chez le client sur sa manière de travailler (le développement informatique participatif ou agile a souvent cet effet)

les -

- les crises internes de l'équipe de DEV sont directement perceptibles par le client
- l'équipe ne se sent pas toujours chez elle (à contrario du + faire partie du client), il existe toutefois bien une frontière, l'équipe ne peut pas toujours se "lâcher"
- l'équipe est parfois victime des petites vendetta côté client par la "priorisation" de tâches importantes

Conclusion : malgrès quelques points négatifs, qui sont là pour nous rappeler que l'agilité est une aventure humaine avant tout, le client sur site est plus que bénéfique pour un projet informatique. Il amène énormément de réflexions chez le client, une connaissance fine du métier client de la part de l'équipe, il nous arrive de participer à des réunions importantes et apporter un point de vue différent. Cela se traduit par une application très proche des désirs utilisateur/client.

Géographiquement, nos bureaux de développement sont dans les bâtiments du client.

Dans ce contexte de méconnaissance métier, sans être négatif, ou je dirais plutôt en période d'apprentissage de la part du client, nous avons créé des rôles qui ne sont pas tout à fait XP.

Il y a un chef de projet, désir du client et en même temps pratique automatique de la part de Thales.
Il y a 2 analystes dont le rôle et d'être le responsable client (product owner) et en même temps analyste fonctionnel, donc le principe est de dire quoi et plus ou moins comment le client veut ses fonctionnalités. Et le fait d'avoir le client à porter de main nous évite la dérive d'avoir des analystes dictateurs, mais bien messagers/décodeurs des exigences du client final.
Il y a également un architecte, qui est notre référence technique qui a comme rôle de penser à la structure de l'application, d'être en avance sur les technos qui vont être utilisées dans l'application et de ce fait, il nous a permis d'avoir dans la même équipe des profils senior et junior qui cohabitent dans un cadre XP. Nous étudierons ce sujet lorsque nous aborderons le binômage.

Voici une cartographie globale des interactions entre notre équipe et le client :


Quelles sont elles ?

Le comité de pilotage

Il réuni notre chef de projet, la direction générale du client, notre commercial. Il sert à passer en revue les différents indicateurs du projet (Bugs, Fonctionnalités,...), mais il sert surtout à donner les grandes priorités du client. Il se déroule toutes les 6 semaines, et donc il y a à chaque fois une livraison en production entre chaque comité de pilotage.

Les réunions fonctionnelles

Ces réunions rassemble les analystes, les décideurs fonctionnels et parfois les utilisateurs du système. Elles sont programmées toutes les deux semaines, donc à chaque itération. Cette réunion permet de définir les priorités de chaque service et donc les directeurs assistent également au comité de pilotage, et donc il sont conscient des priorités issues du comité de pilotage, ils doivent donc intercaler leur demande sans bousculer l'agenda du projet comité de pilotage. A la fin de la réunion nous obtenons le backlog des prochaines itérations.

Le planning game

Cette réunion nous permet d'estimer le backlog des réunions fonctionnelles. Cette réunion rassemble le chef de projet, les analystes, les développeurs client et fournisseur et un (des) représentant(s) du client afin d'apporter quelques précisions au besoin sur les spécifications des analystes. Le représentant du client est à 90 % assuré par les analystes. Et donc utilité de la réunion fonctionnelle préalable.

Stand-up

Réunion matinale qui permet à tout le monde de dire ce qu'il a clôturé la veille, ce qu'il va faire aujourd'hui et ce qui l'a bloqué ou le bloque encore.
Cette réunion rassemble toute l'équipe de DEV et parfois le client et donc comme souvent les analystes font office de représentant du client.

Binômage

Petit mot sur le binômage, dans ce contexte, il est un outil de communication entre les équipes (fournisseur/client). L'équipe du client doit également maintenir l'ancien système informatique. Les développeurs client ne sont donc pas disponible à plein temps. Le binômage leur permet donc de reprendre vite du service et se tenir à jour sur le code après une période d'inactivité sur le projet. Dernièrement un système alternatif a été mis en place, ils sont deux et donc une semaine sur deux il y en a un à temps plein dans le développement de l'application.