Je n'aime pas les radars

Voilà c'est dit !

J'entends certains me dire : "Mais Guillaume qu'est ce que tu racontes là, on s'en fout de ton avis sur la sécurité routière ! Nous on veut savoir comment bien faire du Drupal."

Et vous avez raison !
Voici donc pourquoi je me suis fendu de ce titre pour introduire une métaphore entre le développement et la conduite.

Ayant un certain âge, j'ai connu la route sans radar, j'estime avoir une certaine expérience de la conduite et tel un bon mouton citoyen responsable j'essaie, autant que faire se peut, de respecter le code de la route et donc les limitations de vitesse.
Malheureusement j'ai tendance à conduire mon véhicule à "l'oreille" tout en adaptant ma conduite au flux de circulation dans lequel je me trouve.
Autant dire les choses clairement, je ne regarde que très rarement mon compteur de vitesse, lui préférant la route devant moi, mes rétroviseurs ou mes angles morts.

Et je dois dire que cette situation m'a conduit à me faire attraper 1 ou 2 fois par un radar automatique.

Alors voilà, je n'aime pas les radars et pour pleins de raisons. Mais celle qui me dérange le plus en ce moment me pose un vrai soucis, car quand je me trouve dans une zone "surveillée", je constate clairement que ma qualité de conduite diminue, car je passe plus de temps à regarder mon compteur de vitesse que la route pour être sûr de ne pas dépasser cette foutue limitation de vitesse !

Les radars heurtent ma qualité de conduite m'amenant à des comportements potentiellement plus dangereux que s'ils n'étaient pas là. Il faut reconnaître que c'est un comble.

Et bien cher lecteur sache que c'est pareil quand tu développes ! Et il y a plein de "radars" dans un projet informatique.

  • Le radar peut être un projecteur, il fait la lumière sur un point particulier du projet et ce focus, réduit l'attention portée au reste.
  • Le radar peut être un compteur, une mesure. Et bien que les chiffres qu'il révèle soient intéressants, ils ne remplacent pas les réactions et remarques de l'équipe.
  • Le radar peut être un frein, une exigence trop rigide, qui empêche l'équipe de s'adapter.

Tout cela pour dire qu'il faut être vigilant à la présence de ces radars.


Écoutez l'équipe qui travaille, elle est la plus à même de sentir comment les choses se passent, faites lui confiance et assurez-vous que les améliorations soient mesurables (et pas l'inverse).

Soyez vigilants à atteindre vos objectifs, mais ne perdez pas de vue qu'il faut parfois savoir modifier son plan.

Restez cohérents dans vos priorités, faites les évoluer, mais ne changez pas du tout au tout.

Commentaires

Sylvain Lundi 18 mai 2015 - 17:17
Intéressante métaphore assez juste pour ma part. je dois avouer que le suis assez réfractaires aux indicateurs, mais aussi aux scrums dont je reconnais les mérites d'une manière générale (ainsi que globalement ceux de l'agilité) mais qui heurtent ma pratique personnelle du développement et ma nature : bon Je suis capable de faire avec mais je ne donne pas le meilleur de moi car plus occupé à donner le change qu'a donner tout court ... pour moi le scrum c'est un peu visite médicale tous les matins ... à poil et en rang. l'image est peut être un peu forte mais c'est pas tout à fait éloigné de ce que je ressent parfois. Enfin tout dépend aussi de l'équipe ... Bref indicateurs, agilité, c'est bien mais attentions les doses :)
Artusamak Mercredi 20 mai 2015 - 14:39
Il faut que les choses soient faites pour que ça plaise à l'équipe, comme on le dit dans un autre billet, il ne faut pas que ça soit vécu comme une punition. Si c'est le cas il faut creuver les abscès et faire renaître le plaisir. Tous les artifices de Scrum et des méthodes agiles sont là pour restaurer de la communication dans les équipes et entre les métiers pour livrer un projet à l'heure et si possible en prenant du plaisir. Il ne faut donc pas hésiter à parler des problèmes avec ton équipe. Si par exemple tu ne vois plus l'intérêt des scrums, peut être que vous ne parlez pas des bonnes choses ou que ça traîne en longueur. Expérimentez d'autres choses, demandez-vous ce que vous faites vraiment de votre temps et les choses pourront sûrement changer.

Votre commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
Votre adresse servira à afficher un Gravatar et à vous notifier des réponses. Votre commentaire sera anonymisé si ce billet est dépublié pendant plus de 3 mois.

À propos de Guillaume

Co-fondateur - Expert technique

Drupalophile depuis 2007, j'ai d’abord construit et développé des sites seul pour Aliasource avant de rapidement rejoindre l’équipe de France 24 où j'ai pu me pencher sur les problématiques liées au déploiement “live” et à la gestion d’environnements multiples pour un site de presse.
J'ai ensuite développé mes compétences au sein de Linagora dans l’encadrement technique des équipes, la formation, l’accompagnement projet et les méthodes agiles.