Publié par

Il y a 12 ans -

Temps de lecture 13 minutes

Off-shoring agile : C’est difficile, mais ça marche !

L’offshore est devenu une réalité du développement logiciel. Néanmoins, un grand nombre de projets échouent dans ce domaine faute d’adopter une approche efficace de la distribution des équipes. Au-delà des avantages strictement financiers, l’off-shoring amène son lot de complexité et de risques, et ouvre des boulevards aux gaspillages de toute sorte.

Ce billet, librement traduit de mon excellent collègue indien Vikas Hazrati (billet original sur TheServerSide), vise à présenter comment Xebia réussit à faire fonctionner les projets off-shore en s’appuyant sur les principes du Toyota Manufacturing Process, connu également sous le nom de « Lean ». Nous appelons cette méthodologie « Lean Agile Off-shoring ».

Davantage que des économies de bouts de chandelle, notre objectif, lorsque nous avons fondé notre filiale indienne, était de bénéficier de la somme de talents disponibles en Inde pour développer plus rapidement des logiciels de meilleure qualité. Pour gérer les projets, nous avons choisi d’adopter Scrum en raison des solides compétences que nous possédons dans ce domaine, et des succès que nous avons rencontrés dans la conduite de projet agiles avec Scrum. Les principes du « Toyota Way of Working » – que l’on peut au demeurant appliquer à tout type de développement logiciel – nous ont permis d’ajuster le modèle pour obtenir aujourd’hui un processus de développement mature et doté de mécanismes organiques d’amélioration perpétuelle – en un mot, Lean.

Le projet sur lequel cette méthodologie a été mise au point est la refonte d’un système de traitement automatisé appartenant à une administration centrale hollandaise. Le système traite certaines données salariales en provenance des employeurs et d’autres en provenance du système de taxation sur le revenu. Il valide ces données puis crée automatiquement la déclaration de revenu pour la période considérée. Le système traite 16 millions de transactions par mois, avec un débit d’environ 50 transactions par seconde.
L’équipe était composée de 14 personnes, 6 en Europe, 8 en Inde.

La suite présente un ensemble de principes qui ont émergé de cette expérience, et qui nous permettent aujourd’hui de mener des projets de toute taille avec un niveau de productivité et de qualité qui nous épate nous-mêmes !

Principe #1 – Définir une philosophie à long terme et s’y tenir

Le projet a été démarré avec une idée en tête : il ne serait pas une initiative isolée, mais un laboratoire destiné à asseoir un modèle de développement off-shore hautement productif, stable et reproductible.
Deux principes immuables en ont découlé :

  • aucun compromis ne doit être fait, jamais, sur la qualité des développements
  • toute l’équipe doit, en permanence, inventer et affiner ses pratiques pour supprimer les pertes de temps et les activités sans valeur ajoutée

Principe #2 – Créer un flot de communication continu

Nous avons décidé d’être agiles dans toutes nos actions, et en conséquence de ne pas suivre un plan défini. Néanmoins, sans plan, il est aisé de s’égarer en chemin. C’est là que l’intégration et la communication continues prennent tout leur sens et jouent un rôle vital.
Nous avons adopté un modèle consistant à envoyer régulièrement des ambassadeurs (Scrum Master ou développeurs) d’un site à l’autre, afin de permettre au contexte client de voyager au-delà des frontières, de renforcer la confiance mutuelle des membres de l’équipe, et d’établir cette culture commune indispensable au succès d’un projet agile.
La communication a également été facilitée par la mise en place d’outils de communication permanents sur les deux sites, visant à la construction d’un véritable « lieu de travail virtuel » – caméras, écrans, micros, tableaux numériques, etc. Parler à un membre de l’équipe distante ne doit guère demander plus d’effort qu’à un collègue local.
Enfin, un seul référentiel de source était partagé par les deux équipes, avec un système d’intégration continue pour permettre la détection – et la correction – immédiate des problèmes.

Principe #3 – Utiliser un système « pull » pour éviter la surproduction

Corollaire du principe précédent, il est indispensable de produire le logiciel conformément aux demandes du commanditaire – le fameux « product backlog » de Scrum ; si le backlog est peu fourni, la durée des itérations est réduite, ou le temps ainsi libéré est consacré au refactoring, à l’amélioration du processus ou des livrables, bref à s’assurer que le client obtient ce qu’il veut, au moment où il le veut, et avec des critères de qualité très élevés.

Principe #4 – Niveler la charge (heijunka)

Toyota parle d’éviter le muda (gaspillage), le muri (personnes surchargées) et le mura (irrégularité).

En gardant en mémoire ces objectifs, les principales sources de gaspillage dans un projet off-shore sont : des fonctionnalités superflues, des spécifications inutilement détaillées, des couches de communication superfétatoires entre l’équipe et le commanditaire, la difficulté à accéder à l’information, des erreurs non détectées par les tests.

Un soin tout particulier a été porté dans la définition du périmètre d’une itération, en ne développant que les cas d’usage connus et sur la base de story cards ne comportant que les détails nécessaires à l’itération en cours. Le code était développé directement à partir de ces story cards, en s’assurant que les développeurs, y compris off-shore, aient un contact direct avec le commanditaire.
Afin de niveler la charge de travail, le sprint backlog (c’est-à-dire la liste des fonctionnalités qui doivent être développées au cours d’une itération) était systématiquement établi en conformité avec la vélocité observée de l’équipe. Il n’y a rien de plus contre-productif à moyen terme que de maintenir une équipe de développement sous la pression d’une charge de travail supérieure à sa capacité de production – cela revient à étrangler la poule aux œufs d’or et se traduit généralement par une baisse massive de la qualité et de la motivation.

Mesurer la vélocité réelle de l’équipe, et prévoir la charge en conséquence, est une activité critique.

Principe #5 – Stopper le développement pour régler les problèmes

Nous avons mis en place une culture dans laquelle le travail est interrompu si un problème survient qui met en péril la qualité de la production.

Lorsque les équipes distantes/locales ont eu le sentiment que leur communication n’était pas satisfaisante, nous avons mis en place une machine de communication continue de chaque côté, dotée de haut-parleurs et de vidéo.

Lorsque les équipes ont déterminé que les revues de sprint ne donnaient pas les résultats attendus, nous les avons interrompues, avons déclenché une séance de brainstorming avec tous les membres de l’équipe, et avons mis en place une nouvelle méthode permettant en particulier de consacrer moins de temps à la revue.

S’il y avait un problème avec l’intégration continue ou les tests de performance, nous réglions le problème avant de poursuivre le développement de fonctionnalités additionnelles.

Quand les testeurs fonctionnels ont manqué de temps pour tester le flot de fonctionnalités développées, nous avons suspendu les développements fonctionnels le temps que l’équipe de test absorbe son trop-plein.

Cette culture a non seulement permis de mettre en place rapidement des contre-mesures, mais a également amené à anticiper certains problèmes et à s’ajuster en conséquence.

Principe # 6 – Standardiser les processus communs

La standardisation est la base de l’amélioration continue ; elle permet de diffuser l’expérience des uns dans la pratique des autres, de responsabiliser les membres des équipes, de promouvoir l’apprentissage organisationnel. Le standard, cependant, n’est jamais gelé : il reste au service des objectifs du projet, et doit être mis en question chaque fois qu’il va à son encontre.

Nous avons mis en place des processus standardisés pour le développement à base de test (TDD), pour la gestion des demandes et la résolution des incidents, pour l’assemblage et pour les tests. En aucun cas, bien sûr, ces processus n’étaient figés : ils étaient aussi agiles et vivants que le reste du projet. Simplement, leur existence permettait de démarrer sur une base stable, et de fournir le socle de la culture de l’équipe – et un point de départ pour les améliorations futures.

Principe #7 – Utiliser des contrôles visuels

Une devise simple : tout doit toujours être visible pour tout le monde dans l’équipe – et cela inclut bien sûr le commanditaire.

Le product backlog, géré dans Jira, était commun aux équipes locales et distantes, de même que les diagrammes de suivi (burn down chart) et les états d’avancement quotidien – le tout ouvert au client. Même transparence pour le système de gestion des bugs, dans lequel le client pouvait d’ailleurs déclarer les incidents d’exploitation. Le système d’intégration continue (Cruise Control) déclenchait un build complet à chaque check-in – avec un retour visuel sur le statut du build et une alarme sonore en cas d’échec du build.

Les murs et tableaux – physiques ou virtuels – comportaient suffisamment d’information visuelle pour que n’importe quel commanditaire puisse prendre connaissance de l’état du projet en moins de 10 minutes.

D’une façon générale, quelques codes visuels simples et partagés sont le meilleur moyen de s’assurer que tout le monde possède un niveau d’information adéquat.

Principe #8 – Utiliser des technologies adaptées à l’équipe et aux processus

Un véritable projet lean possède deux vertus cardinales.

Tout d’abord, il transfert un maximum de tâches et de responsabilités aux développeurs – ce sont eux qui sont chargés de créer la véritable valeur ajoutée du projet ; ensuite, il possède, nous l’avons vu, les boucles de rétroaction permettant de détecter et régler les problèmes le plus tôt possible.

Les individus sont la principale richesse d’un projet agile ; c’est donc à eux de décider et d’adapter la technologie pour qu’elle satisfasse leurs besoins – et non la technologie qui dicte la façon dont les choses doivent être faites. Par exemple, nous avons migré toute la logique de présentation de Struts à Spring MVC par ce que cela faisait plus de sens dans le contexte, et que l’équipe s’était mise d’accord sur cette évolution. Les meilleures décisions techniques sont prises par l’équipe, et non, comme c’est trop souvent le cas, par un panel d’architectes autonomes déconnectés des enjeux du projet.

Principe #9 – Privilégier le leadership interne

Les individus sont, répétons-le, la principale richesse d’un projet.

Dans ce projet off-shore, nous étions décidés à promouvoir les leaders à l’intérieur même de l’équipe. Plutôt que d’engager des scrum masters externes, nous avons donc envoyé certains membres de l’équipe – locale et indienne – suivre une formation de scrum master – et nul besoin de préciser que ce sont eux qui connaissaient le mieux l’équipe et ont su le mieux développer leur leadership dans le respect des autres.

Principe #10 – Développer un esprit d’équipe

Une communication sans tabou, un travail efficace, une faible spécialisation des rôles, un bon salaire, les meilleurs outils et matériels, un environnement de travail agréable, un équilibre vie personnelle – vie professionnelle préservé, un perfectionnement continu, une bonne rotation des responsabilités. Voici quelques uns des éléments qui, mis en œuvre avec intelligence et tact, permettent de créer des équipes ultra-performantes.

Une communication saine entre les différentes localisations est un élément clé du succès dans un projet off-shore. Pour gérer cela nous avons, dès le début du projet, favorisé les visites sur le site pair, afin de créer les relations inter-personnelles nécessaires, et avons par la suite régulièrement réitéré ces échanges afin de maintenir la cohésion – ces voyages, bien sûr, n’avaient pas pour but d’accélérer la production, mais de maintenir un climat sain entre les deux sites.

Les gens sont souvent découragés – ou peu enclins – à poser des questions, à parler des problèmes, à mettre en garde contre des objectifs improbables ou à proposer des alternatives aux propositions faites par leurs supérieurs. Nous avons activement promu une culture du questionnement et de la pro-activité. Une fois que les membres de l’équipe eurent réalisé qu’ils avaient la liberté, et la responsabilité, de prendre des décisions, ils sont devenus des contributeurs actifs, et des co-équipiers remarquables.

Principe #11 – Développer les relations avec partenaires et fournisseurs comme des extensions de votre propre entreprise

Etablir une relation honorable et honnête avec partenaires et fournisseurs est l’un des piliers du Toyota Way of Working.

Nous avons autant que possible suivi ce précepte en ouvrant Wiki et Jira au commanditaire et aux sociétés tierces chargées de développer d’autres modules du même projet. Avantage immédiat, une confiance spontanée dans notre travail : nous n’avions rien à cacher.

Non seulement cette transparence a permis de légitimer notre modèle de développement off-shore, mais elle a également permis d’échanger et d’apprendre de nos partenaires.

Principe #12 – Mettre la main à la pâte !

Il n’y a rien de mieux que de mettre la main à la pâte pour juger de la situation ; nous n’avions donc pas d’analyste fonctionnel dédié, ni d’architecte je-sais-tout (Architectus Matrix) : tout le monde devait coder, et cette activité prenait largement le pas sur toutes les autres. Point.

Principe #13 – Evaluer plusieurs alternatives face à un problème, puis implémenter rapidement celle qui a été choisie

Nous avons systématiquement considéré et évalué plusieurs solutions à un problème donné avant d’en choisir une – au besoin au travers d’expérimentations limitées dans le temps ; une fois déterminée la solution appropriée elle était adoptée rapidement et de façon consistante.

Cette approche a pu être mise en œuvre pour toutes sortes de difficultés, dans toutes sortes de domaines : traduction des documents, organisation des journées – il y a 4 heures de décalage entre l’Europe et l’Inde -, choix de bibliothèques ou d’APIs, etc.

Principe #14 – Devenir une organisation apprenante grâce à l’introspection permanente (hansei) et à l’amélioration continue (kaizen)

C’est le principe le plus important, celui qui pilote tous les autres : nous réalisons une évaluation rigoureuse de chaque itération afin de déterminer ce qui fonctionne bien et ce qui pourrait être amélioré – et comment l’améliorer. Chaque itération est ainsi plus mature et plus efficace que la précédente.

Nous sollicitons l’avis immédiat du client et de l’équipe afin que tout dysfonctionnement soit corrigé sans délai, et qu’aucun problème ne s’installe durablement.

En guise d’astuce, pour chaque problème que nous rencontrons, nous recherchons la cause première en posant cinq fois la question « Pourquoi ? ».

Conclusion

Nous continuons, chaque jour, d’apprendre et d’améliorer. La métaphore du développement lean a été appliquée avec succès au développement off-shore. Les principes de Toyota, appliqués au développement logiciel off-shore, offrent un véritable pont vers l’hyper-productivité et la haute qualité.

Publié par

Commentaire

1 réponses pour " Off-shoring agile : C’est difficile, mais ça marche ! "

  1. Publié par , Il y a 12 ans

    Wow. Impressionnant. Bravo.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.