Accusé, levez-vous !
22 déc. 2006 Olivier Azeau En français 4
Hier, je parlais de l'article de Valtech Mag sur le chef de projet agile et de l'utilité d'une telle notion. Le hasard a fait que je lise ce soir un billet de Tom Looy sur le DDR : "Développement Dirigé par la Responsabilité" (ou ADD : Accountability Driven Development en version originale).
Le hasard faisant, selon la formule, toujours bien les choses, Tom Looy apporte une réponse à une des questions que je me posais : qu'est-ce qui pousse les gens à encore raisonner en termes de chef de projet là où il n'y en a plus forcément besoin ?
La réponse de Tom Looy est si limpide que je vais me contenter de traduire sa prose.
"Avec le DDR, on est sûr de trouver une personne reponsable pour chaque phase d'un processus de développement logiciel. Dès le début, on a quelqu'un dont la responsabilité est de rassembler les exigences. Puis on a quelqu'un d'autre responsable de la définition d'une architecture avant le début des développements. Ensuite, la responsabilité est transmise au chef de projet et aux développeurs pour la livraison du logiciel et, enfin, à l'équipe de test. J'appelle ça la responsabilité définie par les rôles".
Relisons maintenant le passage le plus savoureux du Valtech Mag :
"Dans un projet agile, des rôles — et non des tâches — sont assignés aux membres de l’équipe. Chaque rôle est assorti de droits et de responsabilités. La mission du chef de projet consiste à délimiter les droits et les responsabilités de chaque rôle en collaboration avec la personne chargée de l’exécuter. Elle consiste également à vérifier que chacun respecte les droits des autres et assume ses propres responsabilités."
Tout s'éclaire ! Pour s'assurer que ces satanés développeurs feront bien leur boulot, on leur donne non pas des tâches mais des rôles assortis d'une responsabilité : celle de livrer le code. Le chef de projet est nécessaire car son rôle a 2 responsabilités cruciales : délimiter ces responsabilités (tout le monde sait bien que si on ne cadre pas un développeur, il passe sa journée à surfer sur le net) et vérifier que le développeur les assume (au besoin en lui promettant une absence de prime dans le cas contraire ?).
Ce DDR est vraiment une technique de développement qui peut énormément apporter en efficacité. Toutefois, avant d'aller en parler à ses collègues de boulot (ou pire à son chef de projet), il est conseillé de lire Tom Looy jusqu'au bout. Le DDR a 4 défauts, mineurs certes, mais qu'il ne faut pas ignorer (là encore, je vais me contenter de traduire).
Les conséquences d'une trop grande emphase sur le rôle et les responsabilités de chacun sont évidentes. Le détenteur d'un rôle aura tendance à ne regarder que son pré carré. Il essaiera, tel un Charlie Chaplin des temps modernes d'optimiser son résultat individuel en perdant de vue le dessein d'ensemble. Quand il se rendra compte que de son résultat individuel dépend directement celui de son voisin, il essaiera par tous les moyens de verrouiller sa production pour ne pas être tenu pour responsable de l'echec de la chaîne. Ce verrou prendra un aspect tellement formel que l'ensemble du processus sera sclérosé. Pour finir, quand l'échec sera là (car --sauf coup de chance-- il sera là), le coupable sera celui qui aura su le moins bien se protéger ou , selon le point de vue que l'on prend, celui qui se sera mis le plus à découvert pour faire avancer le schmilblic.
Beaucoup de gens qui tentent une approche de l'agilité passent à côté d'une notion primordiale, celle de la responsabilité collective. Dans une formation XP à laquelle j'assistais, un des participants a eu cette remarque fort juste : "XP c'est du communisme alors que notre façon habituelle de travailler, c'est du capitalisme".
Ce communisme, car c'est bien de cela qu'il s'agit, est très difficile à accepter dans la culture actuelle de la plupart des entreprises ou l'on ne parle que d'objectifs et d'entretiens d'évaluation individuels. C'est pourtant un pré-requis incontournable et il passe obligatoirement par la confiance envers les autres. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
Le hasard faisant, selon la formule, toujours bien les choses, Tom Looy apporte une réponse à une des questions que je me posais : qu'est-ce qui pousse les gens à encore raisonner en termes de chef de projet là où il n'y en a plus forcément besoin ?
La réponse de Tom Looy est si limpide que je vais me contenter de traduire sa prose.
"Avec le DDR, on est sûr de trouver une personne reponsable pour chaque phase d'un processus de développement logiciel. Dès le début, on a quelqu'un dont la responsabilité est de rassembler les exigences. Puis on a quelqu'un d'autre responsable de la définition d'une architecture avant le début des développements. Ensuite, la responsabilité est transmise au chef de projet et aux développeurs pour la livraison du logiciel et, enfin, à l'équipe de test. J'appelle ça la responsabilité définie par les rôles".
Relisons maintenant le passage le plus savoureux du Valtech Mag :
"Dans un projet agile, des rôles — et non des tâches — sont assignés aux membres de l’équipe. Chaque rôle est assorti de droits et de responsabilités. La mission du chef de projet consiste à délimiter les droits et les responsabilités de chaque rôle en collaboration avec la personne chargée de l’exécuter. Elle consiste également à vérifier que chacun respecte les droits des autres et assume ses propres responsabilités."
Tout s'éclaire ! Pour s'assurer que ces satanés développeurs feront bien leur boulot, on leur donne non pas des tâches mais des rôles assortis d'une responsabilité : celle de livrer le code. Le chef de projet est nécessaire car son rôle a 2 responsabilités cruciales : délimiter ces responsabilités (tout le monde sait bien que si on ne cadre pas un développeur, il passe sa journée à surfer sur le net) et vérifier que le développeur les assume (au besoin en lui promettant une absence de prime dans le cas contraire ?).
Ce DDR est vraiment une technique de développement qui peut énormément apporter en efficacité. Toutefois, avant d'aller en parler à ses collègues de boulot (ou pire à son chef de projet), il est conseillé de lire Tom Looy jusqu'au bout. Le DDR a 4 défauts, mineurs certes, mais qu'il ne faut pas ignorer (là encore, je vais me contenter de traduire).
- "La responsabilité de rôle est basée sur la croyance erronée que la spécialisation est une bonne chose"
- "La responsabilité de rôle rend les gens hésitants à faire avancer le travail"
- "La responsabilité de rôle tend à transformer les relations entre les rôles en autant de contrats"
- "Le DDR n'a pas pour but de produire un logiciel mais de désigner un coupable en cas d'échec"
Les conséquences d'une trop grande emphase sur le rôle et les responsabilités de chacun sont évidentes. Le détenteur d'un rôle aura tendance à ne regarder que son pré carré. Il essaiera, tel un Charlie Chaplin des temps modernes d'optimiser son résultat individuel en perdant de vue le dessein d'ensemble. Quand il se rendra compte que de son résultat individuel dépend directement celui de son voisin, il essaiera par tous les moyens de verrouiller sa production pour ne pas être tenu pour responsable de l'echec de la chaîne. Ce verrou prendra un aspect tellement formel que l'ensemble du processus sera sclérosé. Pour finir, quand l'échec sera là (car --sauf coup de chance-- il sera là), le coupable sera celui qui aura su le moins bien se protéger ou , selon le point de vue que l'on prend, celui qui se sera mis le plus à découvert pour faire avancer le schmilblic.
Beaucoup de gens qui tentent une approche de l'agilité passent à côté d'une notion primordiale, celle de la responsabilité collective. Dans une formation XP à laquelle j'assistais, un des participants a eu cette remarque fort juste : "XP c'est du communisme alors que notre façon habituelle de travailler, c'est du capitalisme".
Ce communisme, car c'est bien de cela qu'il s'agit, est très difficile à accepter dans la culture actuelle de la plupart des entreprises ou l'on ne parle que d'objectifs et d'entretiens d'évaluation individuels. C'est pourtant un pré-requis incontournable et il passe obligatoirement par la confiance envers les autres. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
"Je vais te dire comment ils fonctionnent les gars[1], tu en choppes un et tu lui dis toi tu es responsable de tel morceau, toi de tel autre. Si tu fais pas ça, ils font tous leur truc dans leur coin sans jamais se concerter"
[1] de l'équipe de développement
C'est évidemment dans un context pas très agile et on est bien loin de la responsabilité collective...
Les principes agiles disent "Build projects around *motivated* individuals". Si un ensemble de développeurs n'est pas suffisamment motivé pour travailler collectivement, le meilleur résultat sera peut être obtenu en ne les faisant pas travailler collectivement...
C'est à mon avis une des limites fortes du modèle agile : l'adhésion des développeurs à ces principes. Un salarié qui vient juste faire ses heures sans avoir une quelconque envie de progresser en essayant de donner plus aux clients sera très difficile à convertir au modèle agile. Pourquoi ferait-il un quelconque effort dans cette direction ?
Je suis d'accord, il faut remporter l'adhésion de l'équipe avant de commencer. La proposition de tendre vers un "pur plaisir de coder" (http://www.sigmat.fr/index.php?post...) est-elle envisageable comme moteur ou comme motivation individuelle ?
Et ce qui me plait encore plus dans le "plaisir" comme objectif c'est que l'on ne peut l'imposer à personne ! Mais cela pourrait-il être suffisamment tentant pour attirer nos "faiseurs d'heures" ??