Questions culturelles liées au développement logiciel Agile

Des gens à des ordinateurs
Robert Biddle est professeur de communication humain-ordinateur à l'école d'informatique (School of Computer Science) de l'Université Carleton à Ottawa, au Canada. Les travaux de recherche sur le développement logiciel interactif du Professeur Biddle, ou développement logiciel Agile, l'ont conduit à concevoir des jeux qui permettent aux développeurs de relever les défis reliés au travail en tant que membres d'équipes diversifiées.

Professeur Biddle, en quoi consiste le développement logiciel Agile?

Le terme « Agile » fait référence à une famille de nouvelles techniques de gestion, principalement d'autogestion, servant à créer des logiciels informatiques. Dans les débuts de l'industrie des logiciels, la méthode générale qui servait à orienter le travail s'inspirait d'une sorte de modèle de production en usine. Toutefois, de nombreuses particularités propres aux logiciels informatiques rendent cette méthode inadéquate. Notamment, dans le cas des logiciels, il n'y a pas réellement d'étapes de fabrication, puisqu'il est facile, une fois le logiciel terminé, de graver des CD et de les expédier partout dans le monde. Le logiciel peut ensuite être actualisé, même après l'expédition. La conception et le développement logiciels peuvent ainsi se mouler davantage aux exigences particulières des clients et des utilisateurs.

Le développement logiciel Agile a été mis au point d'après les expériences de développeurs qui ont travaillé dans l'industrie et qui considéraient le modèle de production en usine davantage comme un obstacle. Ils ont découvert qu'il y avait plus à gagner d'une collaboration réelle entre les développeurs de logiciels et ceux qui en avaient besoin, soit le fait de travailler d'une façon nouvelle pour en arriver à créer un logiciel qui soit utile aux gens. Cette coopération constante est caractéristique des méthodes de développement Agile.

Combien de personnes composent généralement une équipe de réalisation?

Les équipes sont généralement petites, soit de 8 à 12 personnes travaillant dans une pièce commune. La méthode Agile suppose de prendre des mesures pour que la collaboration fonctionne presque de façon fortuite. De sorte qu'une des règles est de ne pas travailler dans des bureaux individuels, mais d'aménager pour l'équipe une pièce commune pour la création. On dispose des tables où plusieurs personnes peuvent travailler en même temps. Il faut faire en sorte que les personnes puissent entendre les conversations des autres. On doit prévoir d'autres espaces lorsqu'il est nécessaire de s'isoler, mais la norme doit être un lieu de travail en groupe où l'équipe du projet occupe le même espace.

Cela n'exclut-il pas le travail en équipe virtuelle?

C'est là le défi. Beaucoup de personnes, parmi lesquelles on compte certains experts des plus réputés en ce domaine, déclarent que le travail dans un même lieu vaut beaucoup mieux que le travail à distance et qu'il faut tout mettre en œuvre pour se retrouver dans un même endroit. À l'évidence, cela n'est pas toujours possible. Certaines grandes organisations qui se sont penchées sur ce problème ont trouvé des façons de s'adapter. Par exemple, une grande organisation internationale dont le siège est à Chicago a proposé un compromis. Au démarrage d'un projet, tous les membres de l'équipe sont réunis dans un même endroit pendant les deux premières semaines. Ils se séparent ensuite mais se réunissent à nouveau six mois plus tard, pendant quelques semaines, dans un autre endroit. Par exemple, il y aura des équipes en Inde et aux États-Unis. Tous les membres de l'équipe indienne seront amenés aux États-Unis pour quelques semaines et ils travailleront dans cette atmosphère de collaboration. L'équipe sera ensuite séparée à nouveau, les Indiens retournant chez eux. Six mois plus tard, les membres américains de l'équipe se rendront en Inde pour y travailler avec l'équipe qui s'y trouve. De cette façon, même si les membres sont séparés, ils se connaissent suffisamment, se font implicitement confiance les uns les autres et savent communiquer efficacement entre eux, même lorsqu'ils ne sont pas ensemble. J'ai pensé qu'il s'agissait là d'une approche très intéressante.

Étant donné le contexte mondial dans lequel nous vivons et travaillons, je suppose que les équipes présentant une grande diversité – et par diversité j'entends sous tous les aspects – sont chose courante.

Absolument, et la diversité l'emporte.

Que voulez-vous dire?

Lorsque l'effet de levier vient de la collaboration, on tire parti des expériences diverses et des points de vue différents. On veut une approche à multiples facettes. En réalité, beaucoup d'organisations ne veulent pas de personnes qui ne possèdent qu'un seul type de compétences. Elles veulent assurément des gens qui ont des compétences, mais qui peuvent aussi généraliser et travailler avec les autres. Dans un milieu de travail nouveau et construit sur le travail en groupe, comme le développement Agile, les idées neuves et les compétences différentes constituent un avantage.

Lorsqu'une équipe est riche d'expériences et que la collaboration existe, il y a de meilleures chances pour que survienne au cours d'une conversation quotidienne un de ces moments où les développeurs de logiciel se disent « Ah, ha! » en réalisant soudainement qu'ils peuvent être encore plus utiles qu'ils ne l'avaient  cru de prime abord.

De plus en plus, les organisations réalisent que des équipes « homogènes » peuvent se mettre en branle plus rapidement, mais que ces avantages sont de courte durée. À long terme, on obtient des réactions prévisibles aux problèmes, ainsi que des solutions très prévisibles. Mais pas nécessairement de la créativité ou de l'innovation.

Ce n'est pas viable; c'est le principe du cumul de la diversité. La diversité est fondamentalement plus viable parce qu'il y a moins de points de défaillance isolés. Même si certaines choses ne se passent pas bien, d'autres, par contre, qui ont été abordées d'un point de vue tout à fait différent, s'avéreront utiles.

Quelles sont certaines des difficultés courantes que posent à la fois la distance physique et les différences culturelles éventuelles au sein des équipes?

Voilà une question qui suscite vivement notre intérêt. Nous avons réalisé un certain nombre d'études – principalement mes étudiants, qui ont interviewé et observé des équipes de développeurs de logiciel partout dans le monde – et il s'agit exactement du genre de phénomène que nous essayons d'explorer. Le psychosociologue hollandais Geert Hofstede a décrit la culture comme le « logiciel de l'esprit » et de nombreux ouvrages traitent de ce sujet. À mon avis, ce qu'il est important de comprendre, c'est que les gens travaillent à partir de leur propre cadre particulier et qu'ils portent leur propre programmation culturelle. Cette dernière leur indique comment comprendre ce qui se déroule sous leurs yeux, selon leur propre point de vue. Je crois que l'importance réelle de ce genre de travail est d'aider les gens à comprendre les différents types de programmation qui existent.

Incluant celle qui leur est propre?

Oui, la leur par-dessus tout; ils doivent comprendre que leur programmation ne reflète que leur seul point de vue, et c'est à ce moment, à mon avis, qu'il y a une chance pour qu'on constate toutes sortes d'avantages. Le premier étant de susciter le respect lorsqu'on comprend qu'aussi étrange que puisse paraître un modèle de comportement, il se dessine contre cette toile de fond culturelle. Je pense que c'est par là que nous devons commencer. Ce qui est le plus motivant, c'est de savoir qu'il y a du travail à faire.

Je crois que c'est dans un certain nombre d'équipes de développeurs de logiciels que nous avons étudiées que cette difficulté s'est réellement présentée. Plusieurs méthodes de développement, y compris la méthode Agile, ont été codifiées et ont « grandi » aux États-Unis. Elles sont le plus souvent décrites et transmises selon un point de vue très individualiste. Tout comme Hofstede et d'autres l'ont fait remarquer, une des différences culturelles les plus courantes se trouve entre les points de vue des individualistes et des collectivistes. Une des questions que nous trouvons vraiment intéressante consiste à saisir exactement comment cette programmation individualiste agit dans la compréhension de la façon dont les choses doivent se faire et comment les méprises peuvent survenir. Et comment il est encore possible de travailler ensemble dans des équipes où existent toutes sortes de points de vue.

Pouvez-vous me donner un exemple?

Une situation courante dans tout travail d'équipe est la différence entre vouloir le succès de l'équipe et vouloir être considéré comme le joueur le plus valable de l'équipe. Nous savons combien ce type de situation est difficile du point de vue de la production, combien il importe peu de savoir à quel point vous êtes bon si le but de votre présence au sein de cette équipe n'est jamais atteint.

Qu'en est-il d'autres types de difficultés? Par exemple, l'environnement ordinaire d'une équipe canadienne est assez « égalitaire », ce qui veut dire qu'il n'est pas très hiérarchique.

La difficulté dans ce cas est que la plupart des méthodes de développement logiciel que nous avons vu à l'œuvre se caractérisent en général par une faible distance du pouvoir (low Power Distance). Elles fonctionnent selon un concept de responsabilité commune où tous sont sur le même pied. Dans nos travaux, nous avons cherché à observer comment cela fonctionne dans des organisations qui choisissent une approche entièrement différente. Il s'agit bien sûr d'une hypothèse, mais je crois que nous assistons à un phénomène en vertu duquel les gens développent leur propre interprétation de ce que les théoriciens nommeraient la permutation du cadre culturel. Ce terme est normalement utilisé pour désigner des personnes qui grandissent dans deux cultures; ils en ont une à la maison et une autre au travail. L'idée est que les deux existent simultanément et que les personnes passent de l'une à l'autre.

Je crois que nous observons des personnes qui font la même chose en milieu de travail. J'ai même vu cela ici en Amérique du Nord, où des organisations très hiérarchisées réussissent à adopter ces nouvelles approches en considérant essentiellement que le développement logiciel est un endroit séparé possédant sa culture propre. Ainsi, dans la salle de travail de l'équipe, il convient que les personnes soient sur un pied d'égalité et que le travail se fasse en collaboration aux fins de la responsabilité collective. Mais hors de la salle, il est entendu que la culture organisationnelle est différente. De plus en plus, j'observe des personnes qui, à toute fin pratique, changent de cadre culturel lorsqu'elles quittent la salle de travail commune pour vivre dans un espace à bureau normal.

Professeur Biddle, vous croyez, à l'évidence, que le rôle joué par la culture dans la méthode de développement logiciel Agile est à ce point important que vous avez créé des ateliers dans le but d'aider les développeurs à acquérir des connaissances sur la question. Pendant le déroulement de ces ateliers, les participants sont amenés à jouer à quelques jeux – j'aimerais que vous élaboriez un peu sur ce sujet.

Nous avons mis au point trois ou quatre jeux. Celui dont je me suis servi plus récemment s'inspire en fait du jeu de société Monopoly. Tout comme au Monopoly, les personnes s'assoient autour du plateau de jeu et ont des petits marqueurs. Le plateau est structuré comme un projet de développement logiciel et les quatre côtés représentent quatre types d'activités différentes qu'on retrouve dans le développement logiciel. Chaque fois que vous faites le tour du plateau, vous lancez une nouvelle version de votre logiciel. Chaque fois que vous faites un arrêt sur une case du plateau, c'est une occasion de collaboration et la question est de savoir avec quelle facilité vous pouvez collaborer avec une personne différente à ce point précis de la méthode de développement logiciel. À chaque arrêt, une certaine difficulté se pose concernant la façon dont vous vous comportez face à un type particulier de différence dans un certain contexte de travail.

Est-ce que chacun a un rôle à jouer et un personnage à adopter?

C'est exact. Le jeu commence par le choix d'un personnage. J'encourage les gens à choisir le personnage ou le rôle qui les intéresse le plus dans l'équipe de développement. Le plus souvent, j'aimerais que les gestionnaires jouent les gestionnaires et les développeurs leur propre rôle, mais il arrive parfois qu'ils choisissent un rôle différent et ça fonctionne. Lorsqu'un joueur s'arrête sur une case après avoir lancé le dé, il doit faire savoir aux autres personnes autour de la table comment il aborderait cette situation particulière. Il y a donc une partie jeu, mais les vraies occasions d'apprentissage viennent du fait qu'il faut considérer en contexte tous les éléments différents qui se présentent durant la partie. Le but est de situer le savoir dans le contexte dans lequel il se présente et de discuter ensuite essentiellement des différents points de vue et de la perception que chacun en a.

Quel type de rétroaction ou de commentaire recevez-vous des participants à ce type de jeu?

Ils m'encouragent. J'ai utilisé ce tutoriel dans trois ou quatre conférences internationales auprès de personnes issues de collectivités différentes. S'asseoir autour d'une table et jouer à un jeu de société génère également son propre contexte, à savoir une sorte de situation très amicale qui aide à tenir ce genre de discussions vraiment très sérieuses autour d'un plateau de jeu. Fait intéressant, lorsque j'ai conçu ces jeux – en collaboration avec un collègue de l'Université d'Ottawa et deux de mes élèves qui enseignent maintenant au Danemark – nous avons trouvé fascinant d'étudier la dynamique du jeu et la façon dont cette dernière simplifie en quelque sorte l'expérience de vie façonnée de cette manière. Je termine habituellement l'exercice en demandant aux gens en quoi le jeu ne reflétait pas la réalité. Jusqu'à maintenant j'ai obtenu du succès et cela amène un sujet de réflexion intéressant.

Je désire préciser un dernier point : Une grande partie de ce travail a été réalisée avec de nombreux étudiants doués et des collègues de grand renom – cela n'est pas uniquement mon travail.

Merci, professeur Biddle.

Je vous en prie.

Apprentissage supplémentaire