Quand nous arrivons quelque part, nous voyons assez bien ce qui ne va pas ou ce qui pourrait être améliorer. On a encore pas mal de recul. Puis très vite, on s'engloutit dans le quotidien et toutes ces bonnes idées s'envolent. D'habitude, je fais un rapport d'étonnement sur un cahier et/ou note les idées dans un trello. Pour plus tard.
Ou jamais.
J'ai un blog, alors autant m'engager un peu plus publiquement.
Vu sur twitter :
Demander l'autorisation de faire des tests unitaires, c'est comme demander l'autorisation d'utiliser un débugguer
J'en ai d'autres cette semaine, sur les standards :
Ne pas donner les conditions d'apparition d'un bug, c'est comme envoyer une lettre sans mettre le code postal
Le facteur peut s'en sortir, le développeur aussi, parfois. Perso, je ne compterai pas trop dessus.
Pendant l'investigation d'un problème A, on a vu par hasard une statistique de plus d'un an en base alors qu'une purge est censée supprimer les données de plus trois mois. Comme j'étais concentrée sur mon sujet et que c'était hors sujet, j'ai tiqué oralement avec mon binôme mais nous n'avons pas relevé plus que cela. C'est important de ne pas perdre le fil, autrement nous passons notre temps à changer de tâche. On n'arrive jamais à destination si on guette toutes les moustiques qui peuvent nous piquer, et encore moins si on se met à la poursuite de chacun d'entre eux. Pour autant, ne pas s'arrêter pour enlever un caillou qui nous gène peut sérieusement compromettre la course.
Quelques semaines plus tard, l'interface ne répondait plus du tout. Une des raisons était que la base de données était complètement saturée, la moindre requête prenait une éternité.
J'ai une demi heure pour parler de ma dernière mission. J'y ai vu des pratiques excellentes, dont je suis certaine de la valeur, et d'autres qui m'ont plus troublée.
Au cours d'un atelier System Thinking, j'ai eu un doute sur la bonne catégorisation d'un item. Nous l'avions etiquetté en but et je me demandais si ce n'était pas plutôt un moyen. Les deux autres personnes du groupe n'ont pas été convaincus et ont suggéré de poser la question à l'animateur. Comme il était occupé et que ce n'était pas siii important, nous sommes passés à la suite.
Plus tard, il est passé et a dit : "C'est bien ce que vous avez fait mais ça, ça serait plutot un moyen". L'un d'entre eux m'a félicité :
J'ai trop longtemps mis à jour des métriques à la main pour en avoir une image positive. Ces derniers temps, je me suis pourtant surprise à en apprécier quelques unes. Je vais vous raconter comment certaines ont réussi à trouver (un peu) grâce à mes yeux, en particulier le burn down chart. Mais avant d'y venir, faisons un tour d'horizon sur quelques défauts des métriques.
La métrique peut être tout à fait pertinente au départ, et dans les faits refleter quelque chose de complètement faux. Nous considérons par exemple qu'une MEP réussie n'a pas de rollback et n'a pas eu d'incidents pendant son déroulement.
"Si une réunion ne vous apporte plus de valeur et que vous n'y apportez rien non plus, vous devriez avoir la possibilité de simplement sortir, avec un signe convenu par exemple." (Entendu aux XPDays 2009).
Comme beaucoup, j'ai participé à des réunions "inutiles" où je faisais acte de présence. C'est moins fréquent en environnement agile, avec le ROTI (un note de 1 à 5 de la réunion) qui permet de donner un indice sur la valeur apportée. Autant dans le principe, une réunion peut être utile, sur place sa valeur peut dégringoler : les conversations peuvent tourner en rond, le sujet a dévié et ne concerne plus que quelques personnes (les chefs), etc.
Avez-vous déjà remarqué en revenant dans une pièce, que l'air ne sentait pas si bon? Vous y étiez pourtant depuis des heures et n'aviez rien remarqué. Vous étiez occupés. C'est après être sorti de la salle pour prendre l'air que cela vous saute au nez. La première fois que j'ai entendu parler de binômage, j'ai réellement cru que c'était un mythe. Quelque chose dont on parle, mais qui n'existe pas dans la vraie vie. D'ailleurs, on constate que si de nombreuses pratiques agiles arrivent à prendre dans les entreprises, le pair programming a plus de mal à prendre sa place.
Quel gâchis de mettre plusieurs personnes sur un travail !!!! On m'a dit "sisi, ça fait gagner du temps". Ben non. Il faut expliquer à l'autre son point de vue, se mettre d'accord, on met du temps avant de commencer à produire...
Axel et moi organiserons justement à l'Agile Conférence un atelier sur la valeur ajoutée du collectif par rapport à l'individuel. En théorie, on accepte facilement cette idée, mais dans la pratique nous sommes beaucoup plus frileux. L'atelier va, on l'espère, vous prouver le contraire. C'est une nouvelle toute fraiche, je viens juste voir la sélection sur le site, nous sommes très contents !
Weinberg évoque dans dans Quality Software Management une idée reçue implicite au sujet des métriques : pouvoir mesurer les choses nous donne l'impression de pouvoir les maitriser.
A quoi servent les métriques?
Au niveau du management, les métriques permettent de prendre des décisions. Elles donnent aussi aux personnes du terrain une vision plus macro, plus large des évènements.