Le développement distribué de logiciels

Dans le contexte actuel de mondialisation des marchés et de la main d’œuvre, les entreprises d’aujourd’hui n’ont désormais plus guère le choix d’user de tous les moyens à leur disposition afin de rester compétitives et maintenir leur part de marché. Le domaine du logiciel n’y fait malheureusement pas exception et c’est pour cette raison que le développement distribué de logiciels s’est vite imposé comme pratique incontournable pour tous les gros joueurs du domaine. Les sections qui suivent présenteront quelques-unes des motivations d’affaires qui justifient le recours à une telle pratique et les obstacles majeurs rencontrés par les organisations qui l’appliquent.

41

1.4.1 Les motivations d’affaires

De prime abord, le développement de logiciel distribué, également connu sous les expressions anglaises de «collaborative software development» ou encore «global software development», réfère au développement d’un logiciel de façon distribuée dans le temps et/ou dans l’espace, c’est-à-dire sur plusieurs sites et/ou sur plusieurs tranches horaires. Quoique le temps ne soit pas une composante nécessaire pour parler de développement distribué, l’espace quant à lui en est la prémisse de base. Toutefois, contrairement à ce qu’il est permis de penser, il ne faut pas nécessairement croire qu’une énorme distance doit séparer les équipes pour impliquer un travail distribué. En fait, selon Allen (Allen Thomas J, 1977), une distance de 30 mètres suffit pour observer une chute drastique des communications entre les membres d’une même équipe et ce, au même niveau que s’ils avaient été séparés de plusieurs kilomètres.

Ainsi, concernant les motivations d’affaires qui justifient le recours à une telle pratique, il n’est pas surprenant de constater que l’une des principales raisons évoquées est la réduction du coût de la main d’oeuvre et la disponibilité de cette main d’œuvre en pays étrangers (Ebert & De Neve, 2001; Kobitzsch, Rombach, & Feldmann, 2001). Toutefois, Ebert et De Neve soulignent le fait que la distance entre les équipes amène un coût supplémentaire à la fois lié à la gestion des équipes virtuelles et à la moins bonne performance de ces équipes. D’autre part, une autre raison de l’accroissement de la pratique du développement distribué de logiciels serait attribuable aux nombreuses fusions et acquisitions des entreprises qui seraient ainsi forcées à conserver le capital de connaissances acquis (Grinter et

42

al., 1999; Herbsleb & Moitra, 2001). De plus, les avantages liés à la proximité du marché et des clients potentiels seraient également une autre source de motivation pour l’adoption d’une telle pratique (Ebert & De Neve, 2001; Mockus & Herbsleb, 2002). Finalement, la pression qui pousse à améliorer sans cesse le temps de mise en marché contribue également à inciter la pratique du développement de logiciel distribué puisque que la répartition de la force de travail sur plusieurs fuseaux horaires amène la possibilité de faire du développement «round-the-clock», c’est-à- dire sans interruption à raison de 24 heures par jour (Ebert & De Neve, 2001; Herbsleb & Moitra, 2001).

1.4.2 Les problèmes de communication rencontrés

Bien que la pratique du développement de logiciel distribué puisse amener son lot d’avantages, elle occasionne également un certain nombre de problèmes. Plus particulièrement, outre les problèmes d’ordres légaux, d’infrastructure (Kobitzsch et al., 2001), de culture et de langue (Kruchten, 2004) et ceux, à proprement parler, liés aux individus impliqués (Herbsleb & Mockus, 2003-; Herbsleb & Moitra, 2001), certains problèmes importants au plan de la communication peuvent également se manifester.

Comme il a été mentionné plus tôt, la communication constitue un ingrédient indispensable au développement de logiciels (Robillard & Robillard, 2000; Seaman & Basili, 1997; Herbsleb & Mockus, 2003-). Non seulement elle permet la cristallisation de l’ensemble des informations requises en un logiciel qui correspond aux besoins de l’usager (Robillard et al., 2003), elle joue également un rôle majeur

43

à la bonne santé de l’équipe (Adler & Towne, 1999) ainsi qu’à sa coordination (Grinter et al., 1999; Herbsleb & Grinter, 1999). Toutefois, il a été trouvé, lors de recherches empiriques (Grinter et al., 1999; Herbsleb & Grinter, 1999) que dans un contexte de développement distribué, la distance entre les membres d’une équipe virtuelle semble lever certaines barrières aux communications informelles, celles qui surviennent à tout moment de façon spontanée, incluant également celles que certains appellent le «water-cooler talk» (Grinter et al., 1999). Les conséquences de cette baisse de communication sont multiples, mais entre autres, elles impliquent divers problèmes de coordination au sein de l’équipe (Herbsleb & Grinter, 1999), de gestion des connaissances et d’expertises (Herbsleb & Moitra, 2001) occasionnant de surcroît des délais supplémentaires aux projets logiciels. Même si une étude comparative récente des communications en contextes co-localisé et distribué (Al- Ani & Keith, 2008) lors de laquelle les chercheurs ont trouvé que les communications informelles se déroulaient aussi fréquemment en contexte co- localisé que distribué, ce qui amène ces derniers à se questionner s’il n’y aurait pas eu d’évolution en terme de pratique ou technologique depuis l’étude mentionnée ci- dessus, la méthodologie employée pour l’obtention des résultats dans le cadre de cette nouvelle étude et qui était basée sur les réponses à un questionnaire administré à 17 répondants et non le fruit d’observations empiriques sur le terrain porte à croire que de nouvelles études sur le sujet s’avèrent nécessaires.

1.4.3 Les solutions envisagées

Afin de pallier un tant soit peu aux divers problèmes susmentionnés, certaines pratiques peuvent être mises de l’avant. Entre autres, certaines technologies telles

44

que la vidéoconférence ainsi que la messagerie instantanée peuvent être mises en place afin de minimiser l’effet des distances géographiques (Herbsleb & Mockus, 2003-). De plus, la division et l’attribution des tâches d’un site à un autre devraient se faire tenant compte du concept de modularité du logiciel développé afin de minimiser les liens de dépendances entre les sites (Grinter et al., 1999). Ainsi, selon Grinter, Herbsleb et Perry, l’attribution des tâches pourrait se faire en fonction des domaines d’expertise de chaque site, de la structure du logiciel, des disciplines liées au processus de génie logiciel suivi, ainsi que du concept de configuration. Finalement, certaines méthodes liées à la gestion des connaissances et de l’expertise peuvent également être mises de l’avant, tel qu’un processus de gestion de connaissances institutionnalisées (Herbsleb & Moitra, 2001) de même qu’un fureteur d’expertises (Mockus & Herbsleb, 2002).