Quelques optimisations sur le front

XITI chapitres

Une fois n'est pas coutume, je vais parler de développement front sur ce blog. Rien de révolutionnaire pour une personne du métier mais venant du monde java, j'ai suffisamment galéré pour en parler :-)

J'ai commencé par un nettoyage visuel pour poursuivre sur la réduction du temps de chargement de la page. Le plus gros du travail a concerné les images. Les outils utilisés sont très répandus, leurs préconisations très simples à suivre sur un environnement où l'on a la main mais moins chez un hébergeur gratuit comme Free.

Lire la suite

Reprogrammez son cerveau

Je suis devenue manager parce que je voulais faire une différence, je voulais que les gens s'éclatent. En réalité, le poste n'y est pour rien. 

Je peux être furax en rentrant chez moi le soir parce que machin m'a dit ça. Alors qu'il ne s'en rappelle même pas... Je peux être ravie pour un mini-succès sans valeur business mais concluant un combat de longue date. Mon environnement m'influe mais l'inverse est vrai aussi : je peux lancer une action qui me parait énorme qui fait plouf ou prononcer une phrase anodine qui fait l'effet d'une bombe sur les équipes. 

C'est en tant que coéquipier, que l'on soit marketeux, webmasteur, à la relation client ou développeur que nous influons sur le climat au travail et l'épanouissement de l'ensemble.

Lire la suite

Les tickets

Poster une lettre

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.

Lire la suite

Manager et/ou développer ?

Developer

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

Lire la suite

Retour d'expérience sur le monitoring des logs

burndown.png

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

Lire la suite

Etre alerté quand une nouvelle erreur squatte nos logs

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

Lire la suite

Les mille pourquoi

question_mark.jpg

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

Lire la suite

Agile France 2011 : Star Wars et Lean

AgileFranceConference2011-logo.jpg

AgileFranceConference2011-logo.jpgComme 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.

Lire la suite

Feedback de l'équipe

Feedback

FeedbackJ'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.

Lire la suite

Exécuter la même commande sur plusieurs serveurs

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.

Lire la suite

Agilité et carrière

homme_d_affaires.jpg

homme_d_affaires.jpgAu 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.

Lire la suite

Donner des cadres

cadre.jpg

cadre.jpgQuand 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.

  1. Plan : recherche des causes racines possibles et planification
  2. Do : mettre en œuvre
  3. Check : vérifier que l'action résoud bien le problème
  4. 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.

Lire la suite

ROI des tests automatiques

dollar.jpg

dollar.jpgL'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 ?

Lire la suite

Relever chaque obstacle rencontré

liste.jpg

liste.jpgDans 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.

Lire la suite

Des pratiques à reprendre

burndown_avsp.jpg

burndown_avsp.jpgJ'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.

Lire la suite

Retour sur le 6e séminaire Lean & SI

pareto-clients.gif

pareto-clients.gifL'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

Lire la suite

Meme quand j'ai raison, j'ai tort

homme_question.jpg

homme_question.jpgAu 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.

Lire la suite

Tester des scripts shell avec ShUnit2

Originellement développé par Vera Peeters and Rik Tytgat, ShUnit a été le premier outil de tests unitaires en shell.

Il permet de valider que vos scripts shell effectuent bien ce que vous en attendez. Intégrez vos tests shunit à votre usine de développement et vous serez assurés qu'ils resteront valides de façon permanente, qu'ils ne souffriront d'aucune régression sans vous en alerter.

Je vous propose de me suivre sur les traces d'un framework un peu plus xUnit like : ShUnit2 de Kate Ward.

Lire la suite

Voter avec ses mains

doigts.jpg

Parmi les goodies de l'agile tour Paris 2010, il y avait des cartes de planning poker d'Octo. J'en avais déjà eu aux XPDays 2009 mais j'ai apprécié le cadeau car je n'en avais pas assez. Je me rappelle le plaisir que j'ai eu la premiere fois à utiliser des cartes pour évaluer les complexité des  […]

Lire la suite

Atelier SCJP

Je reviens d'un atelier SCJP (certification Java) et ça fait plusieurs mois que je voulais poster un petit billet à ce sujet. Il est organisé par les JDuchess (en particulier Katia) et vous pouvez vous inscrire sur le groupe google si vous souhaitez être tenus au courant ou participez virtuellement  […]

Lire la suite

Haut de page