Gestion de projet – Vers les méthodes agiles
196
Comment appliquer ces principes collaboratifs avec des équipes offshore, et donc dispersées
géographiquement, avec des décalages horaires et des différences culturelles ? (suite)
Tout d’abord, les scrum meetings et les scrum of scrum sont mis en œuvre pour répondre au
besoin de communication orale.
Dans les cas des gros projets, nous pouvons considérer que nous avons déjà une notion d’équipe
au niveau de la feature team (une équipe par fonctionnalité). Chaque équipe est composée d’environ 7 personnes. Chaque feature team organise son scrum meeting quotidien, puis il y a un scrum
of scrum quotidien également avec le scrumMaster et un représentant de la feature team. Ce
peut être soit le feature lead (la personne qui a la vision complète de la fonctionnalité à développer et tester) si la notion de feature lead est existante dans l’équipe ou un représentant de
chaque feature team. Dans ce dernier cas, le représentant peut changer à chaque scrum of
scrum. Lorsque l’équipe contient entre 7 et 10 personnes, un seul scrum meeting est organisé.
Lorsque chaque pays a réalisé son scrum, un scrum meeting est organisé entre les scrumMasters ou un représentant volontaire de chaque équipe délocalisée. Ce scrum peut avoir lieu
soit quotidiennement, soit 2 à 3 fois par semaine. Cela dépend un peu du décalage horaire
entre les deux pays. C’est là qu’il faut bien en tenir compte. Il faut trouver un créneau commun
raisonnable entre les deux pays. Ce n’est pas trop compliqué entre la France et l’Inde car nous
avons entre 3 h 30 et 4 h 30 de décalage, cela devient plus compliqué lorsqu’il faut trouver un
créneau commun entre la France, l’Inde et les États-Unis par exemple. Ces scrum se font avec
des logiciels de communication comme Skype ou Messenger, souvent associés à une caméra
qui permet de visualiser les interlocuteurs à distance ou enfin par téléphone.
Dans le cas des scrum entre pays, la langue de référence est l’anglais, ce qui peut être un peu
« perturbant » pour les Français au démarrage, mais après plusieurs scrum, tout se passe bien.
Pour ce qui est de la communication écrite, nous utilisons très fortement Confluence Wiki.
Toutes les informations sont partagées dans des pages Wiki. Le processus défini est commun
à tous les pays. Les données projet sont organisées selon les disciplines UP, et il n’y a donc
pas de problème pour retrouver les informations. À partir de la page de garde, toutes les
données importantes ou utilisées tous les jours sont accessibles.
Le partage des données est essentiel et nous nous basons sur l’outil JIRA pour par exemple la
gestion du product backlog, de l’iteration backlog et enfin des défauts.
À tout moment, quel que soit le pays, on a donc l’état de référence. Il n’y a plus de problèmes
d’échanges par e-mail des données projets. Tout est en temps réel.
Le décalage horaire est ici mis à profit. Le pays qui est en avance du point de vue horaire peut
faire ses travaux, puis il existe une plage commune qui permet de faire des points/réunions,
puis l’autre pays continue ses activités. Pour les activités partagées sur un même sujet, cela
permet d’avoir une plage plus grande qu’une journée normale.
Dans la cadre de réunions techniques, nous utilisons un logiciel de communication type Interwise qui nous permet de partager des documents, avec possibilité d’avoir un stylo virtuel pour
souligner des points comme sur un écran dans une salle de réunion.
Pour répondre à la question sur les différences culturelles, une bonne pratique mise en place
consiste à effectuer des échanges entre les pays. Régulièrement, une personne d’un pays se
déplace pour 1 à 4 semaines dans l’autre pays afin de se rendre compte de la façon dont sont
rythmées les journées de travail, mieux connaître les habitudes de chaque pays, et ainsi mieux
comprendre les comportements. Cela permet de consolider la notion d’équipe unique même si
les personnes sont dispersées entre les pays.
GestProjInform Livre Page 196 Vendredi, 3. avril 2009 12:07 12
196
Comment appliquer ces principes collaboratifs avec des équipes offshore, et donc dispersées
géographiquement, avec des décalages horaires et des différences culturelles ? (suite)
Tout d’abord, les scrum meetings et les scrum of scrum sont mis en œuvre pour répondre au
besoin de communication orale.
Dans les cas des gros projets, nous pouvons considérer que nous avons déjà une notion d’équipe
au niveau de la feature team (une équipe par fonctionnalité). Chaque équipe est composée d’environ 7 personnes. Chaque feature team organise son scrum meeting quotidien, puis il y a un scrum
of scrum quotidien également avec le scrumMaster et un représentant de la feature team. Ce
peut être soit le feature lead (la personne qui a la vision complète de la fonctionnalité à développer et tester) si la notion de feature lead est existante dans l’équipe ou un représentant de
chaque feature team. Dans ce dernier cas, le représentant peut changer à chaque scrum of
scrum. Lorsque l’équipe contient entre 7 et 10 personnes, un seul scrum meeting est organisé.
Lorsque chaque pays a réalisé son scrum, un scrum meeting est organisé entre les scrumMasters ou un représentant volontaire de chaque équipe délocalisée. Ce scrum peut avoir lieu
soit quotidiennement, soit 2 à 3 fois par semaine. Cela dépend un peu du décalage horaire
entre les deux pays. C’est là qu’il faut bien en tenir compte. Il faut trouver un créneau commun
raisonnable entre les deux pays. Ce n’est pas trop compliqué entre la France et l’Inde car nous
avons entre 3 h 30 et 4 h 30 de décalage, cela devient plus compliqué lorsqu’il faut trouver un
créneau commun entre la France, l’Inde et les États-Unis par exemple. Ces scrum se font avec
des logiciels de communication comme Skype ou Messenger, souvent associés à une caméra
qui permet de visualiser les interlocuteurs à distance ou enfin par téléphone.
Dans le cas des scrum entre pays, la langue de référence est l’anglais, ce qui peut être un peu
« perturbant » pour les Français au démarrage, mais après plusieurs scrum, tout se passe bien.
Pour ce qui est de la communication écrite, nous utilisons très fortement Confluence Wiki.
Toutes les informations sont partagées dans des pages Wiki. Le processus défini est commun
à tous les pays. Les données projet sont organisées selon les disciplines UP, et il n’y a donc
pas de problème pour retrouver les informations. À partir de la page de garde, toutes les
données importantes ou utilisées tous les jours sont accessibles.
Le partage des données est essentiel et nous nous basons sur l’outil JIRA pour par exemple la
gestion du product backlog, de l’iteration backlog et enfin des défauts.
À tout moment, quel que soit le pays, on a donc l’état de référence. Il n’y a plus de problèmes
d’échanges par e-mail des données projets. Tout est en temps réel.
Le décalage horaire est ici mis à profit. Le pays qui est en avance du point de vue horaire peut
faire ses travaux, puis il existe une plage commune qui permet de faire des points/réunions,
puis l’autre pays continue ses activités. Pour les activités partagées sur un même sujet, cela
permet d’avoir une plage plus grande qu’une journée normale.
Dans la cadre de réunions techniques, nous utilisons un logiciel de communication type Interwise qui nous permet de partager des documents, avec possibilité d’avoir un stylo virtuel pour
souligner des points comme sur un écran dans une salle de réunion.
Pour répondre à la question sur les différences culturelles, une bonne pratique mise en place
consiste à effectuer des échanges entre les pays. Régulièrement, une personne d’un pays se
déplace pour 1 à 4 semaines dans l’autre pays afin de se rendre compte de la façon dont sont
rythmées les journées de travail, mieux connaître les habitudes de chaque pays, et ainsi mieux
comprendre les comportements. Cela permet de consolider la notion d’équipe unique même si
les personnes sont dispersées entre les pays.
GestProjInform Livre Page 196 Vendredi, 3. avril 2009 12:07 12