Imaginez un peu… Un projet informatique… Une équipe d’informaticiens… Et un taux de rotation des effectifs comme on n’en a jamais cauchemardé dans les pires des SSII offshore en Inde: les personnes restent rarement plus de 3 semaines/un mois sur le projet !
C’est le challenge méthodologique des missions solidaires pour prestataires en inter contrat: des prestas qui se relaient dans une équipe projet auprès d’une ONG le temps qu’on leur retrouve une « vraie » mission. Badr Chentouf soulignait l’importance de ce challenge méthodologique dans un commentaire récent. Comment rendre productive une telle équipe projet dont le gros des troupes ne reste que très peu de temps? Comment limiter la « charge d’entrée » sur le projet? Comment modeler la courbe d’apprentissage?
Dans un tel contexte, les méthodes les plus agiles pourraient paraitre on ne peut plus rigides et inadéquates, non? L’eXtreme Programming n’a pas été conçu pour gérer ce genre de situation, pas vrai?
Et même si, dans les communautés open source, on peut intervenir en peu de temps pour proposer un patch ou corriger un bug, la communauté repose sur des piliers permanents qui suivent le projet depuis de longues années et assurent que le mouvement brownien des contributeurs se traduit en évolution réelle à moyen terme.
Les outils de gestion de connaissances les plus ambitieux proposent de partager la connaissance des experts de l’entreprise avant qu’ils ne partent à la retraite. Mais il faut tout de même de longues semaines d’interview, de modélisation et de mise au point avant de bénéficier d’un système utile pour les successeurs de l’expert. Que faire en 15 jours? En mode incrémental…
Alors que faire? Comment organiser le travail et gérer sa continuité? Comment le coordonner? Comment transférer de la connaissance aux nouveaux arrivant en un temps record?
Ajouter dans l’équipe deux ou trois stagiaires qui sont là pour six mois et garantissent la continuité de la connaissance? Utiliser les méthodes comme XP en insistant sur le « pair programming » et la rotation des paires? Mettre au contraire le paquet sur la modélisation formelle à grands coups d’UML? Modéliser la connaissance du projet dans une usine à gaz de knowledge management (une « corporate memory »)? Ne jurer à l’inverse que par les wikis? S’appuyer sur un dictateur bienveillant mais bénévole et non présent sur site, qui agit comme « gatekeeper » sur le code produit? Inventer une nouvelle méthode agile à faire pâlir d’envie ses cousines?
Je n’ai pas la solution complète mais si on la trouvait, cela permettrait de mettre les meilleures technologies à la portée des ambitions des entrepreneurs sociaux les plus innovants. Quelles pistes de réflexion pourriez-vous partager?
bonjour,
Pour la gestion des connaissances je te conseil l’outils trac, qui permet d’éviter l’usine a gaz en restant quand même efficace.
En temps que chef de projet scrum dans un context similaire (turn-over de l’équipe enorme), j’ai obtenu de très bon résultat.
cordialement