Developers' notebook

Les tickets, "c'est comme"

Florence CHABANOIS — Sun, 18 Dec 2011 02:02:00 +0100

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.

Faire un ticket pour les vrais demandes et juste un mail (plus rapide) pour les petites, c'est comme mettre les vrais lettres dans la boite aux lettres et les petites au dessus de la boite.

On peut aussi demander au facteur que l'on croise de poster notre lettre quand il retournera au bureau. Peut être qu'il le fera, peut-être qu'il n'y pensera plus, peut-être qu'il n'a pas envie, peut-être que la lettre va glisser à côté.

C'est une question de flux et de standards : en sortir, c'est augmenter les chances d'échecs. Le demandeur est pressé, il a voulu économiser 2 minutes. Ok.

Au mieux, il fera perdre cinq minutes au développeur qui devra créer le ticket : qu'il le lise une fois, s'énerve, en parle à coté (-> 3mn) et le fasse (2mn).
Le dev pourra aussi renvoyer à l'envoyeur (2mn de rédaction de mail), l'expéditeur sera vexé, s'enervera, en parlera à coté et créera le ticket (5mn de plus de perdues).
Dernier scénario, le pire. Le dev a vu la demande et étant occupé, n'a pas traité la demande tout de suite. Elle sera zappée. Au final, le demandeur aura juste gaspillé les cinq minutes passés à faire sa demande en promo. Trois mois après, le MOA retombe sur le petit truc toujours pas fait et renvoie un mail. Et là c'est parti pour quelques échanges houleux qui prendront bien une heure en tout.

(variante) ''Penser qu'une demande mineure ne mérite pas la peine de créer un ticket, c'est comme penser que les petits déchets ne méritent pas qu'on se déplace jusque la corbeille, qu'on peut juste les laisser tomber par terre.

Cela dépend de l'objectif : si l'on souhaite que ce soit ramassé, c'est la peine. Implicitement, c'est aussi considérer que notre temps est moins important que celui d'un autre (qui sera obligé de tout ramasser derrière) alors qu'il y a un système prévu pour ces besoins. Cf le "c'est comme" précédent.

Par contre, si l'objectif est juste de s'en débarrasser, bingo. C'est peut être pour cela que nos trottoirs sont truffés de chewing gums.

Les standards peuvent sembler compliqués, peu propices à la créativité et injustes sur le très court terme. Mais ils sont là pour privilégier le bon fonctionnement global du système sur des raccourcis de confort individuels. Idéalement, s'ils sont construits ensemble, ils sont mieux compris, mieux appliqués et plus évolutifs.

(Crédit Photo : consoglobe.com)

Manager et/ou développer ?

Florence CHABANOIS — Tue, 25 Oct 2011 14:39:00 +0200

Le développeur d'une autre équipe m'a dit un jour : "Ah non, le scrum master n'est pas censé coder." Il avait l'air vraiment choqué. Je lui ai demandé pourquoi, et il m'a répondu que cela enlèverait de la responsabilité aux équipes. Que c'était intrusif' ? Oui.

Etonnée, je me suis tourné vers les personnes de mon équipe pour avoir leur avis. Elles ont répondu : "Bah... toi, tu veux coder ?"

Paradoxalement, quelques mois auparavant, j'évoquais lors d'un one on one [1] la difficulté que j'avais à récolter du feedback au quotidien. Pour le développeur, je (le scrumMaster) devais être totalement interchangeable avec un autre développeur et pouvoir faire une story de A à Z sans problème. Pour lui, un scrum master code quasiment aussi facilement et régulièrement qu'un développeur.

Le manager architecte

A mes yeux, si un scrumMaster code à plein temps, il peut devenir trop impliqué dans les choix techniques. Cela risque de devenir super important pour lui que l'on prenne SA solution à ce problème. Si le scrumMaster est en plus supérieur hiérarchiquement, ses idées peuvent passer plus facilement. L'équipe prendra-t-elle la peine de contester ?

Si une idée provenant du manager est forcément acceptée, il vaut mieux qu'il ne code pas pour laisser l'équipe se construire. Il faut du débat à mon sens, sinon il n'y a plus de scrumMaster mais un architecte qui commande officieusement. Ce serait dommage en cherchant à se rapprocher des équipes d'aller à l'encontre de la promotion de l'équipe.

Au delà de la perte de recul, un scrum master qui code beaucoup a moins de temps pour les tâches de base de scrum mastering : la facilitation, la construction d'équipe, l'agilisation, la veille... Devenir aussi bon qu'un développeur "normal" me parait être un objectif inatteignable en développant à mi-temps.

Le développement comme zone de confort

Dans cet extrait de Slack[2], Tom DeMarco évoque les raisons pour lesquelles un manager a temps de mal à quitter le terrain.

Pourquoi un manager va compenser un manque de ressources en mettant la main à la pâte ?

Dans un environnement suffisamment sur-stressé, manager n'est pas un choix sûr. Seul le véritable travail -le travail bas-niveau, comme construire le produit- te protège. Donc, si vous vous mettez à manager même un peu, ce sera une activité à mi-temps. Le reste du temps, vous ferez du produit, vous ramènez de l'argent. Faire rentrer du cash est une option sûre; Ainsi, le temps passé à manager ne sera pas retenu contre vous, tant qu'il reste minimal. (...)

Nous nous assignons aussi du travail d'opérationnel pour fuir le challenge. Oui, je sais, nous aimons tous un bon défi, mais cela ne signifie pas que nous ne nous dégonflons parfois et ne cherchons pas un échappatoire. Les challenges du management sont décourageants : ils nous mènent vers un monde effroyablement intangible de relationnel, motivation, formation sociétale, conflit et résolution de conflits.

Dans mon cas, j'ai été promu à un poste de management juste après un poste technique où il n'y avait rien d'intangible. J'étais un architecte système juste avant ma promotion. Le monde du système est délicieusement noir ou blanc : une solution fonctionne, ou pas. (...)

Le management est tout en nuance. Pourquoi diable Maria est-elle si susceptible ? Qu'est ce que c'est que cette tension entre Armand et Elwood ? Danny cherche-t-il ailleurs, et que ferons-nous si c'est le cas ? La date de livraison est-elle équilibrée entre difficulté et faisabilité, ou tout le monde profite-t-il de ma naïveté ? Ai-je employé le bon ton lors de mon briefing ? (...)

Pendant que j'essayais encore de comprendre tout cela, un de mes architectes partit. J'ai pris sa place sans hésiter. Pff, quel soulagement. Non seulement j'étais manager, mais aussi capable de passer mes jours à accomplir du travail noir ou blanc. Cela semblait être le meilleur des mondes. C'était faux. Je fuyais juste les difficultés du management pour retourner à travail plus froid. C'était le soulagement de la fuite.

Je rejoins l'auteur sur ces points. Depuis que je suis ScrumMaster, je ne sais plus quoi dire au standup. J'accomplis très peu de choses au quotidien (de concret). Je n'ai plus ces petites victoires régulières à la résolution d'un bug ou au développement d'une fonctionnalité.

Le management est indispensable pour que tous les acteurs puissent travailler ensemble, mais il s'agit d'un travail de longue haleine, ingrat en plus. C'est peut être réellement pour avoir un peu de certitude que j'aime retourner coder avec l'équipe.

Les deux métiers ne sollicitent pas du tout les mêmes compétences. Chercher à les améliorer prend du temps. Choisir de coder revient à choisir de renoncer d'autant à la part manageriale et prendre le risque d'illustrer tristement le principe de Peter [5].

Un besoin de feedback

Techniquement, je n'ai pas le temps de développer, je change souvent de tâches et suis régulièrement interrompue. J'en suis à poser des réunions pour binômer par tranche d'une heure, de temps en temps. Sans elles, je verrai mon équipe quinze minutes par jour. Si je veux en savoir plus, je dois aller sur le terrain (go and see).

Sans jamais coder, je ne peux pas me rendre compte des obstacles rencontrés. C'est là que tout se passe. Au standup, ils sont rarement évoqués (quand c'est fini, on n'en parle plus...). Je ne peux pas proposer des idées naïves. Je ne peux pas challenger leurs habitudes. Je ne peux pas comprendre de mieux en mieux leur métier. Je ne peux pas dire que telle autre personne a justement le même besoin et a développé un outil. Je ne peux pas favoriser l'émergence de standards. Je n'aurais pas appris tel raccourci et n'aurait pas pu le remontrer à telle autre personne. Je n'aurais pas proposé de mauvaises idées. Je n'aurais pas proposé de bonnes idées. Je ne comprendrais pas leur quotidien. Je ne serais pas vraiment un membre de l'équipe et peut-être qu'ils ne me parleraient pas aussi franchement.

J'ai besoin de voir ce qu'il se passe pour leur donner du feedback, et vice versa. Je ne veux pas être dans une tour d'ivoire.

La difficulté est de le faire assez souvent pour en tirer de la valeur et assez rarement pour garder le point de vue extérieur. Il faut aller dans l'eau pour voir comment son équipe vit, mais aussi en sortir pour repérer les mouvements inutiles et avoir la vue d'ensemble.

Et vous, qu'en pensez-vous ?

Ressources

[1] One on One (03) : entretien hebdomadaire ou bi-mensuel entre un manager et le collaborateur.
[2] Slack, de Tom DeMarco, p.84 (pardon pour la traduction approximative).
[3] Image de développeur : http://devzone.softathome.com/guide...
[4] Image d'architecte : http://www.asdf.org.in/developersme...
[5] Principe de Peter : http://fr.wikipedia.org/wiki/Princi...

Retour d'expérience sur le monitoring des logs

Florence CHABANOIS — Sun, 18 Sep 2011 14:16:00 +0200

Voici les premiers retours du script de monitoring des logs.

J'étais bien contente du développement super rapide en binôme de ce petit script. J'en avais un peu marre de devoir scanner tous les serveurs quand il y avait un problème et de me demander si telle erreur était "normale" ou pas. Je suis apparemment un piètre vecteur d'enthousiasme : mon mari assez geek était sceptique; mes pairs au boulot n'ont pas semblé plus émus que cela quand je leur en ai parlé. Je me suis vraiment demandé si c'était si peu réutilisable. Alors est ce que cela valait le coup ?

Il est aujourd'hui utilisé sur trois projets Java, avec des équipes et historiques différents : A, B, C. Le script a un peu évolué depuis : il permet de voir l'évolution du nombre d'erreurs dans hudson et contient des règles supplémentaires. Les développeurs reçoivent un mail quand un seuil d'erreurs est dépassé.

Ca fait bobo

Le seuil étant approximatif, les développeurs du projet 1 reçoivent plusieurs jours de suite un mail avec les erreurs. Le premier constat est que c'est chiant et que cela fait mal. On est obligés de voir encore et encore les mêmes erreurs certes connues mais vraiment bizarres. Moi, ça me donne envie chaque jour de retrousser mes manches et de leur faire la peau.

La moindre instabilité de plateforme est visible : un problème réseau tel jour ? Les logs du projet B le montre et les devéloppeurs sont prévenus. Les logs ne mentent pas et donne illico le nombre d'opérations qui n'a pas abouti sur tel problème.

Il a permis d'arbitrer

Nous avons été alerté par un internaute d'un bug le lendemain d'une MEP sur le projet B. Il était suffisamment grossier pour que l'on envisage le rollback. Mais quelle est la réalité ? Combien d'utilisateurs sont réellement impactés ? S'il y en a dix, on peut attendre le bugfix... Ce bug était loggué mais masquée derrière une erreur "connue" : impossible de distinguer les deux cas. En regardant d'un peu plus près, un nouveau message, spécifique à cette erreur, est apparu dans le rapport. On a eu la réponse exacte à notre question et avons pu prendre une décision, sans la fonder sur un simple ressenti.

Il a montré des problèmes avant qu'un utilisateur nous le signale

Sur le projet B, les logs ont révélés des bugs très particuliers, qui ne se déclenchaient qu'avec une saisie précise dans un workflow spécifique. Le PO a été épaté de voir que le développeur lui faisait recetter une story qu'il n'avait meme pas écrite, sur un bug si précis. Pour le coup, cela ne fonctionne que si les développeurs s'appuient sur le rapport de logs pour être proactifs. Le fait de les recevoir par mail facilite la tâche; d'avoir un historique faciliment accesible de faire le tri etre les erreurs connues et nouvelles.

Il m'a permis de travailler avec une autre équipe

En fait, c'est seulement quand je me suis assiste à coté d'un collègue pour lui montrer en live le projet que l'équipe C s'y est intéressé. C'est toujours mieux d'être accompagné que d'avoir une doc à lire. En deux minutes, on a lancé le script sur son site et les problèmes ont émergé. Verdict : plusieurs centaines d'erreur sur un jour précis. Le jour où il y avait eu un problème lors d'une MEP. Le développeur était surpris et content de voir en une seconde son impact.

Du coup, il a proposé des axes d'améliorations et a bossé sur le projet. Quelques jours après, il m'a montré ce qu'il avait fait et on essayé de résoudre un problème d'encoding ensemble. Mon premier binômage transverse, imaginez mon émotion Le script est beaucoup plus sympa maintenant.

Un jour, il m'a dit : "eh le script a révélé une erreur 500 qu'on avait pas vu !". Le projet B a eu la même alerte dernièrement. La todo liste a gagné une ligne depuis : "failer quand une erreur interdite apparait.

Verdict

J'étais convaincu que ce script me servirait mais n'avait pas envisagé qu'il serait utile sur autant d'axes différents. Mon seul regret est qu'on ne se soit pas lancé plus tôt

Etre alerté quand une nouvelle erreur squatte nos logs

Florence CHABANOIS — Tue, 26 Jul 2011 23:04:00 +0200

Nous avons des releases de JSP assez fréquentes. Elles n'ont pas d'impact la plupart du temps. Une fois pourtant, on nous signale qu'un candidat n'arrive pas à déposer un fichier. Les logs révèlent que ce n'est pas la première fois mais impossible de savoir à quand cela remonte. En mettant le nez dedans, on se rend compte en plus qu'il y a des deadlocks en série depuis cinq jours, la dernière MEP web. Arf.

Ok, dans un monde de rêve, une erreur dans les logs devrait être un évènement grave, qui mobiliserait toute l'équipe. Dans la réalité, les logs parfaites sont rares et les erreurs "connues" sont monnaie courante.

[05/07/2011 03:41:32.196-http-a-8080-7$21292131] Unable to create account for candidat with email=bonjourMail@joujou.com

C'est ainsi qu'est né le script de monitoring d'erreurs distinctes :

Cette version se contente de compter le nombre d'erreurs dans un fichier de logs.

Comme vous pouvez le voir, les informations de contexte comme les mails et ids, très pratiques pour le débogguage, ont été aplaties afin de pouvoir s'en affranchir dans le comptage des erreurs. En lançant le script sur les logs d'un autre projet, j'ai dû ajouter les abstractions des dates et documents.

Le script a tourné quelques jours sur Hudson pour avoir une idée du seuil d'erreurs. Voici un exemple d'utilisation :

Ce n'est pas parfait mais la boucle de feedback est déjà plus courte. Il y a probablement un peu de tuning à faire en fonction des projets. La prochaine étape serait d'avoir une liste des exceptions connues, que l'on pourrait réduire au fil de l'eau.

Bruno m'a aussi suggéré de le grapher dans Hudson/Jenkins, ce qui effectivement nous épargne d'avoir à cliquer sur la console de chaque job. J'essaierai avec Plot.

Sources + tests ShUnit2.

Les mille pourquoi

Florence CHABANOIS — Thu, 07 Jul 2011 23:23:00 +0200

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é.

Je raconte ma vie pro

Je ne glisse pas toujours sur les problèmes. Nous avons eu des problèmes d'alertes emails et avons organisé une réunion pour faire une analyse de causes profondes avec l'exploitation, le help desk et les développeurs. Les solutions possibles étaient plus ou moins coûteuses. L'exploitation était déjà sous l'eau. L'assemblée décide que par rapport aux actualités, cela ne vaut pas le coup de traiter ce problème. Il a un impact très fort mais la prochaine fois, on le reconnaitra plus vite, et après tout il n'est arrivé qu'une fois en deux ans.

Dernièrement, nous avons eu un autre problème en production où la home page ne fonctionnait plus. J'étais en réunion toute la journée, le temps que je revienne, le service était rétabli (heureusement :p). Je ne comprenais pas en quoi la cause identifiée pouvait avoir un impact pareil et c'était difficile d'avoir une explication claire. Quand on résout un problème, on est juste content que ce soit réglé et de pouvoir de nouveau vaquer à nos occupations. Surtout quand ça fait deux semaines que les perturbations s'accumulent. L'équipe est déjà usée, poser des questions c'est vraiment l'emm*rder. J'ai eu du mal à avoir une explication claire car il manquait des infos. Le sujet a été évoqué avec quelques opérations à la cafétaria et pour moi ce problème n'aurait pas du se produire dans la mesure où Hudson compile les pages et le build échoue autrement. Les opés n'avaient de toute façon pas connaissance de ce job. C'était bizarre quoi mais bon, c'était réglé et j'avais moi aussi d'avancer sur autre chose.

Un mois plus tard, même problème. Site cassé. Parce que c'était la deuxième fois, big réunion entre l'exploitation et le développement pour éviter que le problème ne se reproduise. Une des causes était une erreur de manipulation. On ne s'en est pas aperçu parce que le développeur front concerné n'était pas en destinataire du job hudson et la modification est partie trop vite en production. Pour le coup, là, je me s'en suis voulue de ne pas m'être accrochée la fois précédente. Je ne vois pas de bonne raison de ne pas l'avoir fait, cela aurait évité la deuxième apparition.

A la poursuite (ou pas) des problèmes

Poser plus de deux questions sur un incident résolu (temporairement) est vécu comme un emmerdement maximal de la part de celui qui cherche à comprendre. C'est comme si on en posait mille. Encore plus quand plusieurs services sont impliqués. Cela tourne assez vite en interrogatoire, même sans le vouloir. Potentiellement très énervant. Procéder à l'exercice des X pourquoi est bien plus facile lors d'une rétrospective.

Pour l'équipe, c'est un véritable dilemme de s'attarder encore plus sur un incident résolu (= continuer de souffrir pour un avenir meilleur) ou de continuer le courant (= se faire plaisir tout de suite). Il n'y a pas de fierté à montrer les problèmes("rha fait chier lui"), personne ne nous remercie d'ailleurs pour ce genre de choses, presqu'au contraire. C'est démoralisant de ne pas pouvoir juste se réjouir d'avoir résolu l'incident.

La gestion des problèmes dans ITIL ou l'établissement d'un diagramme de Pareto dans le lean permet de focaliser l'effort sur la résolution la plus rentable : les incidents les plus fréquents. La fréquence n'est pas tout car un même problème peut avoir des causes très diverses à chaque apparition. Il peut aussi être pertinent de travailler sur la cause la plus fréquente, mais cela demande déjà une analyse plus aboutie de chaque incident. Ce temps d'analyse représente moins de temps de développement.

Est ce qu'un incident grave mais qui n'arrive qu'une fois mérite plus la mise en place de solutions durables ? Après tout, c'est résolu (pour le moment) et il y a tellement d'autres chats à fouetter.

Pour moi, oui. Un problème à très fort impact doit subir au moins la même analyse et je continerai d'insister en ce sens. C'est compliqué à défendre, mais possible en mesurant les impacts économiques. C'est toujours du temps de développement en moins. Il n'y a finalement pas besoin de monter de dossier pour défendre ce qui nous importe. D'autres fois, je privilégierai le courant, il n'y a pas de mode opératoire magique qui permette de prendre la bonne décision à chaque fois.

Agile France 2011 : Star Wars et Lean

Florence CHABANOIS — Fri, 01 Jul 2011 23:29:00 +0200

Comme chaque année, la conférence Agile France a rassemblé plusieurs centaines de personnes au Chalet de la Porte Jaune pour des conférences agiles à gogo. Bizarrement, le tout premier séminaire Java français avait lieu en même temps... Très bizarre de la part de Zenika d'ailleurs, pourtant sponsor il y a deux ans de la conf agile. D'autant plus que l'organisation d'Agile France est constitué de bénévoles et les speakers non plus ne sont pas payés.

Plus de retrouvailles et de rencontres que de conférences pour moi, mais quelques unes ont été particulièrement sympathiques. Je vous propose un premier billet sur StarWars et le Lean dans l'informatique.

En quoi Star Wars peut aider votre dynamique d'équipe

Bruno Sbille, en showman habituel, réussi l'exploit d'illustrer des styles de coaching en se basant sur Star Wars. Oui, le film en six fois 90mn où des garçons en jupes jouent avec des épées magiques (j'ai envie de me faire des amis avec ce billet :-D).

Il a fait une comparaison qui m'a bien fait rigoler : l'équipe correspond aux personnes qui coupent les branches dans la fôret pour se frayer un chemin vers la destination, à coups de hâches; le leader est celui qui monte sur un arbre pour vérifier qu'on va dans la bonne direction. Quand ce dernier signale qu'on se trompe de voie, on lui répond : "ouais mais t'as vu comme on avance bien ".

Super séance avec des extraits pour illustrer les différentes écoles :

Dark Vador pratique un management par le blâme. Si tu ne m'écoutes pas, je te remplace (et te tue avant). L'équipe n'a pas le droit à l'erreur. Le manager recherche un coupable plutôt que des solutions. Toute initiative représente une menace.
Avec un style directif, l'oncle (?) de Luke donne des consignes courtes au jeune homme, au sujet de la préparation de R2D2 quand ils viennent de l'acheter. Il a un ton ferme et lui reproche de poser des questions. Il ne le laisse pas parler. Il dit ce qu'il faut faire avec beaucoup de détails sans donner le pourquoi, et en faisant fi du contexte. Il y a peu de place à l'innovation.
Quand Obiwan va voir Yoda au sujet de la planête qu'il n'arrive pas à retrouver, Yoda ne répond pas. Il pousse Obiwan à poser le problème et consulte les jeunes jedis pour qu'ils trouvent la réponse. Dans la vraie vie, on ne laisse pas toujours l'occasion aux juniors d'apporter des réponses. Il s'agit du management par considération personnelle, en fonction du goût de chacun.
Enfin, le général des rebelles donne l'objectif : atteindre l'étoile noire, sans être précis sur le comment. Le but est donné avec un cadre (il faut passer par tel petit passage pour atteindre le coeur), mais l'équipe décide des moyens. C'est du management par objectif. Sur un projet agile, ce serait le Product Owner qui donnerait l'objectif et le ScrumMaster le cadre.

Aucun ne constitue LA bonne réponse. Ces modes ont leurs avantages et leurs inconvénients : certaines personnes ne supportent pas l'autonomie, aiment l'autorité sans avoir à réfléchir. D'autres étouffent complètement avec ce type de management. Le mode directif pose toute la responsabilité sur une personne, qui doit penser à tout mais être très pertinent dans une situation d'urgence par exemple. Il est très accepté sur un domaine que l'on ne maitrise pas ou qui nous importe peu. Les managements par objectif et par considération personnelle ne permettent pas de prise de décision définitive rapidement. En effet, un consensus est plus long à atteindre et la confiance ne s'acquiert pas rapidement.

Le mode adéquat dépend donc des personnes et du contexte. Si un manager a forcément une préférence sur un style, Bruno recommande de donner du feedback en tant que managé aussi pour aider l'ajustement. Une corde peut représenter la relation, et on peut la tirer des deux côtés.

Retour d'expérience Lean IT

Le duo de choc Régis Médina et Antoine Contal nous raconte une implémentation du lean dans une banque italienne.

Pour les orateurs, le lean est avant tout une stratégie d'entreprise, par l'excellence. Elle s'articule autour de trois axes :

satisfaire le client (ça m'a fait pensé à ITIL)
réduire les coûts
en développement les salariés par la résolution de problème

La toute première action consiste à bien cerner les attentes du clients. Il faut plusieurs feedback dessus avant d'identifier l'objectif.

Le management idéal selon Toyota (toyota way) consiste à

refuser le statut quo et se challenger. On rêve au delà des nuages, c'est loin, mais on a le courage d'y aller.
on essaie de faire un peu mieux à chaque fois ("Kaizen").
pratiquer le "go and see". Il s'agit de respect, en faisant l'effort de comprendre le point vue de l'autre sans forcément être d'accord.

Le premier problème était que la DSI n'arrivait pas à prendre tous les appels. En repérant l'appel le plus récurrent, on peut le sortir du flux et chercher une solution spéciale. En résolvant un cas d'appel, le nombre d'appels perdu a été divisé par six en trois mois.

Un autre besoin était que le niveau 3 réponde rapidement et bien, que le système fonctionne parfaitement. En suivant la piste du lean, on souhaite rendre l'équipe super forte, qu'elle comprenne ce qu'il se passe. Elle a ainsi tracé le cycle de vie d'un incident grâce à du management visuel (post-its, calendrier mural). Il y avait énormément d'attentes. Chacun faisait de son mieux mais ce n'était pas organisé. Un membre de l'équipe est allé plus loin, en procédent à un QRQC sur chaque incident pour trouver les causes. Au début, on y voyait rien puis il y a eu un flash. Le batch en cause est devenu super surveillé.

Pour conclure, l'outil lean n'est pas simple à mettre en oeuvre. Afficher les performances est un sujet sensible. Montrer les problèmes aussi, puis il faut prendre le temps de les résoudre. Cela peut révéler des problèmes plus profonds.

Feedback de l'équipe

Florence CHABANOIS — Wed, 01 Jun 2011 23:39:00 +0200

J'ai compris récemment pourquoi j'avais autant aimé mes toutes premières rétrospectives et moins celles d'un autre projet. Plus que l'amélioration continue même, c'est ce qui permet cette dernière d'être qui m'a plu : le feedback.

J'apprends ce qui a saoulé mes coéquipiers, ce qu'ils ont adoré. Que certains commencent à glisser tout doucement. Et vice versa, je peux mieux me lâcher à ce moment là, je sais que j'aurai cette espace. Parce que j'ai cette possibilité, je peux pleinement me consacrer à éteindre le feu quand il y a un problème.

Pendant mes premières, un étrange sentiment de confort m'entourait. Normal, on souffle un peu (nous sommes entre deux itérations) et nous sommes entre nous. Des conditions top pour réfléchir à du moyen/long terme. Du lien se crée. Pour cette raison, j'aime bien inviter des extérieurs quand ils ont été impliqués dans l'itération.

Feedback ?

Le feedback est une valeur XP. Nous nous attachons à réduire sa boucle avec les tests unitaires lancés en continu par exemple. Fail or pass fast. C'est pour leur feedback que j'aime autant les tests.

Le feedback est un besoin humain : quelque chose cloche en nous lorsqu'une pièce est lancée et qu'on ne l'entend pas retomber. Quand l'on s'exprime en public aussi, nous avons tendance à regarder notre manager ou un proche plutôt que les visages impassibles de l'audience. Nous avons besoin de signaux. Ils nous permettent de nous conforter dans notre voie ou de corriger le tir.

Le feedack est l'essence de l'apprentissage. Un enfant sait qu'il ne peut pas descendre d'un coup d'une chaise haute. Pas parce qu'on lui a dit, mais parce qu'il a déjà essayé et l'expérience a été douloureuse. Expérimenter, expérimenter, expérimenter.

Le feedback permet d'être plus "aware" en entreprise car il élargit notre champ d'informations. Plutôt qu'avoir un feedback annuel des membres de l'équipe, via l'entretien annuel, nous pratiquons les one-on-one hebdomadaires dans les équipes IT.

One on one

Un One-on-one (O3)dure 30 minutes. Pendant 10 minutes, le collaborateur s'exprime pendant que le manager écoute activement. Puis c'est au tour du manager de lui donner son feedback positif, neutre ou négatif. En dernier lieu, un certains nombre d'actions sont planifiées pour la fois suivante.

A l'ère des open spaces, les one on one constituent un bureau avec une porte ouverte. En mieux, car elle est dans les deux sens. C'est le moment d'encourager les comportements désirés.

Pour le manager, le O3 permet de ne pas passer à côté d'idées et de frustrations de ses équipiers. Il épargne pas mal de malentendus. C'est l'occasion aussi de construire des objectifs individuels et collectifs moyens termes.

Pour l'équipier, c'est le moment où il a les clefs pour tenter de changer sa condition, en commençant par l'exprimer. Il peut demander de l'aide, un avis extérieur, lever des alertes ou simplement poser des questions. Nous pouvons avoir plein d'idées, c'est souvent pendant les O3 que je les ai vu s'exprimer. Car on n'y pense pas autrement.

Dans les deux sens, il évite d'accumuler des "dossiers" sur des gens, de se construire une image négative petit à petit et surtout l'explosion inévitable qui va avec. Il permet de construire une relation de confiance entre le manager et le collaborateur, de mieux se connaître : nos contraintes, nos facteurs de motivation, nos attentes respectives. Ils donnent des lunettes différentes au manager e à l'équipier sur la situation.

Les O3 révèlent les problèmes quand ils sont encore petits. On peut fermer les yeux, mais bizarrement, les problèmes ne s'en vont pas. Ils pourrissent.

Dans ma pratique, j'aurais des difficultés si je devais me passer de ces entretiens réguliers. J'ai trop souvent eu l'effet Ouf.

Ouf, heureusement que j'ai eu un 03 sinon je ne l'aurai pas su. J'ai eu chaud.

Sans cela, on allait dans le mur. Pour éviter que cela soit trop lourd, le team member peut demander à sauter un 03 s'il n'en voit pas l'utilité.

Souvent, je me mets à espérer que d'autres équipes en dehors des dev aient ce genre de pratiques. Avec du feedback, nous sommes obligés de communiquer et ça aussi, c'est une denrée rare dans les services. Certes, les 03 prennent du temps, semblent ralentir. En réalité, ils nous évitent de courir dans la mauvaise direction. Si. Essayez une fois par mois déjà, pour voir. Expérimentez et voyez par vous même la valeur de ces feedbacks.

J'aurais pu appeler ce billet "Pour une généralisation des O3..."

Exécuter la même commande sur plusieurs serveurs

Florence CHABANOIS — Tue, 24 May 2011 22:05:00 +0200

Nous avons parfois besoin d'effectuer une même opération sur plusieurs serveurs. Les équipes exploitation connaissent bien cette problématique avec la multitude de frontaux à mettre à jour lors d'une mise en production.

Les développeurs aussi. Nous devons créer un répertoire sur les serveurs de recette et d'intégration; suite à un bogue, nous partons à la recherche d'informations dans les logs sur les cinq frontaux; nous avons besoin de comparer les logs de production avec ceux de recette, etc.

Il y a au moins trois possibilités à ce type de besoin : le faire à la main à la suite; utiliser clusterSSH; ou Gnome Connection Manager.

ClusterSSH permet d'exécuter une commande sur plusieurs machines en même temps, mais honnêtement, il y a mieux. Premièrement, le copier coller n'est pas possible. Deuxièmement, plus il y a de serveurs, plus les consoles sont petites. Avec cinq frontaux, on n'y voit plus rien.

Johan m'a fait découvrir Gnome Connection Manager, qui permet de configurer les serveurs une fois pour toutes. Le fichier de configuration est sous SVN.

Surtout, il permet d'exécuter des commandes sur des clusters de serveurs.

Il suffit d'appuyer sur [Entrée] pour envoyer la commande.

L'application s'installe très simplement avec Ubuntu, ce serait dommage de s'en priver. Personnellement, je ne peux plus m'en passer pour les commandes groupées.

Liens

GnomeConnectionManager : http://kuthulu.com/gcm/
ClusterSSH : http://sourceforge.net/projects/clusterssh/
Multitail : http://www.vanheusden.com/multitail/

[Edit du 24 Mai, suite aux remarques de JP]

Puppet : http://www.puppetlabs.com/puppet/introduction
Chef : http://www.opscode.com/chef
CF Engine : http://www.cfengine.org

=> plus rien n'est manuel, tout est dans svn/git, tout est répétable. Dans ma boite, nous avons eu des surprises en production avec puppet., suite à des modifications "automatiques".

Agilité et carrière

Florence CHABANOIS — Thu, 14 Apr 2011 00:33:00 +0200

Au scrum day, j'ai assisté à deux sessions sur le management dans l'agilité : "De scrum master à coach agile" de Véronique Messager et "Pratiques et difficultés pour les managers d'équipes agiles", une table ronde animée par Damien Thouvenin. Si chaque membre de l'équipe peut déjà tout faire et a déjà des responsabilités, quelles progressions de carrière sont possibles ? Devenir scrum master, devenir indépendant ? Comment rétribuer individuellement un succès collectif ? Comment justifier des écarts de salaire quand nous sommes "tous" des développeurs agiles ? Ce billet compile quelques reflexions à ce sujet.

Rétribution salariale

Lors de l'entretien annuel, les trois axes suivants sont souvent évoqués :

la progression des compétences individuelles;
la contribution au succès de l'entreprise;
la négociation salariale [1].

Le dernier élément est souvent en fonction des deux premiers. Parfois, l'augmentation est liée à l'effort fourni (elle reste jusque 22h tous les jours), d'autres fois à la compétence (il fait le travail en 2h au lieu de 5h par d'autres [2]), parfois encore à la compétence supplémentaire acquise (elle met 1h là où il lui fallait 2h). Il y a évidemment d'autres facteurs : le niveau d'indispensabilité, la visibilité de la personne, etc.

Gérer une augmentation dans un contexte traditionnel est donc déjà compliqué.

Salaire de l'individu / collectif ?

Dans un contexte agile, l'ensemble de l'équipe tourne à peu près au même rythme soutenable. L'effort est donc le même ? Si on fournit le même travail, comment se fait-il que l'on ne soit pas payé pareil ? Les années d'expérience l'explique mais peuvent être incomprises.

L'ensemble de l'équipe travaille ensemble, ce n'est plus simplement telle personne qui s'occupe de telle tâche. Non seulement l'équipe tourne dessus, mais en plus elle binôme. Il n'est pas évident de distinguer les compétences des uns et des autres. D'ailleurs le faut-il ? Encourager les succès individuels (par des augmentations salariales) va à l'encontre de l'idéal de partage et de monter en compétences ensemble. Cette démarche n'incite pas non plus à la transparence et à montrer les problèmes.

Pour autant, donner la même augmentation à tout le monde ne me parait pas une bonne idée non plus. Cette égalité peu équitable peut démotiver les éléments moteurs, voire les faire partir. S'il s'agit d'un pourcentage, les mieux payés creusent de plus en plus l'écart; si c'est un montant fixe, les mieux payés ont l'impression d'avoir une baisse. Une piste serait d'évaluer les "efforts" à travers l'implication, les "compétences" par la pro-activité et la levée de problèmes.

Un intervenant à la table ronde disait consulter d'autres directeurs afin d'avoir des avis extérieurs. Le fait d'augmenter le nombre de regards donnent un effet miroir et oblige à défendre les cas. Un autre se donnait comme critère de ne pas avoir honte s'il fallait les publier. Un dernier disait au contraire, qu'il aurait honte de les rendre publique car il a parfois fallu "retenir" des personnes.

Le dernier axe est d'éviter ces questions en passant par des intermédiaires : la prestation. Si la SSII paie suffisamment ses salariés, on s'en sort bien sans avoir à gérer des problèmes d'équité et de motivation. Dans le cas contraire, c'est raté. Je pense à ce scrum master qui me disait que chaque année telle SSII sapait le moral des ses prestataires sans qu'il ne puisse rien y faire.

Augmentations

Dans le schéma classique, c'est en changeant d'entreprise ou de poste que l'on peut avoir un bond salarial. Dans l'agilité, il y a moins de paliers : développeur agile, développeur agile sénior, scrum master ou product owner, directeur de projets ? Petit panorama des pratiques :

toujours un peu au dessus du marché;
toujours le maximum du marché, quelque soit les résultats de l'entreprise, comme à Netflix [3]. Il y a ainsi peu de risques de départ qui reviendrait à une baisse de salaire. C'est également un facteur de motivation (c'est mieux qu'ailleurs). En pratique, il y a finalement peu d'augmentations et pas de variable, juste des "big salaries";
variable selon succès du projet en principe. Sans parler de la difficulté à définir le succès, la notion de "récompense" est dangereuse et créer des effets pervers;
en fonction de l'effort T / T-1, à l'effort Individu / groupe, au succès individu / groupe ?
une demande d'augmentation est soumise en proposition à tous les salariés de l'entreprise. Il n'y a pas d'entretien annuel;
chaque salarié décide de son propre salaire sous condition de la rendre publique [4] . Cela limite les injustices car vis à vis des autres, un salaire élevé pour soi limite le salaire d'un autre. Personnellement, j'ai un peu de mal à y voir un système qui peut marcher partout, à moins que les salariés soient aussi actionnaires. Le droit de décider de quelque chose d'aussi déterminant s'accompagne d'un risque à prendre. On a son mot à dire quand on est engagés, comme le cochon;
même idée mais l'entreprise est une coopérative ou SCOP. Motion twin, éditeur des jeux Labrute.fr et Hordes.fr ont adopté ce fonctionnement [5].
dernière variante : les salariés ont connaissance du budget et doivent se le répartir entre eux.

Parcours professionnel

Le métier de développeur est souvent vu comme le premier jalon d'une carrière, pas une fin. "Je ne vais pas rester développeur toute ma vie" est une phrase assez courante. Ce métier n'est pas valorisé comme aux Etats-Unis par exemple. La majorité des jeunes diplômés ne pensent qu'à devenir chef de projet. Dans un environnement agile, le parcours professionnel est plus flou, il n'est pas tout tracé. Cela peut faire un peu peur, on ne sait pas où on va.

Quand un désir de changement se manifeste, il peut s'opérer au sein de l'équipe sans qu'il n'y ait à passer par les ressources humaines. Chacun peut spontanément décider de se concentrer sur telle technologie, de faire du suivi de projet, du scrum mastering, de gouter à tout. Il peut même changer d'avis et réessayer autre chose. Ce côté officieux est souple mais peut manquer de concret s'il ne s'accompagne pas d'un titre\ [6]. C'est vrai, l'évolution est plutôt horizontale.

Par contre, il peut y avoir un manque de reconnaissance en dehors de l'équipe agile. Le développeur agile reste un "simple" développeur aux yeux du monde, alors qu'il peut faire de l'architecture, de l'expertise, du fonctionnel, de la planification, de la coordination. Toutes ces compétences peuvent être valorisées sur le CV mais le monde extérieur a souvent besoin d'avoir un seul interlocuteur. Dans la mesure où les informations sont bien relayées à toute l'équipe, je ne pense pas que ce soit un problème. Le tout étant de ne pas encourager ce mode là et de laisser les devs agiles répondre à l'extérieur le plus souvent possible. La communication au sein de l'équipe est alors déterminante pour assurer un suivi.

Si on veut clairement changer de poste, la voie suivante est scrum master ou product owner. Après, c'est peut-être directeur ? On peut avoir le sentiment de plafonner assez vite. Il y a aussi des postes de coach, d'indépendant. Et quand l'agilité sera mainstream ? A ce moment là, je continuerai de me dire qu'au moins, je m'éclate dans mon métier tout en apportant des petites pierres à l'édifice.

Le contexte agile est plutôt favorable à l'enrichissement individuel. L'équipe a des compétences variées et pointues, le tout est de donner à chacun des occasions de se dépasser.

Ressources

[1] http://www.estherderby.com/weblog/l...
[2] http://www.estherderby.com/weblog/2...
[3] http://www.slideshare.net/reed2001/...
[4] http://www.amazon.com/Maverick-Succ...
[5] http://www.motion-twin.com/blog/ent...
[6] http://www.inc.com/magazine/2011040...
Vidéos du scrumday
et des discussions sur la liste xp-france ("Evaluation et rémunération", etc)

Donner des cadres

Florence CHABANOIS — Wed, 16 Mar 2011 09:23:00 +0100

Quand nous avons un problème, nous cherchons une action qui permettra de le résoudre. Passer par un processus de Plan Do Act Check (PDCA) permet de vérifier que ladite solution est efficace.

Plan : recherche des causes racines possibles et planification
Do : mettre en œuvre
Check : vérifier que l'action résoud bien le problème
Act : Agir, ajuster, réagir (si on a testé à l'étape Do, on déploie lors de la phase Act). En cas d'échec, le processus continue sur le test d'une autre solution. Autrement, la pratique devient un standard et le processus peut se poursuivre sur la résolution d'un autre problème.

Le fait d'en faire un standard a beaucoup d'avantages mais aussi des limites. De temps en temps, une solution convient à un instant T, avec un certain contexte projet (client/équipe) et ne plus du tout être valide quelques mois après. Sans parler du fait qu'il faut du courage pour bousculer ce standard. Résultat : l'équipe se retrouve à maintenir une habitude qui ne lui apporte plus de valeur mais que l'on ne pense pas / ose pas contester. Nous nous retrouvons paradoxalement dans une situation anti-agile. Rajouter des standards se fait plus facilement qu'en supprimer.

Ces derniers temps, j'essaie donc de donner plus d'espace d'expression aux gens. Le signaler explicitement aux personnes me permet de dire "checked" sur la case "donner du lead à la team" mais n'incite pas à le faire pour autant. Après tout, je dis peut être cela juste comme cela, sans réellement le penser.

Pourquoi des espaces d'expression

Les raisons à cela sont multiples :

nous avons pas tous autant de facilité à prendre la parole spontanément, et encore plus en groupe;
la présence d'extravertis dans le groupe peut laisser penser que ce n'est pas la peine;
on peut simplement ne pas y penser, en étant pris par toutes nos autres activités;
l'absence d'espace réservé facilite la perte d'information et de suivi (= l'oubli);
on peut considérer que ce n'est pas notre place, si ce n'est pas explicitement demandé. Culturellement, on nous apprend plus à rentrer dans des cases qu'à secouer les systèmes établis;
avoir un espace dédié favorise la productivité d'idées

Grossièrement, le principe est de laisser une place aux introvertis, de leur donner le micro. Ce type de fonctionnement peut sembler être une perte de temps pour les extravertis, qui n'ont pas de problème pour exprimer leur point de vue à chaud et objecter. Ils le font au quotidien.

Pour autant, leur absence à ces réunions serait dommage car on ne profite pas d'eux lors du brainstorming et vice versa. Il n'y a pas la possibilité de se nourrir mutuellement, de construire les idées les unes sur les autres.

L'autre axe est de rentabiliser la réunion au maximum : les introvertis peuvent se préparer calmement à l'avance et la réunion elle-même est timeboxé (une heure grand maximum) avec un animateur gardien du temps et de l'équité de paroles.

Quelques exemples

Expérimentations au standup

Le principe de base est que tout le monde peut proposer des idées et expérimentations au standup meeting.

Elles sont applicables immédiatement sauf si le coût est important (ce qui inclut impact sur quelqu'un d'autre). Par contre, il y a une date d'expiration, où l'équipe s'exprimera pour la maintenir, l'améliorer ou la supprimer. Je n'ai pas poussé le vice jusqu'à créer un test JUnit exprès qui échoue à la date mais j'aurais pu. L'expérience en cours est simplement affichée sur le mur avec la date à coté, à la vue de tous.

Avec ce système, j'ai appris que le standup était trop long et le libellé des post-its pas assez explicites. Sans cela, certaines personnes auraient pu simplement continuer à le subir et petit à petit faire juste acte de présence.

Si le coût est important, l'équipe en discute. Une timebox de quelques heures peut être décidée pour effectuer un prototype.

Veille technique

Avoir un créneau spécial pour la veille technique permet de faire des prototypes. Il y a ensuite une réunion d'une heure pour échanger sur les découvertes et questionements de chacun.

Je pense qu'au moins de temps en temps, ce créneau permet de sortir la tête de l'eau, de redynamiser une équipe, d'éveiller des vocations, de créer des spécialistes. Peut être que des personnes qui à la base n'en faisaient pas s'y mettraient alors elles aussi.

Le revers est que l'équipe peut croire que s'il n'y a pas de cadre pour, il n'y a pas de raison d'en faire en dehors. Il faut prendre les gens par la main.

Idées fonctionnelles

Tout le monde peut en théorie suggérer des idées d'améliorations au marketing sur le produit. Certains le font entre deux couloirs, d'autres de façon plus formelles. Mais les suggestions n'étant pas toujours (jamais) formalisées, elles sont perdues avec le temps. Donner un cadre permet d'assurer un minimum de suivi et d'avoir des échanges plus riches. Il accentue aussi l'objectif commun de l'équipe technique et l'équipe fonctionnelle : avoir un produit qui déchire.

Rétrospectives

Les rétrospectives bien sûr constituent un cadre officiel pour l'amélioration continue en équipe.

Les One on One

Il s'agit d'entretiens individuelles sur une base plus fréquente qu'à l'année, typiquement toutes les quinzaines. Les One on One (O3) donne la parole au salarié. Un format peut être qu'il s'exprime pendant 10mn sur ses obstacles, ses succès, ses objectifs; ensuite le manager dit ce qu'il en pense et donne du feedback (positif ou négatif); restent 10mn pour définir des actions pour la prochaine fois (une seule est déjà bien si elle est accomplie).

Depuis que j'en fais, en tant que manager et managé, je vois les problèmes plus tôt et les traite plus vite. Cela revient à mettre des lunettes quand on est myope : je ne suis pas à l'abri de tomber mais j'avance avec plus d'assurance. J'ai une meilleur connaissance du contexte. Tous ces cadres permettent finalement d'avoir plus de feedback et de mieux s'adapter.

Insights

De manière générale, il me parait important de bien exposer sa propre vulnérabilité aux erreurs , afin que l'ordre établi ne paraisse pas siii difficile à bouger. L'autre point est que les désaccords sont une bonne chose, il n'y a pas de raison d'en avoir peur. Elles permettent de mieux décider et de progresser.

Néanmoins, je me rends compte que les cadres ne sont pas adaptés à tout le monde. De plus, une organisation trop officielle peut laisser croire que le reste du temps doit être exclusivement réservé au développement pur, sans tâches transverses ou d'amélioration continue. Un cadre peut être perçu comme de la rigueur. Ironiquement, il couperait alors toute initiative et étoufferait certaines personnes. La responsabilité n'appartient pas au manager de décider ce qui vaut la peine d'être dit et qui mérite un cadre. C'est exactement le contraire de ce que je souhaite. Et puis, cela fait beaucoup de réunions.

Au final, il n'y a pas de standard miracle à appliquer tout le temps, heureusement ! L'humain n'est pas modélisable.

ROI des tests automatiques

Florence CHABANOIS — Sat, 19 Feb 2011 01:09:00 +0100

L'industrie du logiciel est encore loin d'avoir systématiquement des tests automatiques. Le coût est tout de suite visible et rédhibitoire, contrairement à son gain. Personnellement, j'en fais dans mon développement car il me donne de la confiance et m'aide à construire le produit. Pourtant, certaines personnes restent hermétiques à mon enthousiasme. Entre deux réponses à un appel d'offres, un client lambda privilégiera la plus "compétitive" (= la moins chère), quitte à en payer le prix plus tard.

Les clients les plus sensibles à la cause se demandent jusqu'où il faut aller. Est-ce qu'il faut absolument tout tester? Est-ce que la valeur apportée vaut son coût ? Il y a un pallier où la qualité supplémentaire n'a plus de ROI. Je peux fabriquer des biscuits parfaitement rectangulaires mais il n'est pas dit que ma fille de dix ans apprécie le geste outre mesure. Elle ne s'en rendra probablement même pas compte. Je ne sais pas non plus apprécier un couteau damassé 32 couches avec un manche imputrescible à 350 €. Il n'existe pas de ressources illimitées, qu'il s'agisse de temps ou d'argent. Nous ne souhaitons pas que nos produits soient parfaits à tous les niveaux, car cela couterait trop cher. Alors, où s'arrêter ?

Quelques pistes pour aider

Définir l'objectif

Avant de décider si l'on est prêt à y mettre le coût, nous pouvons déjà nous recentrer sur l'objectif. On oublie les autres offres temporairement, on évite de se dire qu'on peut juste avoir moins cher ailleurs.

Alors, qu'est ce qu'on veut ?

Un produit qui fonctionne (presque) parfaitement ? Des délais tenus ? Un lancement plus tôt ? Un produit innovant ?

Les offres annexes nous détournent parfois de nos objectifs. Revenons au couteau de luxe : je n'ai pas l'habitude d'y mettre un budget de 300€. J'en ai plein d'autres dix fois moins chers qui remplissent mes besoins. C'est pour cette raison que le prix me juste parait exorbitant.

Paradoxalement, acheter un Monet 300€ me parait une bonne affaire.

Le couteau méga tranchant et résistant sera utilisé deux fois par jour pendant des années tandis que le tableau se fondra dans le décor de mon appartement au bout de quelques jours seulement. Finalement, j'ai peut être tort de ne pas vouloir y mettre le prix... Ne laissez pas les coûts relativement moindres de la concurrence flouter vos objectifs.

Rendre les coûts visibles

Les organisations ont souvent des mesures toutes faites, calculées automatiquement par des outils. Il y a beaucoup de travail souterrain non visibles qu'il faut rendre visible si on veut pouvoir le mesurer. Dans une de mes missions par exemple, le temps de déboguage effectué après le passage à la validation n'était pas réimputé au temps de développement de la fonctionnalité. On n'y pensait pas alors que ce coût invisible pouvait être très important en temps.

Mesurer les coûts annexes

Ensuite, il faut comparer des choses comparables. Avant de dire que les tests coutent trop chers, combien coutent actuellement l'absence de tests automatiques ?

Toute la difficulté est de rendre visible ces coûts cachés.

Il y a quelques temps, lors d'une formation sur les tests, il m'a été demandé :

combien coutent la mise en place des tests unitaires et fonctionnels ?
comment vendre ce surcout au client ?

Je n'avais pas de réponse toute faite. J'aurai pu apprendre des chiffres par coeur, citer des exemple de grandes entreprises qui y recouraient. J'ai dit que les tests permettaient de garantir que le produit fonctionnait, simplement. Que quand un problème était corrigé, il ne réapparaitrait plus jamais. Autant vous dire que personne ne semblait très convaincu par si peu de concret.

Alors j'ai cherché leur problème.

Au fil des jours qui passaient, le problème de qualité s'avérait flagrant. Il y avait énormément de gâchis. Le plus marquant était qu'il y avait en moyenne trois renvois de fonctionnalité par le service de recette aux équipes de développement. Autrement, le client imaginait ce coût pour un développement

temps de développement + livraison intégration + recette intégrale + recette spécifique 
+ livraison

Nous obtenons autre chose en mettant en lumière les coûts cachés :

temps de développement + livraison intégration + recette intégrale + recette spécifique 
  +  temps de renvoi (synchronisation recette/dev) 
     + synchronisation du développement pour se remettre dans le bain
     + temps de déboguage (x10 par rapport à un bug découvert pendant le développement, avec un facteur temps aggravant)
     + temps de résolution
     + livraison intégration + recette spécifique
  +  temps de renvoi (synchronisation recette/dev) 
     + synchronisation du développement pour se remettre dans le bain
     + temps de déboguage (x10 par rapport à un bug découvert pendant le développement, avec un facteur temps aggravant)
     + temps de résolution
     + livraison intégration + recette spécifique
  +  temps de renvoi (synchronisation recette/dev) 
     + synchronisation du développement pour se remettre dans le bain
     + temps de déboguage (x10 par rapport à un bug découvert pendant le développement, avec un facteur temps aggravant)
     + temps de résolution
     + livraison intégration + recette spécifique
+ livraison

La recette intégrale n'est effectuée que la toute première fois car le time to market serait beaucoup trop long s'il fallait tout recommencer.

C'est bien à la deuxième formule que le client doit comparer les coûts des tests que l'on souhaite mettre en place :

temps de développement + temps de tests + livraison intégration + recette intégrale manuelle + recette spécifique manuelle
+ livraison

Plusieurs visions du ROI

Une question de scope

Afin de commencer petit, j'avais proposé de prendre comme premier objectif d'atteindre deux allers retours maximum d'ici six mois. Le temps d'apprentissage peut être rapide mais couvrir la majorité du produit est un travail de longue haleine.

De façon générale, la question du coût est une question de scope. Avant de hurler au scandale en voyant les jours d'apprentissage nécessaires, il faut calculer le coût actuel sur un scope intégral : de la demande de fonctionnalité à sa maintenance en production.

Un manager m'a raconté une fois qu'une de ses équipes était assez peu portée sur les tests mais qu'au final, il ne voyait pas trop de différences en termes de nombre de bugs avec une autre, très XP et TDD. Je ne sais pas si c'était un coup de chance, si les bugs étaient aussi scrupuleusement reportés des deux côtés, s'il y avait moins d'utilisateurs, s'il aurait fallu comparer avec des mesures plus précises sur une plus longue durée ou si la valeur suffisante de qualité avait été atteinte.

Une question de calcul

Le sens le plus classique mais pas le plus simple quand l'on parle de qualité : il suffit de mesurer le cout et de le comparer au gain.

Dans Google Innovation Factory, vous pouvez voir l'évaluation cout/gain des tests unitaires et de l'intégration continue chez google.

Cout d'un test unitaire

écriture + maintenance

Economie

Evitement d'un bug (en production)
Développement plus rapide (refactoring)

Ecrire les tests avant de coder permet de réfléchir à la conception et aux cas limites. Cela permet aussi de s'assurer que notre code fonctionne comme on s'y attend très rapidement et très tôt, sans avoir à lancer une application entière. En cas de problème, la présence de tests permet d'éliminer et/ou de valider des hypothèses concernant les causes des bugs.

Il ne reste "plus" qu'à chiffrer tout cela sur une période et comparer le avant/après. Le calcul a été effectué concernant les builds automatiques et les tests :

Activités d'un ingénieur en un mois

2 = Checkout initial
10 = Nettoyage de Build
170 = Build après modification
60 = Build après synchronisation
60 = Lancement de tests

Je vous laisse devenir le temps gagné à l'installation d'un serveur de build automatique.

Une question de balance

Au quotidien, je fais un test unitaire avant de coder, pour savoir tout de suite si ce que je fais "fonctionne". Je me pose plus de questions sur les tests fonctionnels par contre, qui sont plus couteux à mettre en place et qui n'ont pas tous la même valeur. Concrètement, si le client est prêt à accepter que tel dysfonctionnement arrive sans que l'on soit prévenu, je ne fais pas de test automatique. Je ne fais pas non plus de tests pour les fonctionnalités dont le client n'est pas sur ou n'a pas conscience.

Les tests fonctionnels font débat régulèrement du fait de leur surcoût. Les tests IHM font encore moins l'unanimité. Très emballés au début, nous en sommes vites revenus car trop difficiles à maintenir.

Une question de feeling

Je ne peux pas calculer le ROI de l'achat du dernier Radiohead, mais je peux vous assurer qu'il valait le coût et m'a apporté ce que j'en attendais. Pour les tests aussi, il y a des ROI qualitatifs difficiles à chiffrer.

Ils donnent de l'assurance et permet de savoir où l'on va, petit à petit. Il m'évite aussi d'avoir à tester dix fois la même chose à la main, et ça, ça joue sur mon humeur. Cela a peu de prix.

C'était un peu cher au début, un peu comme un bon couteau, mais une fois qu'on y a gouté, on a du mal à s'en passer.

Ressources

La première partie de ce billet : Ecrire des bons tests. Waouw, ce billet a été initialement crée en aout 2010 !

Relever chaque obstacle rencontré

Florence CHABANOIS — Fri, 14 Jan 2011 22:05:00 +0100

Dans le cadre d'une démarche Lean, certains membres de l'équipe avaient voulu se lancer dans la mise en évidence de nos problèmes. L'idée était de pouvoir tracer un diagramme de Pareto et de régler les problèmes les plus importants.

La théorie est belle mais la réalité plus compliquée. En premier lieu, il faut se rendre compte que l'on rencontre un obstacle, puis s'arrêter pour le formaliser et l'écrire. Ensuite seulement, je peux reprendre le cours normal et tenter d'y rémédier. La première fois, on est à peu pres attentif, mais au jour le jour, on oublie facilement ce listing non naturel. A la fin, les données doivent être classées et analysées afin de dégager des tendances.

Clairement, j'avais beau vouloir tenter l'expérience, cette dernière coupait totalement mon flow. De plus, toute l'équipe n'était pas convaincue de l'intérêt de la chose. Quelques temps après, Régis nous a fait remarquer que ce n'était pas une condition nécessaire. Nous nous sommes dits que nous n'étions peut être pas si motivés pour le faire, que révéler un obstacle était peut être inconsciemment perçu comme une mauvaise chose, un aveu d'échec. Il fallait renverser ce sentiment.

Avec un collègue alors présent, nous avons donc fait une deuxième tentative : pendant trois semaines, nous noterions chacun nos obstacles et celui qui en aurait le plus gagnerait une boite de chocolats. Voici les résultats.

Des données brutes différentes

Ma liste

Voici ma liste d'obstacles, bruts de fonderie :

Attente hudson rouge pour tester les erreurs – 1h
Reconfiguration par tatonnement poste individuel apres passage velocite (les tests ne passaient plus) : mtree, package ubuntu inconnu, usr/local/bn/bash – 2h
Evolution n'arrive plus à charger mes mails – 30mn
Logs perdues sur fitnesse → tentatives veines puis réinstallation chroot dont redirection local7 – 15mn
Attente équipe systeme – switching de taches – 2h
Perturbation entre tests fitnesse. Aggravé par multithreading. - recurrent
Logs fitnesse peu lisible dans local7 : suppression local7 → il a fallu reconfigurer syslog. Puis copie du fichier apres chaque test et grep.... (sur certains flags : jonglage « c quoi deja le mot qu'on cherchait pour voir ça? »)
Tomcat se crash a chaque rebuild fitnesse, voire plus. A chaque fois... Constat, puis relance manuelle. ==> essayer en dehors de la chroot ?
Attente entre chaque tentative de fix fitnesse. Rebuild Fit nécesaire à chaque fois car on fit pointe sur les jars pour tous les projets (sauf fixtures). => pas normal
Erreur d'environnement (connexion distance sur un autre poste, on ne testait pas l'appli qu'on avait corrigé) => interdire ecriture distante ?
Attente build : aggravé par le logging en niveau debug. On a essayé de voir d'où ça venait mais trop de causes possibles.
Méconnaissance sujet en cours => dépendance binome (attente)
Rework : apres un move eclipse, on s'est rendu compte que les projets n'étaient pas en « shared » (conf perdue lors de la montee de version de la chroot). On a faire des opérations svn à la main et corriger des erreurs de compil. Entre temps : attente buildr.
Logs à parser dans fitnesse
Certains répertoires sont rajoutés par svn régulierement. On les supprimer à la main pour avoir un « svn st » clean.
Suppression d'une nouvelle classe lors d'une suppression de ces repertoires, on est allés trop vite. 1/2h de perdue car on ne s'en est pas rendu compte tout de suite et cause pas non plus identifiée immédiatement (eclipse etait ok).

Assez vite, j'ai rajouté le temps de blocage car ils ne se valaient pas tous.

La liste de Philippe

Philippe les a plutot classés en taille : Petit, Moyen, Grand. Vous pouvez voir entre parenthèses les causes qu'il a identifiées. Voici ses données :

ven 22 oct : outil 2, attente 1, connaissance 1

(P) (connaissance) Transmission connaissance sur archi du bus (transmission connaissance)
(P) (attente) Temps pour releaser la chroot
(P) (outil/git) Méconnaissance git (outil:git)
(P) (outil/git, configuration) Dernière release chroot : git-svn ne fonctionne pas et git n'est pas en couleur

jeu 21 oct : non isolation 1, complexité fonctionnalité 2, TU 2

(P) Suppression éronnée d'une ligne dans /etc/hosts de la chroot(4) => accès BD locale échoue chez AL (format: lisibilité)
(P) Suppression duplication dans tests (tests: duplication)(TU)
(M) Concurrence d'accès (complexité fonctionnalité: concurrence)
(M) Report inutile sur une branche (overproduction)
(M) Complexité controle du temps (complexité fonctionnalité)
(M) Dépendance entre 2 tests par l'intermédiaire du temps et d'un singleton (solution: bouchonner le temps dans les 2 tests) (mockTime, junit3)(non isolation, TU)

mer 20 oct : TU 1, complexité fonctionnalité 2, outil 2, écart au standard 1

(M) Blocage du clavier => déplacements entre différents postes (méconnaissance outil: ubuntu/gnome)
(P) Modifs du spike non commitées => examen et sauvegarde des modifs pour choisir quoi sauver/commiter/détruire (encours/stock) (écart au standard)
(P) svn merge passé deux fois => (méconnaissance outil: svn)
(M) Difficulté à trouver algo (complexité fonctionnalité)
(P) Difficulté à trouver résultat attendu des test (complexité fonctionnalité)
(P) Temps pour trouver enchainement des tests en TDD (TU)

mar 19 oct : extérieur 1, complexité code 2, outil 2, attente 1, extérieur 1, TF 1, complexité fonctionnalité 1

(P) Difficulté à trouver quoi vérifier dans test du buffer de 30 s. entre 2 rechargements du cache (TF, complexité fonctionnalité)
(P) Déploiement échoue depuis la chroot d'un développeur (outil/erreur outils déploiement)
(P) Manque de contenu sur itg => déploiement sur bench (plateforme: contenu)(complexité code)
(P) Absence du bus sur bench => impossible de déployer (plateforme: retard coté système)(attente, extérieur)
(P) Mauvais fonctionnement du clavier depuis binomage distant occasionant jusqu'à un changement de poste (outil/ubuntu)
(P) Erreur dans le spike de l'ingénierie (complexité code)
(M) Grève RATP/SNCF (extérieur)

lun 18 oct : outil 2, connaissance 2, extérieur 1, complex code 3, connaissance 1

(P) Méconnaissance bash : option de test pour vérifier qu'un fichier n'est pas vide (outil/bash)
(M) Transmission de connaissances : grands nombre d'éléments dans le système des caches (complex code / caches)
(P-M) Longue recherche de l'endroit où se trouve la map racine d'un niveau de cache (cache pgc)(3) (complex code / caches)
(P) Mauvaise date de début de gc.log (distance info-usage)(connaissance)
(P-M) Une colonne de trop dans le plan de service (colonne vide) (erreur format)(extérieur)
(P) Difficulté à expliquer la fonction d'objets du dump mis en avant par "eclipse memory analyzer" (complexité code)
(P) Temps à s'interoger sur la différence entre 650 Mo de heap du dump & 6 Go de mémoire utilisée (connaissance)
(P) Mauvais fonctionnement du clavier depuis binomage distant (outil/ubuntu)

ven 15 oct : rework 1, connaissance 1

(P) Recréation d'une stat : récupération des données brutes (rework)
(P) Incertitude sur quoi travailler

jeu 14 oct : connaissance 1, outil 2

(P) Fichier mysql représente chaque requète lente sur plusieurs lignes (méconnaissance format: mysql)
(P) Méconnaissance de l'option -A de grep (--after-lines) (méconnaissance outil: bash)
(P-M) Task switching suite notamment à une chute de QoS en cours de journée
(P) Manque d'expérience dans l'interprétation des résultats de profiling (méconnaissance outil: mysql)

mer 13 oct (visite médicale => demi-journée) : connaissance 2, extérieur 1

(P) Log des full gc sont sur 2 lignes quand la mémoire dépasse 98% => temps pour adapter le script (méconnaissance format: jvm)
(P) Incertitude sur quoi travailler
(M) Grève RATP/SNCF

mar 12 oct : rework 1, outil 1, extérieur 2

(M) Commandes pour générer graph des gc pas sauvés la première fois (rework)
(P) Méconnaissances des options de awk et date (méconnaissance outil: bash)
(P) Je réponds à des questions de Z. sur son code C perso
(M) Grève RATP/SNCF

lun 11 oct : lisibilité 2, connaissance 1

(M) Code des caches obscur (buildAndSave(), reload()) (obscurité code: caches)
(M) Méconnaissance du mécanisme d'invalidation des caches (1) (obscurité/complexité: caches)
(P) Pas trouvé comment obtenir une connexion mysql dans le contexte de CatalogProxy (2) => utilisation dbUnit provoque une erreur (emplacement code: DAO/ConnectionHelper)

ven 8 oct : rework 1, attente 1

(M) Certains AS de bench swappent => mesures incorectes => tir à relancer (rework)
(M) Attente de reconfiguration des machines de bench par eq. système (attente)

jeu 7 oct : outil 1, connaissance 1, rework 1, attente 1

(P) (outil/jmeter) Incertitude sur fonctionnement jmeter : nb requètes/AS
(P) (connaissance) Tatonnement sur bench à réaliser
(M) (rework) Certains AS de bench swappent => mesures incorectes => tir à relancer (rework)
(P) (attente) Attente que tir s'achève (attente)

Je vous laisse deviner qui a eu droit aux chocolats

Comment les classer ?

Nous n'avions pas du tout la même perception du terme "obstacles". J'avais tendance à faire un filtrage préalable, en n'écrivant que les obstacles sur lequel on pouvait faire quelque chose trandis que Philippe mettait absolument tout.

Nous avons tenté de regrouper nos données. Est ce que nous devions les classer par catégorie de symptômes ou de causes ? Le premier cas ne nous apportent à priori pas grand chose, le deuxième cas nous amènent déjà dans la recherche de solutions. Sans parler du fait qu'il peut y avoir de nombreuses causes et de nombreuses solutions.

Dans un premier temps, nous avons maladroitement essayer de faire des catégories. Une matrice semblait constituer une bonne réprésentation.

Nous avons passé une partie de la pause déjeuner à classer, sans terminer. Plus tard, nous avons repris le tri pendant des moments d'attentes justement. Le travail d'analyse est restée inachevée de mon coté mais Philippe continue et pour l'instant, je crois que ce sont l'attente et le manque de connaissances qui constituent les causes les plus fréquentes.

Ce que j'en ai tiré

L'exercice était plus compliqué que prévu, tant sur la réalisation que sur l'analyse. Ecrire les obstacles est en soi un obstacle, c'est comme s'arrêter en plein fun pour prendre une photo. C'est bien pour plus tard mais c'est au prix du présent.

Il m'a fait prendre conscience de l'importance de certains de mes problèmes, sur lesquels je "glissais" trop vite auparavant. Cela m'a plus incité à les résoudre plutot qu'à eternellement les contourner. D'autant plus quand je me suis aussi rendue compte que d'autres personnes glissaient sur ces mêmes problèmes.

J'ai aussi l'impression que des causes trop macro type "attente", "cause extérieure" sont trop grosses pour être exploitables.

Je pense retenter l'expérience dans les prochains mois; cette fois avec une idée plus claire de la méthode.

Avant tout :

Je timeboxerai l'expérience sur quelques semaines.
Je chercherai un ami dans l'équipe. Car clairement, il faut être extrêmement attentif pour avoir conscience de ses propres obstacles. Un accolyte n'est pas de trop pour les pointer du doigt.
Je préparerai un tas de feuilles de brouillon et un bac (rouge?) que je remplirai au fur et à mesure des obstacles rencontrés (format plus manipulable et collectif)
Nous definirions un format commun avec au moins le symptome et la durée d'impact (1h, 1/2journée, 1 jour). Un obstacle = une feuille.

Au moment du dépouillement, lors d'une rétro par exemple :

Les obstacles identiques seront regroupées et évalués en termes d'impacts.

S'il y a un obstacle particulier qui ressort :

Nous prendrions l'obstacle le plus important et réfléchirions ensembles à toutes les causes possibles. Puis à toutes les solutions possibles.
Et nous choisirions une action. Il faut être précis tant sur les causes que les problèmes.
Les autres obstacles seront simplement survolés et archivés pour un autre dépouillement ou affichés.

Si aucun obstacle particulier ne ressort

Nous chercherions les causes possibles de chacun des obstacles. La cause (elle doit être assez précise) la plus fréquente sera celle à traiter.
L'équipe cherche des actions possibles et en choisit une. Le pari est que ce levier permettra de faire tomber plusieurs problèmes.

Ce ne sera pas parfait mais déjà mieux je pense. Avez-vous déja tenté ce type d'expérience ?

Des pratiques à reprendre

Florence CHABANOIS — Sun, 02 Jan 2011 23:31:00 +0100

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.

Les pratiques extras

Les standards sont le bien. Il y a un tableau avec un post it par standard, construit peu à peu par l'équipe
L'auto gestion et le lead par l'équipe. Toutes les décisions sont prises par l'équipe, suite à un vote. Le processus de décision est plus lent et il peut y avoir des clashs mais au final, il y a plus de conviction. Un consensus mou ne permet pas de valider une décision. Par ailleurs, si le client a un lien plus régulier avec le scrum master, c'est à toute l'équipe que les mails sont envoyés et n'importe quel membre de l'équipe répond directement à ses questions. Quasiment tout le monde fait des propositions d'améliorations du coup.
Le binomage systématique. Meilleure qualité du produit, moins de rework, plus d'apprentissage et meilleure ambiance.

Le Developpeur Responsables des Incidents de la Semaine fait barrage et il tourne chaque semaine. La duree d'une semaine est assez longue pour permettre de monter en compétence sur le fonctionnel.
La chroot. Ca, c'est vraiment génial. Il permet à chaque développeur d'avoir exactement le même environnement de travail, avec les memes logiciels, les mêmes alias. Moins de configuration et plus de travail intéressant. Le site de Barreverte publiera prochainement un article à ce sujet, essayer c'est l'adopter.
L'audace m'a également frappé dans cette équipe. Pas de scrupules à tuer le code mort, à appuyer où ça fait mal ou à essayer des choses.
L'intransigeance avec le code propre
Les réunions d'alignement. Les membres de l'équipe peut écrire des sujets au fur et à mesure. Ils sont traités le premier lundi du mois, par vote.
Les ateliers lectures. Une fois par mois, l'équipe se réunit autour d'un article choisi par le scrum master, qui a plus de recul que l'équipe.
L'équipe vélocité dont l'objectif est d'augmenter la vélocité. Deux membres de l'équipe travaillent sur un sujet annexe au sprint, comme la mise en place d'un nouvel outil de build ou de git par exemple. Les projets sont souvent issus des réunions d'alignements.
Les archives dans un classeur physiques ou un paper board. Un peu rétro mais réellement pratique : c'est arrivé plusieurs fois qu'on aille chercher dedans.
Les étiquettes partout. On trouve tout plus vite, ,on ne stocke plus pour rien.
Les chiffrages des stories en votant avec les mains.
Les estimations en jours binomes. Cela évite les calculs où on se dit qu'en travaillant à deux, on avance plus lentement.
Le fait de savoir tous les matins si on est sur la bonne voie, en comparant le nombre de points taches accomplis la veille avec ce qui devrait etre accompli. Et de se demander que faire pour y remédier.
L'importance des métriques manuelles => elles sont ainsi plus souvent regardées.

Les pratiques qui m'ont troublée

Les réunions qui ont lieu dans la war room. Le checkout officiel doit nous permettre de nous en échapper mais ce n'est pas vraiment possible quand il y a une réunion à 50cm de soit. L'autre problème est que c'est difficile de projeter des choses.
Les affichages plein le mur, y compris derriere les bureaux. D'ailleurs il n'y a plus de mur. Les affiches sont disponibles au moins, on peut dire, mais finalement pas tant que ça. Certaines affiches contient des éléments écrits en tout petits sur lequel on a du mal à revenir. Pour l'instant, ce sont juste des données non exploitées.
L'absence de gardien du temps, corollaire de l'équipe autogéré. Tout le monde à la liberté de dire que quelqu'un s'égare mais on ne se sent pas toujours la légitimité pour le faire.
Les 6 points de user stories par itération. Le task board est plus léger (<=> plus lisible) mais la valeur d'un point est énorme. Entre un et trois points, il y a plusieurs jours de travail.
Les stories découpées au moment de la review, et le calcul de reste à faire pour la suite.
La non inclusion des obligations de moyen dans les user stories. Les obligations de moyens (type support VABF), les réunions d'alignements et les chiffrages sont exclus lors du calcul des points pour le prochain sprint.
Le client au stand up meeting tous les matins, par audio conférence.
Le fait de faire des tests unitaires assez hauts niveaux pour permettre le refactoring. Du coup, on ne voit pas tout de suite si une méthode est testée, il faut faire des recherche d'appels (car elle sera souvent testée indirectement).
"Faire "f" pour lancer les tests fitnesse, c'est encore trop long." Il n'y a pas de limites au mieux.
La durée des standup (une demi heure pour une équipe de dix personnes). Chacun rentre assez dans les détails des taches de la veille. L'avantage est que cela va dans le sens de la collectivité du code (tout le monde est au courant et cela laisse une porte ouverte à la contestation) mais cela invite aussi à digresser.
Le nombre de décisions en off, lors de standup. Cela facilite les échanges, mais c'est embetant quand il y a des absents.

Timeout, c'est mon heure de dodo. Merci encore à toute l'équipe, j'ai passé des super moments avec vous.

Bonne nuit et bonne année à tous !

Retour sur le 6e séminaire Lean & SI

Florence CHABANOIS — Sun, 05 Dec 2010 23:15:00 +0100

L'institut Lean organise régulièrement des séminaires autour du Lean. Certains sont gratuites, comme la 14e du Lean en France le 16 décembre, d'autres payantes durent toute la journée, comme le 7 décembre avec Michael Ballé. Je vous conseille vivement d'y assister si vous en avez l'occasion !

Ce billet évoque quelques éléments de la sixième séance du séminaire "Lean et Système d'information" :

"Mise en flux continu des incidents informatiques" par Catherine Chabiron, Lean Office and IT Governance, Faurecia ;
"Le Lean dans la maintenance du système d'information" par Régis Médina, Operae Partners

Mise en flux continu des incidents informatiques, par Catherine Chabiron

Cette présentation m'a ramené à des années en arrière, dans ma vie précédente, quand alors au service Qualité, nous mettions ITIL en place à BBGR. Non sans quelques difficultés. Agiliste convaincue, je n'imaginais pas entendre parlé d'ITIL de si tôt.

Faurecia a mis en place plusieurs files d'attentes pour gérer les incidents, en fonciton de leur complexité, typiquement les niveau 1, niveau 2 et niveau 3. Là où c'est nouveau, c'est qu'elle montre chiffres à l'appui, en quoi c'est avantageux. Un incident serait résolu 100 fois plus vite à un niveau 1 qu'à un niveau 3 par exemple. En plus la qualitification moindre des niveaux 1 (= cout salarial moins), le temps de résolution plus tard, à un niveau supérieur est forcément plus long car il est plus alors plus difficile d'identifier les causes d'un problème.

Catherine Chabiron évoque ensuite l'importance d'un flux continu, pour ne pas avoir de stock (=attente). Pour ce faire, un management visuel a rendu visible ces stocks et des standards ont été fixés par le biais de seuils d'alerte. Les métriques portent à la fois sur des données à un instant T mais aussi sur des variations.

Les éléments suivant m'ont marqué :

les 1% des utilisateurs pas contents sont particulièrement visisbles
le manager vérifie régulièrement le bon suivi des standards
les KPI sont partagés avec le prestataire (Help Desk), ce qui assure l'alignement des objectifs. Il n'y en a qu'un seul en réalité, sur la satisfaction des clients car même si un SLA est respecté, le client n'est pas forcément content. Les métriques classiques (taux de résolution, etc.) sont mesurés uniquement pour un usage interne.
les métriques sont mise à jour manuellement, en dépit du fait que "les informaticiens aiment bien tout avoir en appuyant sur un bouton :D". L'aspect manuel permet de les remettre en cause, d'en discuter, et surtout de les voir. Les métriques automatiques ne sont pas suivies. C'est une réalité dont je n'avais pas conscience.

Le Lean dans la maintenance du système d'information, par Régis Médina

Le plan était un PDCA, tout simplement. Nous allions aborder le problème, voir les actions essayées, évaluer si elles sont portées leur fruits et en tirer des leçons.

La voix du client

Quand nous demandons au client ce qu'il veut, il dira qu'il ne veut pas perdre de temps (= répéter, = attendre, = refaire), qu'il ne veut pas perdre d'argent ou encore autre chose. Pourtant, avant tout, c'est surtout avoir un système qui fonctionne qui compte. Pour le reste, il s'agit de résoudre les problèmes.

Si au sein de l'entreprise, certains services semblent être les clients d'autres (la MOA pour la MOE par exemple), il n'y a en réalité pas des clients mais bien un seul au final. Tous les autres : les études, la maitrise d'ouvrage, les opérations, le help desk constituent bel et bien une seule équipe.

Voir

Régis a demandé à son client le nombre de tickets par mois et le temps de résolution moyen. Personne ne connaissait la réponse. "Il faut regarder dans le système". Si nous ne voyons pas les problèmes, nous ne cherchons pas à nous améliorer et il ne peut pas y avoir ni standards, ni objectifs. Une métrique simplissime, sur une page peut suffire.

Parachuter un expert n'est pas efficace, il vaut mieux déjà rendre acteur l'équipe, puis experte, en augmentant la visibilité des problèmes et donc leur résolutions.

Les métriques

Les indicateurs sont crées par l'équipe et mis à jours manuellement tous les matins par eux. En couleur s'il vous plait.

La premiere métrique concerne le Lead Time : on voit en rouge les incidents qui ont mis plus de 4h à être résolus, les autres sont en vert.

La deuxième idée consiste à rendre visible les tickets en attente, en comparant leur nombre avec les autres.

Tous les jours, quand il y a du rouge, l'équipe s'interroge sur les raisons et se demande ce qu'elle peut y faire. Il ne s'agit pas de faire du reporting mais bien d'afficher sa performance et de piloter.

Le fait de ne pas voir les problèmes est un véritable problème. Le rôle du coach est de les rendre visible et c'est à l'équipe de trouver la solution. A ce sujet, Régis raconte une anecdote, où personne ne connaissait la procédure de test. C'est une personne qui s'en occupe la nuit, tout seul. Comment automatiser une procédure de test inconnue ?

L'équipe dresse également un pareto au fur et à mesure qu'elle rencontre des incidents. Le Pareto est le graphique montrant le nombre d'incidents par type d'incident. Tous les quinze jours, l'équipe consulte son pareto et cherche à supprimer les plus importants.

Le bilan

En demandant à l'équipe ce qu'elle a appris, elle répond

le travail d'équipe. Ils sont ensemble, avec le même client.
"aider les autres équipes (en particulier le niveau 1) nous est bénéfice." Les incidents remontent moins/pas aux niveaux supérieurs.
les standards. Ne pas travailler dans l'urgence permet de faire les choses plus proprement.

Pour conclure, Régis nous laisse méditer sur les sujets suivants :

L'expérience a également démontré que la qualité opérationnelle ne signifie pas nécessairement qu'il y a des résultats économiques. De plus, il faut veiller à ce que le sponsor ne redeviennent pas "interventionniste" au moindre problème.
Les boucles d'améliorations via les PDCA sur les produits s'appliquent finalement aussi sur les processus.
Il ne suffit pas de demander explicitement au client ce qu'il veut, il faut comprendre son métier.
L'indicateur sur la satisfaction client est essentiel.

Conclusion

En quelques heures à peine, les retours d'expériences des orateurs nous font sortir la tête de l'eau et méditer sur d'autres problèmes et d'autres. Le buffet a également constitué un espace convivial pour les échanges avec participants et orateurs. Je donne un ROTI de 5 pour mon baptème et y retounerai !

Je remercie chaleureusement les organisateurs et les speakers pour cette demi-journée riche en réflexions.

Source de l'image "diagramme de pareto" : http://www.archimarketing.com/marketing/focalisez-efforts-sur-20-pourcents-qui-comptent-713

Meme quand j'ai raison, j'ai tort

Florence CHABANOIS — Thu, 18 Nov 2010 13:24:00 +0100

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é :

- Bravo, tu avais raison.
- Bah non je n'avais pas raison, c'est la majorité qui l'emporte.
- Ah non, ce n'est pas vrai. Tu aurais du insisté car tu avais vu juste. Laisse moi te raconter une expérience.

Il s'agit de demander à un groupe de personnes laquelle de deux lignes tracées est la plus longue. Parmi ce groupe, tout le monde en réalité est complice, sauf un, et l'ensemble défendra avec force la mauvaise réponse. Influencée par ces pressions, la personne finit par croire elle aussi que le trait le plus court est le plus long. Tu vois, la majorité n'a pas toujours raison.

Ce n'était pas ce que je voulais dire. Je voulais dire que dans la mesure où la majorité n'a pas été convaincu, j'ai tort. Si mes raisons et arguments ne font pas echos et ne parlent apparemment qu'à moi, le fait "d'avoir raison" ne vaut rien. Par ailleurs, c'était un détail et je préférai préserver mon énergie pour quelque chose de plus sérieux.

Au final, le plus important dans une décision, c'est le consensus du groupe. Même si la décision s'avère mauvaise au final, si à un moment donné elle a semblé la meilleure pour tout le monde ou presque, c'est celle là qu'il faut suivre en premier. Si dans le futur, on se trompe, on donnera un peu plus de crédit à la voix isolée. On aura décidé (consciemment ou pas) d'être plus sensible à l'expertise de telle personne.

Attention aux faux consensus : a la longue, si cette confiance devient trop forte et que la seule raison de suivre une décision est "parce qu'untel l'a dit", elle ne sera pas réellement suivie. Elle constitue donc aussi une "mauvaise décision", avec un seul porteur.

J'ai besoin de faire mes erreurs

Il m'arrive d'entendre les arguments très rationnels de personnes pour me dire qu'il vaut mieux éviter telle voie. Parfois, je n'arrive juste pas à être convaincue, j'ai besoin de faire l'erreur. Pour me rendre compte par moi-même du pourquoi des échecs et des conséquences. Et puis, je ne connais personne qui ait tout le temps raison.

De plus, chaque expérience est différente. Ce n'est pas parce que telle solution n'a pas fonctionné pour X qu'elle ne fonctionnera pas dans mon contexte. Non ?

Les autres aussi

L'inverse est vrai aussi. Pour le coup, je n'ai pas d'exemple en tête, mais je suis sûre que vous en trouverez. Vous avez dit et répéter la même chose à quelqu'un : votre manager, un collègue, votre enfant, votre copine, un ami. Mais votre message n'a jamais semblé atteindre le destinataire, son comportement est resté strictement identique. Un beau jour, votre manager/collègue/enfant/copine/ami vous dira : "<la phrase que vous rabacher depuis des lustres>", comme si votre message avait fini de traverser l'univers pour atteindre tout à coup son cerveau.

Le premier réflexe est de le prendre personnellement. Mais sii, on vous écoute. Il a juste eu lui aussi besoin de sentir les conséquences de son comportement pour arriver à la même conclusion (ou pas).

De plus, c'est parfois moins efficace de donner directement la voie à prendre que de laisser les gens faire leur expérience. Expliquer à un enfant comment marcher avec des descriptions est plus long que de le laisser tatonner, au risque de tomber. C'est de cette façon qu'il interiorisera le mieux les choses à faire et à ne pas faire.

C'est difficile de laisser faire

Je me suis rendue compte dernièrement à quel point c'était dur de ne pas intervenir lors d'un atelier A3. En me taisant, l'autre personne a tout le loisir d'explorer un chemin que je n'avais pas du tout vu. Et au moins, ce chemin sera engagé. On ne pourrait pas dire la même chose d'une solution parachutée par un consultant. Merci à Pascal Van Cauwenberghe de m'avoir permis de mettre le doigt sur ce point.

C'est plus long, mais le jeu en vaut la chandelle, comme toute bonne donne décision.