Précédemment, dans la partie 1 de cet article, nous avons parlé de l'importance de favoriser la communication entre les équipes pour mettre tous les membres de tes équipes sur la même longueur d'onde.
Aujourd'hui, dans cette partie 2, nous discuterons de la création de processus pour les projets de développement distribué. Pour mener à bien ces projets, il faut mettre en place des processus bien définis et bien documentés pour t'assurer que toute l'équipe fait les mêmes choses de la même manière.
Tous les membres de l'équipe doivent suivre les mêmes processus. Si tu ne disposes d'aucun processus documenté, tu ne peux pas t'attendre à ce que tes équipes de développement à distance soient en phase avec ta façon de faire.
Voici un exemple de liste d'éléments à documenter avant de commencer à travailler avec des équipes à distance :
Comme tu peux le voir, le but de cette liste est de permettre aux gens de faire ce qu'ils doivent faire au quotidien tout en nécessitant le moins d'aide possible. La première étape consiste à documenter les processus et l'étape suivante consiste à diffuser l'information. Une façon d'y arriver est d'avoir un wiki ou une autre page Web interne où les membres de l'équipe peuvent consulter les processus et les avoir à portée de main.
Définir tes processus c'est bien, mais ça ne veut rien dire si personne ne les suit. Il faut que les leaders renforcent continuellement ces processus et prennent l'initiative de communiquer avec les équipes à distance lorsque le cours normal des choses n'est pas suivi. Place la barre de qualité là où tu en as besoin, puis assure-toi que les équipes atteignent cette barre.
Tu auras autant de succès avec ton équipe de développement distribué que lorsque tu travailles avec ta propre équipe. Si tu n'as pas de processus et que ton équipe vit dans le chaos, devine quoi? Tes efforts de développement distribué seront tout aussi chaotiques sinon pires, car tu viens d'ajouter un groupe de personnes supplémentaires à ton équipe.
J'ai déjà été dans une situation où je faisais partie d'une équipe à distance, et l'équipe principale avait peu ou pas de processus en place. Notre équipe étant certifiée CMM niveau 5, nous avions la capacité de définir des processus. Ainsi, chaque fois qu'on rencontrait une situation sans processus, on en créait un. Lorsque l'équipe principale rencontrait les mêmes problèmes que nous et a appris que nous avions des processus, elle a adopté les nôtres comme méthode de travail.
Lorsque tu commences à travailler avec une nouvelle équipe, tu dois planifier des sessions de travail où certains de ces développeurs se rendent à ton bureau. Pendant ce séjour, ils pourront avoir du temps en face à face avec les membres de ton équipe et en apprendre davantage sur les processus. Pour être efficaces, ces sessions doivent être planifiées et organisées. Détermine le temps nécessaire pour les éléments essentiels et prépare un programme de formation standard. Si moins d'une semaine suffit pour passer en revue l'essentiel, fais-les venir pendant une semaine et confie-leur des tâches pour leur permettre d'interagir avec l'équipe.
Le défi avec ces sessions de formation est que tu ne pourras peut-être pas consacrer de ressources à la formation. Dans ces cas, une solution consiste à les associer à certains de tes meilleurs collaborateurs pendant une semaine et à les laisser apprendre les processus en les voyant en action. Donc d'intégrer la formation à tes processus.
Si tu n'as vraiment pas de temps pour la formation de nouveaux employés, je te recommande fortement de ne pas le faire du tout. Il y a des coûts liés à la formation. Cela peut se transformer en un gros investissement de temps et d'argent, alors assure-toi que celui-ci est productif. Considère également cela comme une chance pour ton équipe de faire bonne impression et de commencer à établir une relation de travail avec les membres de l'équipe à distance.
En termes de processus, il est essentiel d'effectuer des revues des exigences formelles, du design et du code. Tu peux les considérer comme des points de contrôle pour valider le travail à effectuer ainsi que pour confirmer les estimations initiales. Implique plusieurs équipes dans les revues et fais des efforts pour éviter le syndrome de « Big Brother », où une équipe dit aux autres quoi faire sans tenir compte de leurs commentaires.
Les revues doivent également être organisées. Tout le monde devrait avoir eu suffisamment de temps pour examiner les artefacts avant que la revue ait lieu. Propose un modérateur qui garde une trace de tous les problèmes qui surviennent pendant la revue, puis qui assure le suivi avec les personnes à qui sont assignés ces problèmes jusqu'à ce qu'ils soient résolus.
Tu dois impliquer plusieurs personnes dans les revues afin d'avoir plusieurs points de vue. Pour les exigences et les revues, implique des personnes des équipes de gestion de produits, de documentation, d'assurance qualité et de développement. Pour les révisions de code, implique plusieurs développeurs ainsi qu'un testeur d'assurance qualité.
Le développement distribué consiste à outiller les gens et à faire d'eux une extension de ton équipe. Tu verras rapidement ce qui marche et ce qui marche moins dans tes façons de faire. Pour réussir, tu dois identifier ce qui ne fonctionne pas et trouver des moyens de le faire fonctionner. Tu as besoin de processus documentés que tous peuvent suivre.
Les problèmes auxquels tu fais face au quotidien avec ton équipe locale sont les mêmes que ceux auxquels tu seras confronté lorsque tu travailles avec des équipes à distance. Autant un enfant est le reflet de ses parents, le développement distribué est le reflet de tes pratiques de développement actuelles.
Tu dois instaurer un climat de confiance entre tes équipes et leur donner les outils pour réussir. Pour ce faire, tu dois pousser l'idée que vous êtes une seule équipe travaillant ensemble et non plusieurs équipes travaillant sur le même projet.
Enfin, tu as besoin de leaders dans chaque équipe qui ont le souci du bon fonctionnement du projet et de l'équipe. Ces leaders contribueront à créer un environnement de collaboration où les gens se sentiront intégrés dans l'équipe.
Ceci est une version éditée du tout premier article publié par Steffan. Le Dr. Dobbs Journal a publié une version raccourcie de l'original dans son numéro d'août 2007.
