Travail en équipe

L'organisation d'une équipe XP s'éloigne de l'organisation traditionnelle d'une équipe de développement, dans lequel différents développeurs travaillent sur des parties distinctes de l'application, coordonnés par un chef de projet responsable de l'intégrité de l'ensemble. Ce schéma de séparation des activités fait place dans XP à un schéma d'intégration, ou de collaboration intensive.

Définition et partage des tâches

Au début de chaque itération, le client, les développeurs et les testeurs se réunissent au cours d'une « réunion de planification d'itération ». La réunion commence par un point sur l'itération passée, puis le client décrit les scénarios à implémenter au cours de l'itération qui commence. S'ensuit une discussion sur les scénarios en question, au cours de laquelle l'équipe dresse une liste des tâches correspondantes.

Cette réunion se présente comme une réelle séance de conception collective, qui donne aux différents intervenants l'occasion d'aligner leur compréhension de ce qui doit être réalisé. Les besoins sont analysés à un niveau de détail plus fin, et les développeurs commencent à envisager les solutions techniques à mettre en place.

Au terme de cette réunion, l'équipe dispose d'une liste complète des tâches à réaliser dans l'itération. L'attribution des tâches se fait alors de manière auto-organisée : les développeurs choisissent eux-mêmes leurs tâches en cours d'itération, ce qui est rendu possible par deux pratiques fondamentales d'XP : la responsabilité collective du code, et le travail en binômes.

Responsabilité collective du code

Chaque développeur d'une équipe XP est susceptible de travailler sur toutes les parties de l'application, sans être bloqué par une éventuelle spécialisation initiale. Cette liberté d'action s'accompagne toutefois d'une responsabilité : chaque membre de l'équipe est garant de la qualité de l'ensemble de l'application – en particulier, chacun a le devoir de laisser le code qu'il parcourt aussi clair et propre que possible, pour faciliter le travail de ceux qui y interviendront par la suite.

Travail en binômes

Les développeurs d'une équipe XP travaillent quasiment tout le temps en binômes, c'est-à-dire à deux sur un même poste. L'idée n'est en aucun cas d'avoir une personne qui code pendant que l'autre la surveille, mais au contraire d'aboutir à un dialogue permanent par lequel les deux membres du binôme sont engagés à 100% dans leur tâche.

Les binômes changent fréquemment (typiquement tous les jours), de sorte que chacun est rapidement amené à travailler avec tout le reste de l'équipe. C'est cela qui rend possible la pratique de responsabilité collective du code : un développeur donné peut intervenir sur une partie de l'application qu'il ne connaît pas encore bien, sachant qu'il pourra s'associer à un binôme ayant déjà travaillé sur le sujet. Après quelque temps de ce traitement, chacun a une bonne vision d'ensemble de l'application et peut intervenir n'importe où.

Cette mécanique de rotation des binômes et de responsabilité collective du code conduit à une très grande souplesse en matière d'organisation d'équipe : le projet n'est plus bloqué par l'absence de tel ou tel individu, et toute l'équipe peut focaliser ses efforts sur une partie donnée de l'application en cas de besoin.

Stand-up meetings

Chaque jour, toute l'équipe se réunit pour un « stand-up meeting » d'une quinzaine de minutes - les participants se tiennent d'ailleurs tous debout (d'où le nom) pour éviter que cela ne traîne. A l'occasion de cette réunion, tous les membres de l'équipe prennent la parole pour faire un point sur l'avancement de l'itération, et surtout pour organiser la journée de travail à venir.

Règles de codage et métaphore

Des règles de codage sont définies et suivies par l'ensemble des développeurs. Elles donnent au code un aspect uniforme sur toute l'application, ce qui facilite le partage du code et le travail en binômes.

L'homogénéité du code ne se réduit toutefois pas au respect de quelques règles de programmation. L'équipe s'appuie en effet sur un système de métaphores commun, c'est à dire un ensemble d'expressions décrivant les acteurs du système et leurs interactions. Ce système de métaphores constitue :

• Un vocabulaire commun qui va permettre à toute l'équipe de parler des mêmes choses avec les mêmes mots. Par exemple, dans le monde des télécom, il faut définir ce qu'est un "noeud" d'un réseau et se servir de ce mot dans le cadre de la définition établie.
• Une métaphore de fonctionnement, par exemple : "le logiciel de contrôle de cette machine-outil fonctionne comme une machine à café".

Intégration continue

L'intégration des modifications menées par les développeurs est faite tous les jours. Dès qu'un binôme finit une tâche, il met à jour la version d'intégration en s'assurant que tous les tests de non-régression de l'application passent à 100%. La version "livrable" du logiciel évolue donc chaque jour, reflétant fidèlement l'état d'avancement des développements.

Le rôle du coach

Dans un contexte où l'équipe s'organise elle-même en définissant et en choisissant ses tâches, le rôle de chef de projet tel que nous le connaissons devient inadéquat. L'activité de coordination de l'équipe est prise en charge par un « coach », qui est davantage un facilitateur qu'un donneur d'ordres. Le but du coach est en effet de former l'équipe aux pratiques XP, et ensuite de travailler en permanence sur les pratiques de l'équipe pour améliorer son fonctionnement et l'amener à l'autonomie.

Les fonctions hiérarchiques et administratives du chef de projet font l'objet dans XP d'un rôle particulier : le « manager ». Le manager est le patron de l'équipe, il s'assure qu'elle dispose des moyens est nécessaire à son fonctionnement, fait l'interface avec le reste de l'organisation, et vérifie enfin que les résultats sont bien là.

Rythme durable

D'une part, une équipe fatiguée ne produit pas un bon travail. D'autre part, s'il y a trop de retard, c'est qu'il y a un problème de fond et il est illusoire de chercher à le masquer par davantage de travail. Pour ces raisons, l'équipe adopte la règle suivante : pas d'heures supplémentaires deux semaines de suite.