Déspécialisation
Par Bernard Notarianni le lundi 4 février 2008, 22:33 - Lien permanent
Kent Beck nous propose dans sa méthode eXtreme Programming d’adopter sur nos projets la pratique de propriété collective du code. Il propose que l’application soit comprise et maitrisée par tous les membres de l’équipe.
A titre d’exemple, une équipe peut mettre cette pratique en œuvre au travers des actions suivantes :
- Les développeurs travaillent en binômes sur une grande majorité du codage de l’application. Les binômes tournent régulièrement. (Pair Programming)
- Aucune personne ne se spécialise dans un module ou une partie de l’application en particulier. L’équipe évite de se retrouver avec un spécialiste de la base de données, du build, du framework IHM ou de l’architecture générale de l’application.
- Tout le monde participe à l’effort de création des jeux de tests unitaires et fonctionnels. L’équipe évite d’avoir une personne dédiée uniquement à la qualité.
L’absence de spécialisation des membres de l’équipe apporte entre autres les bénéfices suivants:
- Si une personne s’absente de manière volontaire ou involontaire, l’équipe peut continuer à faire avancer le projet. Le client n’est pas obligé d’organiser le contenu des itérations en fonction de la disponibilité des spécialistes.
- Les conventions de conception et d’implémentation adoptées par l’équipe sont suivies de manière homogène sur l’ensemble de l’application. L’application devient plus maintenable.
- Les membres de l'équipe sont responsabilisés sur l'ensemble de la livraison de l'application. L'alignement est renforcé.
Ces effets sont connus et il est aisé de comprendre leur valeur intrinsèque. D’autres bénéfices plus subtils apparaissent grâce à la propriété collective du code.
Dans une équipe avec spécialisation, il est difficile de parler des difficultés qui apparaissent sur les modules des spécialistes. Les membres de l’équipe ont tendance à éviter le conflit (à tord ou à raison) et n’osent pas discuter le travail d’un spécialiste. Qu’il s’agisse de la conception d’un module java, d’un schéma de base de donnée relationnelle, du choix d’un outil ou de l’architecture, si un de ces éléments est confié à un spécialistes (expert, DBA, architecte..) il aura moins de chance d’être amélioré par les feedback de l’équipe.
De même, si un spécialiste se sent en difficulté sur son domaine, il sera plus difficile pour lui de l'exprimer car par nature, il n’a pas l’habitude de demander de l’aide à ses coéquipiers.
Les membres d’une équipe sans spécialiste peuvent plus facilement discuter des difficultés qu’ils rencontrent. Ils se sentent tous responsables du code produit. Ils peuvent discuter de la qualité sans avoir le sentiment de remettre en cause les compétences des autres membres de l’équipe.
La déspécialisation va à l’encontre des habitudes que nous a imposé l’ère industrielle depuis des décennies. C’est pour cela qu’il est difficile de l'adopter. Pourtant, ses vertus sont nombreuses, et permettent souvent d’aller plus loin, plus vite, contrairement à ce que nous expliquait Taylor au début du 20eme siècle. L’industrie l’a compris depuis Toyota et l’approche Lean. Il est temps que nous suivions le même chemin dans l’informatique.