L'équipe agile distribuée
Scott W. Ambler
Les problèmes de communication sont votre principal risque.
Scott examine les my...
Figure 1 : Taux de réussite des projets pour les équipes agiles distribuées. Plus une équipe est distribuée et plus le
ris...
hiérarchie informée.
Démarrer un Projet Agile Distribué
Une des toutes première choses par laquelle une équipe agile disci...
car il devient nécessaire d'écrire plus de documentation, de tenir plus de revues de documentation,
de fournir plus d'effo...
travers des graphes de reste à faire, de tendance des défauts, d'état du 'build', et des statistiques
d'allocation des res...
travers des graphes de reste à faire, de tendance des défauts, d'état du 'build', et des statistiques
d'allocation des res...
Upcoming SlideShare
Loading in...5
×

Ddj Architecture & Design The Distributed Agile Team

1,333

Published on

Agile, équipe distribuée

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,333
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Ddj Architecture & Design The Distributed Agile Team"

  1. 1. L'équipe agile distribuée Scott W. Ambler Les problèmes de communication sont votre principal risque. Scott examine les mythes entourant le développement logiciel agile. Scott travaille en qualité de Practice Leader Agile Development pour IBM Rational. Traduction par Emmanuel Hugonnet de l’article The Distributed Agile Team avec l’aimable autorisation de Scott Ambler et de Jon Erickson du Dr. Dobb’s Journal. Parmi les mythes qui entourent l'agilité, celui qui laisse à penser qu'elle ne s'applique qu'à de petites équipes regroupées géographiquement reste largement diffusé. L'étude Dr. Dobb's 2008 Agile Survey (www.ddj.com/architect/207600615) a prouvé le contraire, les réponses indiquent, en effet, que les stratégies agiles sont appliquées avec succès par des équipes comptant plus de 200 membres et qu'une grande part des équipes agiles sont distribuées. Dans l'article "Agile Large Teams" (www.ddj.com/architect/208700162), j'ai proposé différentes stratégies pour organiser de grandes équipes agiles, et ce mois-ci je vais vous décrire les expériences vécues au sein d'une équipe de développement IBM, à la fois distribuée et agile. Si un membre de l'équipe travaille à un autre étage, ou depuis chez lui, ou dans un autre bâtiment que le reste de l'équipe, alors votre équipe est distribuée. La Figure 1 résume les résultats de l'étude Dr. Dobb's 2008 Agile Survey, qui montrent que les chances de succès se réduisent avec la distribution géographique de l'équipe. Bien que cela soit alarmant, ce n'est pas surprenant – plus grande est la distribution et plus élevé est le risque. Cependant, il faut noter que beaucoup d'équipes arrivent avec succès à développer en mode agile distribué. Comprendre les risques Le taux de réussite moins élevé des équipes de développement distribuées vient principalement des problèmes de communication qui augmentent. Même dans le cas où l'équipe est distribuée sur un même site et peut facilement se réunir si le besoin s'en fait sentir, il existe des risques de communication comme le fait d'avoir des priorités différentes, ou sur la compréhension des exigences. De nombreuses entreprises vont utiliser le papier et demander à ce qu'on écrive des spécifications détaillées pour se prémunir contre de tels risques, mais comme la théorie sur la richesse des média l'a montré depuis des années, la documentation est le moyen le moins efficace pour communiquer entre personnes, et peut même augmenter le risque.
  2. 2. Figure 1 : Taux de réussite des projets pour les équipes agiles distribuées. Plus une équipe est distribuée et plus le risque d'échec de votre projet augmente. Les projets dont les membres de l'équipe sont loin les uns des autres, où il faut passer par l'avion pour réunir l'équipe, peuvent souffrir des décalages horaires et des différences culturelles. Pour minimiser ces risques, j'ai pour habitude de poser des questions ouvertes pour savoir si les autres comprennent ou non le sujet de la conversation. En particulier, je ne pose jamais de question dont la réponse est oui ou non, car un 'oui' peut avoir une variété de sens selon la culture :  Oui, je vous entends  Oui, je comprends ce que vous dites  Oui, je comprends et je suis d'accord avec vous Lorsqu'il faut travailler avec des personnes distantes, il est recommandé de leur demander de résumer la conversation par écrit, même si c'est un simple courriel avec une liste de points/choses, pour valider la compréhension commune des décisions. Le manque de confiance dans les capacités de ceux avec qui vous ne travaillez pas directement ou que vous ne connaissez pas bien, est aussi un problème, cela devient particulièrement vrai lorsque plusieurs services ou entreprises sont concernés. Cette méfiance transparaitra sous la forme de spécifications détaillées à écrire et valider pour les personnes distantes, du temps passé sur l'aspect légal des contrats entre entreprises, et au contraire du manque de discussions sur le processus suivi par 'chaque coté'. Ayant été consulté par de nombreuses SSII, ainsi que par leurs clients, je peux assurément dire que tous ceux qui se retrouvent impliqué dans un projet off-shore bénéficieraient grandement de discussions franches et ouvertes sur leur véritable manière de travailler. La plupart des SSII aimeraient fournir une meilleure qualité de service à leurs clients en travaillant de manière plus agile, mais elles croient à tord que leurs clients veulent travailler de la manière bureaucratique traditionnelle. De la même façon, leurs clients croient que les SSII ne peuvent travailler ainsi, pensant à tord qu'une entreprise respectant CMMI ne peut être agile. Mon conseil en la matière est de parler à votre partenaire, et de voir ensemble comment travailler plus efficacement. Pour illustrer mon conseil je veux partager avec vous certaines de mes expériences avec une équipe de développement d'IBM travaillant sur un outil de gestion de projet par les métriques de nouvelle génération, autour de la technologie de la plateforme Jazz (www.jazz.net) et qui permet de réconcilier les différentes méthodologies de gestion de projet: agile, traditionnelle, hybride et tous les niveaux intermédiaires. L'équipe projet se compose actuellement de 30 membres repartis sur Bangalore, Boston et Toronto. Les itérations se font à une fréquence d'une toutes les trois semaines, avec une démonstration interne hebdomadaire pour s'assurer un retour régulier des parties-prenantes distribuées, et une revue de l'état d'avancement toutes les six semaines pour maintenir leur
  3. 3. hiérarchie informée. Démarrer un Projet Agile Distribué Une des toutes première choses par laquelle une équipe agile disciplinée va commencer – et c'est d'autant plus vrai pour une équipe distribuée – est de modéliser une vision globale à la fois de l'architecture et des exigences. Dans le cas de notre équipe projet, elle a identifié avec le responsable produit une liste des principales histoires d'utilisateur ce qui lui a permis de définir le périmètre initial, et à partir de celui-ci elle s'est donnée une direction pour son architecture technique en définissant les principaux concepts architecturaux. Commencer par concevoir l'architecture permet à l'équipe distribuée de s'organiser efficacement comme nous le verrons par la suite. Les équipes agiles disciplinées commencent aussi par une planification de haut niveau afin d'identifier les dépendances importantes et les dates de livraison – vous n'avez pas besoin d'un diagramme de Gantt monolithique avec plus de 1000 tâches, mais vous devez avoir réfléchi à tout cela. Les équipes efficaces intègrent activement les développeurs dans la mise au point de cette planification (ils font partie de la même équipe après tout), en effet, ils font tout leur possible pour prendre en compte tous les coûts associés, et en particulier ils n'oublient pas les risques à faible probabilité mais fort impact qui sont souvent à l'origine de la mort des projets. Regrouper l'ensemble de l'équipe physiquement au lancement du projet est aussi une stratégie essentielle. Ainsi cela vous permet de créer des liens entre les membres de l'équipe, de connaître les personnes avec qui vous allez travailler ce qui facilitera la communication par la suite, et de mieux comprendre la situation sur le terrain. C'est sûr que de regrouper les gens en les faisant venir par avion augmente les coûts initiaux, cependant c'est un investissement qui sera rapidement rentabilisé par la réduction des risques encourus. Dans mon expérience ce qui coûte moins cher dans ces voyages est de le faire, alors que cela coûte plus cher de ne pas les faire ce qui augmente les risques liés à la communication par la bureaucratie et la documentation. Hélas cette stratégie est souvent sacrifiée sur l'autel du gain financier à court terme, aux dépends des risques pris sur le projet. Organiser une équipe agile distribuée Une bonne pratique pour organiser les équipes distribuées, décrite dans "Lean Developement Gouvernance", est d'organiser votre équipe selon l'architecture afin de réduire les communications entre les différentes sous-équipes. Lorsque l'on analyse les flux de communication dans une équipe de développement logiciel, on s'aperçoit que la majorité des échanges se fait entre les personnes qui réalisent ensemble un sous-système, aussi organiser votre équipe en suivant l'architecture réduit les risques liés à la communication. C'est l'une des raisons pour laquelle il faut commencer par modéliser l'architecture – en identifiant les sous-systèmes, et en investissant un peu de temps pour définir les interfaces de chacun d'entre eux, vous permettez à vos sous-équipes de se concentrer sur leur tâche. Les responsables de l'architecture de chacun des sous-systèmes doivent se coordonner pour modifier les interfaces ensembles, c'est un sujet que je décris en détail dans mon article de Juillet 2008 (www.ddj.com/architect/207600615). Cette manière de gérer l'architecture s'appelle 'API First' dans Eclipse Way, une méthodologie agile pour les équipes distribuées. Une grave erreur serait d'organiser l'équipe autour des spécialités techniques, par exemple avoir une équipe d'analystes métier, une équipe de concepteurs, une équipe de testeurs, etc. et de faire transiter les tâches entre ces équipes de spécialistes. Cette stratégie augmente la bureaucratie, donc le coût,
  4. 4. car il devient nécessaire d'écrire plus de documentation, de tenir plus de revues de documentation, de fournir plus d'efforts en termes de traçabilité, etc. pour permettre à cette organisation d'équipe de fonctionner. Cela a aussi pour effet de favoriser le rejet de la faute sur les autres équipes en cas de problème – un logiciel qui fonctionne est nettement plus concret et mesurable que de la documentation, ce qui facilite la tâche lorsqu'il s'agit de déterminer la valeur produite par une équipe, ou son absence. Le seul cas où vous pouvez briser cette règle, serait le cas d'un projet off-shore avec des tests indépendants, comme décrit dans "Scaling Test-Driven Development" (www.ddj.com/architect/205207998), lorsque vous avez une petite équipe de testeurs de qualité pour réaliser des tests complexes en parallèle des développements. Avoir une petite équipe qui réalise les tests en parallèle des développements sur le site du client permet au client de suivre l'avancement du projet et la qualité du travail fourni par l'équipe tout en limitant le besoin de spécifications détaillées, de revues couteuses des livraisons tout au long du projet, et de la longue phase de tests à la fin du projet (il faut tester à la fin du projet mais ce n'est pas du même ordre de grandeur). Gérer un projet agile distribué La différence entre le fonctionnement de l'équipe d'IBM et d'une équipe agile regroupée est très similaire. Ils commencent une itération avec une session de planification durant laquelle l'équipe identifie les tâches à réaliser durant cette itération et qui fait quoi. Ces sessions de planification comprennent la phase de modélisation durant laquelle chaque histoire d'utilisateur est élaborée par ceux qui vont la réaliser. Le but de tout ceci est de creuser suffisamment les détails de réalisation pour pouvoir planifier l'itération efficacement, même si la modélisation sera détaillée plus en profondeur lors de l'itération selon les besoins. Les réunions express quotidiennes1 se passent légèrement différemment pour les équipes distribuées par rapport aux équipes regroupées. Les personnes qui sont dans un même lieu géographique tiennent leur réunion debout quotidienne durant laquelle ils échangent les informations de bases – ce qu'ils ont fait depuis la dernière réunion debout, ce qu'ils espèrent réaliser d'ici à la prochaine, et s'il existe des éléments bloquants. Ensuite des représentants pour chaque réunion, se réunissent pour se coordonner. Si la réunion quotidienne debout est la première chose à faire le matin en arrivant, la réunion de coordination doit, elle, prendre en compte les fuseaux horaires. Une bonne pratique consiste à faire tourner l'heure de la réunion de coordination, de manière à répartir l'effet des différents fuseaux horaires. Les équipes distribuées ont besoin de meilleurs outils que les équipes regroupées car les fiches, les tableaux d'affichage, et les tableaux blancs ne fonctionnent pas bien en mode distribués. Une option est d'intégrer un ensemble d'outils libres, une autre est d'accepter la perte de productivité liée à l'hétérogénéité de ces outils, enfin une troisième option est d'adopter des outils dédiés à un développement distribué. L'équipe projet d'IBM utilise le produit Rational Team Concert (RTC), téléchargeable sur www.jazz.net, qui fournit un environnement de développement intégré complet et distribué (Integrated Distributed Development Environment) permettant la gestion distribuée des exigences et des défauts, de savoir si un membre de l'équipe est disponible et de pouvoir discuter en ligne avec lui avec une traçabilité complète, et la gestion des processus. L'équipe a choisit d'investir dès le début dans l'automatisation pour pouvoir supporter la vitesse de développement et le volume des modifications. RTC n'est pas simplement dédié aux développeurs, il peut aussi fournir un ensemble de graphiques qui permettent de suivre en temps réel l'état du projet notamment au 1 N.d.T.: Daily Stand up Meeting
  5. 5. travers des graphes de reste à faire, de tendance des défauts, d'état du 'build', et des statistiques d'allocation des ressources qui se basent sur les véritables activités des membres de l'équipe (à l'opposé des activités rapportées par l'équipe qui oublient souvent des points critiques). L'intégration de cet outil réduit très fortement la nécessité de rapporter pour l'équipe ce qui lui permet de se concentrer sur les tâches de développement, et fournit les informations nécessaires aux gestionnaires à distance du projet. Enfin, deux autres pratiques critiques pour les équipes de développement agile distribuées sont d'avoir des ambassadeurs et des médiateurs. Les ambassadeurs sont des experts séniors techniques ou métier qui passent d'un site à l'autre en échangeant avec les différentes sous-équipes. Réunir l'équipe au complet au début du projet a créé les bases d'une bonne communication, mais sans un investissement régulier pour maintenir une collaboration efficace entre les équipes vous risquez de voir vos sous-équipes dévier de la stratégie globale. Les médiateurs sont ceux qui sur le site facilitent la communication entre les membres de la sous-équipe et entre les sous-équipes. On en retrouve classiquement sous trois formes – les responsables qui gèrent le projet de la sous-équipe, les responsables produit qui représentent le métier dans la sous-équipe, et les responsables de l'architecture qui donnent la direction technique des développements. Ces médiateurs vont travailler en étroite collaboration avec leurs pairs, se réunissant régulièrement pour se coordonner entre sous- équipes, ainsi que des réunions impromptues à quelques uns pour résoudre des problèmes spécifiques. Plus la distribution géographique est importante plus la discipline doit être forte Sur un projet distribué, agile ou non, la communication est le risque le plus important. La bonne nouvelle vient du fait que les méthodes agiles mettent l'accent sur la communication et la collaboration, c'est déjà un premier pas dans la bonne direction. Accepter d'investir dans les voyages, faire un peu plus de modélisation dès le début du projet, organiser votre équipe autour de l'architecture, et adopter des outils plus sophistiqués sont les clefs du succès en mode agile distribué. Si vous souhaitez de plus amples informations je suggère de consulter le livre rouge d'IBM intitulé "Global Development and Delivery in Practice: Experiences of the IBM Rational India Lab" (www.redbooks.ibm.com/abstracts/sg247424.html). Je trouve cette approche un peu trop lourde à mon goût mais c'est écrit par des personnes avec des années d'expérience dans le développement distribué géographiquement. Remerciements Je voudrais remercier Rajesh P Thakkar, Lead Architect au laboratoire logiciel d'IBM à Bangalore, pour ses informations inestimables qui ont permis cet article.
  6. 6. travers des graphes de reste à faire, de tendance des défauts, d'état du 'build', et des statistiques d'allocation des ressources qui se basent sur les véritables activités des membres de l'équipe (à l'opposé des activités rapportées par l'équipe qui oublient souvent des points critiques). L'intégration de cet outil réduit très fortement la nécessité de rapporter pour l'équipe ce qui lui permet de se concentrer sur les tâches de développement, et fournit les informations nécessaires aux gestionnaires à distance du projet. Enfin, deux autres pratiques critiques pour les équipes de développement agile distribuées sont d'avoir des ambassadeurs et des médiateurs. Les ambassadeurs sont des experts séniors techniques ou métier qui passent d'un site à l'autre en échangeant avec les différentes sous-équipes. Réunir l'équipe au complet au début du projet a créé les bases d'une bonne communication, mais sans un investissement régulier pour maintenir une collaboration efficace entre les équipes vous risquez de voir vos sous-équipes dévier de la stratégie globale. Les médiateurs sont ceux qui sur le site facilitent la communication entre les membres de la sous-équipe et entre les sous-équipes. On en retrouve classiquement sous trois formes – les responsables qui gèrent le projet de la sous-équipe, les responsables produit qui représentent le métier dans la sous-équipe, et les responsables de l'architecture qui donnent la direction technique des développements. Ces médiateurs vont travailler en étroite collaboration avec leurs pairs, se réunissant régulièrement pour se coordonner entre sous- équipes, ainsi que des réunions impromptues à quelques uns pour résoudre des problèmes spécifiques. Plus la distribution géographique est importante plus la discipline doit être forte Sur un projet distribué, agile ou non, la communication est le risque le plus important. La bonne nouvelle vient du fait que les méthodes agiles mettent l'accent sur la communication et la collaboration, c'est déjà un premier pas dans la bonne direction. Accepter d'investir dans les voyages, faire un peu plus de modélisation dès le début du projet, organiser votre équipe autour de l'architecture, et adopter des outils plus sophistiqués sont les clefs du succès en mode agile distribué. Si vous souhaitez de plus amples informations je suggère de consulter le livre rouge d'IBM intitulé "Global Development and Delivery in Practice: Experiences of the IBM Rational India Lab" (www.redbooks.ibm.com/abstracts/sg247424.html). Je trouve cette approche un peu trop lourde à mon goût mais c'est écrit par des personnes avec des années d'expérience dans le développement distribué géographiquement. Remerciements Je voudrais remercier Rajesh P Thakkar, Lead Architect au laboratoire logiciel d'IBM à Bangalore, pour ses informations inestimables qui ont permis cet article.

×