samedi 14 janvier 2012

Mes deux cents : "Quelques mauvaises pratiques"

Ceux qui ont lu les quelques billets de mon blog auront bien senti que je suis très enthousiaste à propos de Scrum et d'Agile. C'est parceque j'ai connu des situations de mauvaises pratiques, et qui n'arrivaient plus dès lors que j'ai commencé à travailler sur des projets Scrum. Oui, j'ai connu du grand n'importe quoi avant de découvrir Scrum. Et voici quelques anecdotes :)

- J'avais 22 ans et j'étais plein de motivation et d'espoir pour le futur. Lors d'un projet de refonte, le chef de projet présente une solution pour la nouvelle interface et de façon naïve j'osais m'exprimer ainsi : "ah non, je suis pas d'accord sur cette solution". Réponse du chef de projet : un grand rire bruyant suivi de "non mais on te demande pas ton avis, on te demande de faire". J'étais renvoyé dans les cordes et je me suis vu me faire remettre en place : celle d'un ouvrier à qui on ne demande pas de penser. Vous vous rendez bien compte que se faire couper ainsi dans son élan coupe également toute motivation. J'étais passé dans ma tête d'une obligation de résultat à une obligation de moyen. Une équipe est une équipe car les gens sont différents et ont des idées différentes. Certains vont voir des solutions à des problèmes lorsque d'autres seront bloqués et vice-versa. C'est cette collaboration et cet apport d'idées de toutes parts qui fait la richesse de l'équipe. Il est inutile de croire qu'une personne peut avoir toutes les réponses. Et dans le cas de mon anecdote, c'est ce que le chef de projet pensait : sa solution était la bonne, quoiqu'en pensent les membres de l'équipe. La conséquence avec ce genre de management est que si moi ou un membre de l'équipe s'aperçoit d'une mauvaise pratique, un trou de sécurité ou tout autre problème, nous sommes encouragés à ne rien dire et ça tombe bien, c'est ce qu'on nous demande : implémenter une solution, même si elle est mauvaise. J'ai écrit de la m**** ? Ce n'est pas grave car c'est ce qu'on m'a demandé de faire et j'ai donc "réussi" ma mission :/ Ok, j'avais 22 ans à l'époque et ça ne se serait pas passé comme ça si ça arrivait aujourd'hui, je le reconnais ;)

- C'est une anecdote arrivée à des membres de mon équipe et à moi-même aussi. Les équipes ont souvent un outil d'intégration continue tel que Jenkins. Si celui-ci détecte que des tests unitaires ne passent pas à cause de régressions par exemple, il lance une alerte. Il s'avère que sur certains projets, c'est un outil qui sert de joujou à pointer la "nullité" des uns et des autres. "Machin, tu as cassé le build !" (traduction : "t'es vraiment une tâche !") comme si c'était le projet en entier que cette personne venait de planter... Comme le disait judicieusement un ancien collègue : "Ce n'est pas grave de casser le build ! L'important est de le réparer !" Et c'est bien cela qui importe : pourquoi avoir un outil de surveillance si l'on considère qu'il ne doit jamais passer à un autre état que "OK" ? Ce qui importe lorsque l'état du build est KO est de s'en rendre compte vite et d'intervenir au plus vite, et non de perdre son temps à dire à la personne en cause comme ce qu'il a fait est mal, etc...
- Ahlala, c'était toujours un moment particulier quand mon chef de projet me tendait une feuille avec un boulot à faire pour dans 3 jours. Une question qu'avait soulevée un collègue de cette mission me paraissait pourtant pertinente : "Mais qui a estimé cela à trois jours ?". Le chef de projet nous donna une réponse avec une telle confiance dans la voix qu'elle en semblait presque logique et légitime : "et bien il y a des concepteurs très expérimentés là qui ont pour rôle d'écrire les specs et de les estimer". Whoa! Heureusement qu'il y avait ces types pour nous dire combien de temps on allait mettre pour développer tel ou tel module. C'est pas grave s'ils ne connaissaient rien à Java et ne nous connaissaient pas non plus vu qu'ils ne nous ont jamais parlé en un an et demi. Vraiment, on se demande pourquoi on demanderait leur avis aux développeurs...

Bon je m'arrête là sinon on va croire que je n'ai rencontré que des galères dans ma vie... :P

3 commentaires:

  1. Bon allez maintenant le même billet mais avec le titre : "Mes deux cents : "Quelques bonnes pratiques"" ...

    RépondreSupprimer
  2. Ah ah ah. J'ai comme l'impression de reconnaître les situations. Je te renvoie à 3T, qui a été conçue spécialement avec ton dernier point en ligne de mire. En effet, les concepteurs invisibles, qui ne nous parlent jamais, on les implique dans le projet. Ils écrivent des spécifications immédiatement traduites en contrat sous forme d'interfaces Java, puis sous forme de test dans la foulée. Si on fait ça alors peu importe qu'on les croise ou non dans les couloir. Ils auront fait leur partie du job. A partir de maintenant, je considère qu'un cahier des charge est acceptable à la seule condition qu'il me permette d'écrire une interface et les tests associés. Le reste est mon affaire. Si le cahier des charges ne répond pas à cette demande simple, autant le mettre directement à la poubelle parce que c'est du vent.

    RépondreSupprimer