Le collective code ownership et ses nombreuses implications

February 7th, 2005 par Freddy Mallet

PS: tous les articles concernant les méthodologies agiles se trouvent également sur le site xp-swiss

Le collective code ownership fait partie de ces nombreuses pratiques agiles relativement faciles à expliquer mais dont les ressorts sont plus difficiles à comprendre qu’il n’y paraît. Bon nombre de personnes aux frontières de l’agilité regarde cette pratique d’un oeil certes complaisant mais ont tendance à la qualifier de doux rêve humaniste. Après tout, le collective code ownership peut vaguement ressembler à une pratique d’anarchistes sentimentaux non ? Et bien non et non et définitivement non. Pour tout vous dire, je ne suis pas bien sûr qu’une quelconque pensée humaniste ait traversé l’esprit de Kent Beck quand il a élevé cette pratique au rang des 13 commandements XP et voici mon raisonnement.

Tout d’abord un bref rappel sur ce qu’est le collective code ownership et peut être surtout sur ce qu’il n’est pas. Vu de très loin le collective code ownership consiste à dire que l’ensemble du code d’une application est sous la responsabilité collective de toute l’équipe XP. Par conséquent tout développeur de cette équipe XP a le droit (et dans certains cas le devoir) de toucher à n’importe quelle ligne de code de l’application. Si on en reste à cette définition le responsable du projet n’a plus qu’à demander à sa belle-mère d’aller lui faire brûler quelques cierges à Fatima et à Lourdes. Il est en effet essentiel de replacer cette pratique au sein de l’ensemble des pratiques XP. Quand on touche à une ligne de code et qu’on fait de l’XP on a le DEVOIR de :

* Coder / Modifier les jeux de tests unitaires en lien avec le changement
* Faire le changement à deux
* Coder de la manière la plus simple qui soit pour répondre uniquement à la problématique soulevée
* Refactorer si possible par petites étapes successives
* Respecter toutes les normes de codage en vigueur sur le projet

et pour assurer encore plus ses arrières, l’équipe XP et le responsable du projet ont le ‘'’DEVOIR”’ d’avoir un mécanisme d’intégration continue en permanence opérationnel qui assure le plus régulièrement possible (au moins une fois par jour) que :

* Le code contenu dans le SCM compile
* Tous les tests unitaires passent
* Tous les tests fonctionnels passent

Si vous avez respecté tous vos devoirs, vous pouvez rappelez votre belle-mère et dormir sur vos deux oreilles. On peut noter à ce stade que beaucoup de gens non convaincus par le collective code ownership ne le sont justement pas car ils évoluent dans un processus de développement artisanal qui ne leur offre pas les gardes-fous nécessaires au passage de la 5e vitesse. Si tous vos voyants sont au vert, que vous êtes prêt à passer cette fameuse 5e vitesse, que va vous apporter le collective code ownership ?

Dans les entreprises, le processus de développement est le plus souvent issu d’un effort de formalisation des pratiques qui ont fonctionné dans les projets précédents mais également d’une suite de règles édictées en contre réaction à des problèmes rencontrés. Exemple :

Paul travaille sur un nouveau projet tout seul depuis 4 mois. Personne n’a trop eu le temps de jeter un coup d’oeil sur son travail jusqu’au jour où la première version passe en production. Paul quitte l’entreprise 3 mois après le passage en production de l’application et un autre prestataire reprend le flambeau. Seulement voilà, le nouveau prestataire est écoeuré par le design de l’application, ne comprend rien à rien, les bugs s’enchaînent, les clients sont mécontents, blablabla. Contre réaction naturelle à ce genre de problème : sur les prochains projets l’architecture logicielle sera étudiée et validée en amont avant de passer le relais à un développeur, les développeurs doivent pondre une documentation exhaustive de leur développement pour faciliter le passage de relais, l’équipe de management repasse sur tous les projets pour savoir exactement quel développeur est responsable (pas encore coupable mais ça ne saurait tarder) de quel bout de code.

C’est exactement le genre de réaction que l’on a lorsqu’on a mal au ventre. On sait pertinemment que notre salut passe par un effort (pas du tout évident mais tout de même essentiel) de relaxation alors que naturellement on a tendance à se contracter, à se replier sur soi.

Le collective code ownership correspond à cet effort pas du tout évident de relaxation, d’ouverture pour au final mieux maîtriser les choses. La motivation d’une équipe de développement résulte en partie directement du niveau de responsabilité qu’on est prêt à leur accorder (c’est une lapalissade). Si on reprend l’exemple précédent et qu’au lieu d’en appeler à l’architecte, à la documentation et au bâton on prend un binôme de développeurs et qu’on leur dit :

« Nous avons fait une erreur de management sur la conduite de ce projet et nous actons ce point. Maintenant, nous sommes dans une situation critique, l’application est essentielle au bon fonctionnement de l’entreprise, le code existant n’est pas fameux mais nous ne pouvons repartir de zéro. Nous nous engageons mutuellement (côté client et développeurs) à respecter les pratiques XP, vous êtes désormais tous les deux collectivement responsables de l’application et des choix d’architecture. Nous tiendrons tous les jours un standing meeting pour suivre au plus prêt l’évolution du projet. Nous avons confiance en vous, bon travail ! »

Voici ce que le terme collectivement apporte à ce discours :

* Quand on écrit une ligne de code, on sait que cette ligne de code ne nous appartient pas et pire qu’elle peut rapidement (dans le quart de seconde si pair programming) subir la critique d’un oeil externe certes amical mais tout de même affûté. Conclusion, on réfléchit à deux fois avant de nommer les méthodes, les variables. Quand une fonction fait 80 lignes, on sait qu’il faut refactorer avant que l’ami ne le fasse. On écrit des jeux de tests unitaires parce que lorsqu’on touche au code de l’ami on est bien content à son tour de trouver des jeux de tests qui sont une sorte de filet de sécurité. Bref, il se produit un phénomène d’émulation qui engendre un code de bien meilleur qualité.
* Quand un bug est découvert en production, la question n’est plus de savoir qui est le responsable du bug et qui va corriger ce bug, la seule pensée est : « Je dois corriger ce bug ».
* Encore mieux, si un bug ou un mauvais pattern est découvert durant le cycle de développement on prend son marteau et on y va. Dans une équipe cloisonnée, dans le meilleur des cas le développeur en charge du ‘code smell’ est averti, dans le pire des cas, rien ne se passe et le bug surgira en production.
* Si le bateau commence à être chahuté en raison de problèmes en production et que tout l’équipage se sent concerné vous avez nettement plus de chance de rétablir la situation.

Bref au final, vous vous retrouver avec une application qui tourne, un nombre de bugs en diminution, une augmentation progressive de la vitesse de livraison des fonctionnalités, une équipe de développement stabilisée (quand on permet à un développeur de s’épanouir en faisant de l’XP, il réfléchit à deux fois avant d’aller voir ailleurs), et si un nouveau développeur arrive il y a de forte chance qu’il n’ait pas besoin d’une quelconque documentation pour comprendre le fonctionnement de l’application.

Donc la prochaine fois que vous avez mal au ventre, pensez à vous relaxer, à respirer… ;-)

5 Responses to “Le collective code ownership et ses nombreuses implications”

  1. Franck Says:

    Que dire sinon merci pour cette synthèse, On pourrait éventuellement critiquer la conclusion un peu trop happy end ;-)
    En fait je m’aperçoit que les méthodes dites agiles remettent l’humain au centre de la méthode. Ce n’est pas le fait de savoir faire un diagramme UML qui est vraiment important mais plutôt le comportement social à adopter.
    Merci Freddy

  2. Freddy Mallet Says:

    C’est en effet un peu cela. Le meilleur exemple est le standing meeting. Je suis certain qu’à l’usage des personnes seront tentées de dire:

    - et pourquoi ne pas faire une page de résumé du standing meeting sur l’intranet ?
    - les développeurs ne pourraient-ils pas présenter leurs questions/affirmations/sujets du jour sur l’intranet avant la réunion ?
    - en fait si on arrive à mettre en place un portail collaboratif digne de ce nom sur l’intranet est-ce que le standing meeting a toujours sa raison d’être ?

    et là encore on peut se dire, bin oui pourquoi pas, on formalise un processus, on garde une trace écrite, ce processus est moins dépendant de facteurs humains, bref c’est plus professionnel. Et bin ce serait surtout une grosse boulette car:

    - le standing meeting oblige à écouter ce que l’autre a à dire
    - quand on aborde des problèmes difficiles (relationnels, comportementaux, etc..) il est toujours préférable de se dire les choses en face
    - le fait de s’exprimer devant l’ensemble de l’équipe avec un temps compté, oblige à un effort de synthèse et de justesse du propos
    - on perd généralement beaucoup moins de temps à s’exprimer par orale que par écrit
    - l’information véhiculée durant un standing meeting aura certainement très peu de valeur dans 6 mois mais elle a par contre une valeur capitale à court terme (de feedback ) qu’il faut absolument saisir.

    le développement informatique est une activité humaine et à ce titre le processus suivi doit pleinement intégré cette dimension plutôt que d’essayer de la minimiser pour s’abstraire virtuellement du risque humain.

    je suis assez content de mon exemple…

  3. Franck Says:

    Bon d’accord il sort quand ton bouquin sur les méthodes agiles ?
    Je veux une dédicace ! :-)

  4. Eric Says:

    Les précommandes sont-elles ouvertes ?
    Si tel est le cas, j’en commande un aussi! Je pourrais le mettre à côté de celui co-écrit par Sandra : Le FMI - De l’ordre monétaire aux désordres financiers, Economica, Paris, 2000. :-)

  5. Freddy Mallet Says:

    A bien y réfléchir l’humour n’est pas une valeur mentionnée dans les différentes méthodologies agiles, il y a peut être un truc à faire sur ce thème. Vous êtes vraiment des perles… ou simplement des groins de cochons capables de dénicher les plus belles truffes ;-) .

Leave a Reply

You must be logged in to post a comment.