Développement externalisé à l’offshore

Vincent Massol, un ancien d’Octo Technologies semble-t-il, fait le point sur l’utilisation des méthodes de développement dites « agiles » dans le cadre de projets de développement externalisés à l’offshore. J’avoue que je n’ai pas encore consulté cet entretien (video). Mais j’ai déjà lu la discussion qui s’en est suivie. J’en retiens les points suivants :

  • les outils d’issue tracking jouent un rôle déterminant dans la mise en place d’un processus efficace de communication avec le sous-traitant
  • à l’offshore, il est plus difficile (voire impossible) pour un chef de projet de deviner l’aisance ou les difficultés rencontrées par les développeurs au quotidien ; d’où le risque de passer à côté d’erreurs graves
  • même en faisant des itérations rapides (livraisons toutes les 2 semaines), il est nécessaire de formaliser (via UML par exemple) les use cases de manière détaillée à chaque itération
  • de fréquents voyages allers-retours sont nécessaires
  • l’équipe offshore doit avoir un chef d’équipe : il n’est pas possible de gérer des relations individuelles multiples à distance
  • il est nécessaire d’avoir des cycles de livraisons courts et d’intégrer chaque livraison de manière continue
  • les tests doivent constituer « l’ultime documentation »
  • les décalages horaires constituent davantage un frein qu’un facteur positif
  • les logiciels de messagerie instantanée sont un moyen très apprécié de coordination quotidienne
  • dès qu’une personne sur site doit travailler en relation avec une personne distante, il est nécessaire d’organiser une rencontre physique préalable faute de quoi la relation interpersonnelle ne peut s’établir correctement et le travail échoue
  • le moindre détail doit être documenté, jusqu’à la position de chaque bouton à l’écran, la police des libellés affichés, etc. faute de quoi la société offshore qui travaille au forfait fournira un résultat ayant des « finitions » défectueuses
  • il est souhaitable d’organiser une réunion quotidienne d’une durée d’au moins une demi-heure avec téléphone + videoconf ou chat + videoconf, à l’heure qui convient le mieux aux deux équipes ; cette réunion doit être préparée à l’avance chaque jour et, sauf exception planifiée, la réunion doit s’interdire tout travail du type « brain storming » (ce n’est pas une réunion de créativité)
  • les échanges en vue de créativité « brain storming » doivent avoir lieu sous forme de texte (wikis, mails, chat, …)

Le carnet Web DCLab fournit des notes et indications complémentaires pour bien travailler avec des sociétés à l’offshore.
Mais… j’apprends que ma société revient sur ses ambitions initiales d’externalisation à l’offshore et adopte un discours plus prudent suite à quelques expérimentations et, surtout, suite à l’apparition d’objectifs stratégiques considérés comme plus prioritaires que l’externalisation à l’offshore. Les inquiétudes sociales liées à la délocalisation d’emplois informatiques contribuent sans doute à ce revirement. Est-ce un signe des temps ? Le signe que les sociétés ajusteraient leurs ambitions aux possibilités réelles des modes de fonctionnement avec des sociétés offshore ? Ou bien le signe d’une prudence dans le discours pour ne pas effrayer la populace ? Ou tout simplement le signe que le gain à espérer de l’externalisation à l’offshore ne suffit pas à placer ce genre d’opérations parmi les top priorités d’une direction informatique ? L’avenir le dira sans doute.

4 réflexions au sujet de « Développement externalisé à l’offshore »

  1. Fred

    Les méthodes agiles où comment batir des maisons avec des silex.

    >à l’offshore, il est plus difficile (voire impossible) pour un chef de projet de deviner l’aisance ou les difficultés rencontrées par les développeurs au quotidien ; d’où le risque de passer à côté d’erreurs graves

    Encore faut-il qu’il s’y connaisse un minimum en technique.

    >même en faisant des itérations rapides (livraisons toutes les 2 semaines), il est nécessaire de formaliser (via UML par exemple) les use cases de manière détaillée à chaque itération

    Formaliser et livrer rapidement sont 2 choses contraires.

    >de fréquents voyages allers-retours sont nécessaires

    C’est çà. C’est le client qui paye.

    >l’équipe offshore doit avoir un chef d’équipe : il n’est pas possible de gérer des relations individuelles multiples à distance

    Qu’est-ce que je disais pour le chef de projet ?

    >les logiciels de messagerie instantanée sont un moyen très apprécié de coordination quotidienne
    dès qu’une personne sur site doit travailler en relation avec une personne distante, il est nécessaire d’organiser une rencontre physique préalable faute de quoi la relation interpersonnelle ne peut s’établir correctement et le travail échoue

    Je n’ai jamais vu mon hébergeur et pourtant cela se passe bien entre nous au téléphone ou par tchat.

    >le moindre détail doit être documenté, jusqu’à la position de chaque bouton à l’écran, la police des libellés affichés, etc. faute de quoi la société offshore qui travaille au forfait fournira un résultat ayant des “finitions” défectueuses
    il est souhaitable d’organiser une réunion quotidienne d’une durée d’au moins une demi-heure avec téléphone + videoconf ou chat + videoconf, à l’heure qui convient le mieux aux deux équipes ; cette réunion doit être préparée à l’avance

    C’est çà. On prend une journée la veille pour préparer la réunion d’1/2 heure.

    Je ne vois pas comment une méthode dite « agile » pourrait supplanter la bonne vieille méthode du bordel organisé présente dans tous les grand comptes.

  2. Ping : AkaSig » Clever Age - Le point sur l’interopérabilité J2EE, .NET et PHP

  3. Ping : AkaSig » Blog Archive » Consultant-in-a-box

Les commentaires sont fermés.