Présentons tout d’abord Alex et Fred, deux développeurs Java plus ou moins fraichement sortis de l’école. Comme beaucoup de jeunes ingénieurs, ils font leurs premières armes en SSII. Un entretien plus tard, c’est parti pour l’aventure : ils sont placés en régie sur un super projet, il y a une ambiance terrible dans l’équipe ! D’ailleurs la première semaine est ponctuée par 2 pots (de départ), idéal pour faire connaissance avec tout le monde.

Cette série d’articles présentera sous forme de petites histoires, des problèmes vécus par nos deux amis et les solutions qu’ils ont pu y apporter (parfois)… Allons maintenant voir comment s’en sort Alex…

Le problème

Alex est placé dans un bureau avec les 2 experts techniques du projet (Marc et Victor), c’est un encadrement idéal !
Marc donne assez rapidement plusieurs gros paquets de feuilles reliées à Alex (arrondissons à 200 pages).
- Tiens ! Voilà la doc du projet, il faut commencer par là. Bon courage !

Finalement la journée n’aura pas eu raison de la doc… Alex aurait bien voulu se rendre utile, mais bon avec la mise en prod « tout le monde est débordé»  et « de toute façon après, on ne sait pas ce qu’il y a à faire» . Alex aurait bien voulu poser quelques questions aussi, mais ils ont surement raison « regarde dans la doc»  et « ne cherche pas sur l’intranet, il n’y a rien !»  est une bien meilleur idée (tout le monde est occupé après tout !).
Le lendemain, Alex est en formation sur l’architecture du projet (de toute façon la doc n’est pas très claire sur ce point…). Une collègue présente depuis longtemps sur le projet lui explique le fonctionnement du framework – bien plus simple que l’ancien – toute la matinée. Malgré ses 10 pages de notes Alex n’a pas tout compris et ne voit pas en quoi ça ressemblait à ce qu’il y avait écrit dans la doc, mais il est content car on lui a confié un correctif à faire l’après midi !

Oui, mais la documentation n’aide pas beaucoup pour savoir à quelle portion de l’application correspond cette anomalie (où est donc l’écran de modification des rejets brouillons ?!)… finalement Alex va mettre 3 semaines à livrer le correctif ! Il n’a pas pu poser beaucoup de question, la doc reste muette, tout le monde semble toujours très occupé sur ce projet, et puis le temps qu’il obtienne les habilitations pour cette partie de l’application… Alex aura compris que personne n’utilisait la doc (elle ne semblait d’ailleurs pas tout à fait à jour) et n’aura livré son correctif qu’après de nombreux tâtonnements et efforts douloureux. Ouf ! Heureusement il y a une bonne ambiance dans l’équipe !

La solution ?

Avec Fred qui a vécu une expérience similaire, ils se décident à mettre en place un Wiki pour le projet ! Quel drôle de mot ! Mais à quoi ça sert au juste se demande l’équipe ?
Une fois expliqué l’importance d’une base de connaissance opérationnelle sur le projet, l’équipe rigole doucement mais ne s’oppose pas à sa création. On les mets toutefois en garde que cela ne leur prenne pas trop de temps car il y a des correctifs à faire ! Bien que le wiki soit un sujet de moqueries récurrent, Alex et Fred ne se découragent pourtant pas de l’alimenter régulièrement…

Finalement après une année et un démarrage difficile, force est de constater que ce wiki est devenu la base d’informations de référence du projet : sur les problèmes récurrents rencontrés, les bonnes pratiques et l’essentiel de ce qu’il faut savoir pour travailler sur le projet. Il est alimenté par toute l’équipe et il paraîtrait même que d’autres projets viennent y jeter un oeil…

Mais au fait, où sont passées les 200 pages de doc techniques ? Ah oui, je crois qu’elles n’ont pas survécu au dernier changement de bureau… mais ça personne ne l’a remarqué.