Souvenir d’eXtreme programming #3 : Convertir l’équipe
Voici la suite de notre grand feuilleton sur la mise en place d’eXtreme progamming. Notre CTO, après avoir convaincu le management, va-t-il convaincre l’équipe ?
De l’importance de l’équipe
Au delà du management, c’est surtout avec l’équipe qu’on réussit la mise en place d’une méthodologie (quel qu’elle soit).
Alors pour une méthode comme eXtreme Programming, centré sur l’équipe plus que les process, c’est crucial.
On commence d’abord par une présentation, plus complète que celle prévue pour le management. Après un “teasing” d’enfer, avec convocation de toute l’équipe sans préciser la raison, et une question sur le mode de l’auto-analyse, la méthode est présentée.
Première présentation
L’équipe accepte globalement bien les valeurs, malgré une certaine ironie. Finalement l’ironie est une autre manière qu’exprimer les mêmes réserves que le management quand à l’incompatibilité des valeurs de XP par rapport aux valeurs de l’entreprise.
Concernant les pratiques, la discussion a été plus rude, sur le mode “c’est bien, mais pas pour nous !”, ou alors “ça a l’air bien , mais comment on va faire ?”.
Le développement conduit par les tests, qu’il est difficile à expliquer de façon abstraite, alors qu’une démonstration rend l’explication évidente, est un particulièrement saillant durant cette présentation. On décide donc d’organiser une formation spécifique sur ce sujet.
L’acceptation des tests de recette se heurte à une vrai difficulté du développement le tests des interfaces. On en parlera plus plus tard avec NUnitAsp.
Le remaniement est un peu difficile à accepter, d’autant que la doctrine en place était plutôt d’éviter les “optimisations” intempestives. Mais au final ce n’est pas vraiment la même chose, d’autant que le remaniement n’est possible que si on dispose de tests unitaires complets.
La métaphore ne provoque pas de réaction, ce qui prédestine un peu son avenir dans le projet, c’est à dire son absence !
L’autre point bloquant est la programmation en binôme, d’abord parce que certains individualistes forcenés s’y opposent, et que les autres commencent déjà à chercher leur binôme permanent. Il faut donc rappeler fermement que les binômes changent fréquemment, quitte à décevoir les couples déjà formés !
Pour les règles de codage, le fait que les règles sont définies par l’équipe fait l’unanimité. On planifie une réunion consacrée à ce sujet.
La conception simple et la responsabilité collective du code font l’unanimité, sans réserve. L’intégration continue, les livraisons fréquentes, la planification itérative et le client sur site sont quasiment déjà en place. Et quand au rythme durable, grâce aux 35 heures, est déjà bien en place !
Évidement les plannings games intéressent paradoxalement beaucoup plus les développeurs que les fonctionnels du marketing produit. Encore cette crainte de devoir assumer plus de responsabilité dans la gestion des projets. Décidément le coté “boite noire” des équipes de développement ne profite pas qu’aux développeurs !
La présentation est ensuite suivie par un grand classique des consultant XP, le fameux XP-Game.
Et bien jouez maintenant.
On trouve un peu partout des exemples de XP-Games, notamment ici.
Le but du XP-Games est d’illustrer de façons ludique les pratiques XP dans un contexte non-informatique, afin de les faire comprendre pas tous.
Le pair programming s’illustre notamment par un dessin réalisé en binôme après avoir demandé à chacun de réaliser le même dessin seul. On se rend compte que les dessins en binômes sont globalement mieux réussis que les dessins réalisés seuls (sauf s’il y a un très bon dessinateur).
Ensuite on illustre la méthode de travail itérative avec un projet simple et fictif, par exemple créer un réfrigérateur. Le marketing écrit des scénarios d’utilisation et détermine leurs valeurs, les développeurs estime leurs coûts. Ensuite on classe les scénarios en combinant leurs valeurs et leur coût. Puis les développeurs les réalisent. On peut même illustrer le développement conduit par les tests en rédigeant les tests de validation en amont. Souvent on arrive à obtenir un four plutôt qu’un réfrigérateur, ce qui illustre bien les dérives naturelles des projets !
Au final un bon moment de détente, plein d’enseignements et de promesses pour la suite.
Tout reste à faire
Le risque après une journée de sensibilisation comme celle ci, c’est que tous le monde retourne à son poste et continue à travailler comme avant. Pour éviter cela, une réorganisation spatiale s’impose.
A suivre…