samedi 22 août 2009

Agile : spécialistes ou généralistes ?

Dans la littérature des méthodes agiles, on y lit souvent qu'une équipe devrait être plutôt composée de membres généralistes plutôt que spécialistes. Pour quelle raison ? Essentiellement, parce qu'on dit d'un spécialiste qu'il est souvent focusé sur une seule solution à un problème, qu'il peut parfois manquer de modestie et d'introspection et qu'il est difficile de travailler avec lui en équipe, car il ne comprends pas bien les autres membres de l'équipe. À l'inverse, on prête aux généralistes, une plus grande facilité à travailler ensemble, ils connaissent mieux ce que les autres font et n'ayant pas de spécialisation précise dans un domaine donné, ils sont plus ouverts à regarder plusieurs alternatives pour étayer leur solution.

Qu'en est-il dans la réalité ? Pour ma part, je trouve cela un peu paradoxal, car en TI, le domaine est tellement vaste et les possibilités infinies, que chaque individu en vient à se faire une niche, une spécialisation dans un domaine plus ou moins précis. Je crois que c'est inévitable si on veut survivre dans le domaine des TI.

À mon avis, dans une équipe agile, on doit avoir toute sortes d'individus, généralistes, spécialistes, plus ou moins généralistes, plus ou moins spécialistes, peu importe ... Cependant, ils doivent partager certaines qualités communes : l'ouverture d'esprit, la capacité à travailler en équipe et à collaborer et le désir d'apprendre et de se dépasser. Il n'y a pas de mal à avoir un expert (spécialiste) d'une technologie dans une équipe pour autant qu'il est en mesure de partager sa connaissance et d'accepter qu'il a peut-être tord et qu'il existe une solution mieux adaptée au problème à résoudre. Il doit être ouvert à faire des compromis ou même à changer son fusil d'épaule. Au même titre que, le généraliste doit être en mesure de profiter de la connaissance de son collègue pour ajouter une corde à son arc et reconnaître qu'il est plus expérimenté dans un domaine donné.

Ce qui tue une équipe, c'est la hiérarchie et l'individualisme. En TI, nous avons la fâcheuse tendance à vouloir hiérarchiser les rôles dans une équipe en leur accordant plus ou moins d'importance : programmeur, analyste, architecte, gestionnaire de projet, directeur, etc. Chaque joueur d'une équipe a un rôle important. Enlever vos programmeurs, pensez-vous réaliser une solution complète ? De plus, qu'est-ce qui empêche un programmeur de participer à l'architecture du système ? Ou vice-versa, à l'architecte de participer à la programmation ? Chacun a ses forces et faiblesses et chacun a à tirer profit de l'expérience et la connaissance de l'autre.


La force d'une équipe est donc d'exploiter les forces de chacun, de les mettre à profit pour acquérir une plus grande maturité collective. Pour ma part, le débat n'est pas de savoir si mes membres qui composent mon équipe sont des généralistes ou des spécialistes ou les deux. Ma préoccupation et plutôt de mettre en place une équipe en mesure d'affronter n'importe quel défi en équipe tout en étant flexible. Au final, ce qui compte, ce que mon équipe soit AGILE !

Aucun commentaire:

Enregistrer un commentaire