Une équipe agile, c'est comme l'équipe du Dr House

le 18 avril 2016, par Jean-Philippe Caruana

L’autre soir, je regardais un épisode de Dr House (oui, ça arrive) et j’ai été frappé par la similitude entre le fonctionnement de son équipe et celui d’une équipe agile.

Dr House

Pour ceux qui ne connaissent pas Dr House, il s’agit d’une série américaine dont le “héro”, le Dr House, résout en équipe des cas médicaux difficiles, voire impossibles - en tout cas, dont le pronostique vital est largement prononcé. Comme médecin, Dr House est vraiment très fort, brillant, surprennant, mais il a besoin d’une équipe pour fonctionner. Seul, il dépérit et ne peut résoudre les problèmes qu’on lui pose. Comme être humain, il est invivable, mais cela ne nous intéresse pas ici.

Comment fonctionne cette équipe ? C’est très simple : un patient arrive, au seuil de la mort. En observant tous les symptômes, l’équipe soumet un feu continu d’hypothèses et de causes possibles au reste de l’équipe afin de trouver comment soigner leur patient. La discussion se déroule à bâtons rompus, et chaque hypothèse est soit démontée immédiatement (un symptôme manque ou bien ne colle pas avec le reste), soit validée ou invalidée par l’expérience (un examen médical ou une expérience folle qui risque de mettre en danger le patient).

Dans mon équipe

Eh bien dans une équipe agile, c’est pareil. Quand on rencontre un bug ou quand on cherche à faire évoluer son architecture pour le prochain palier de trafic de son service, il n’y a pas de solution immédiate, évidente qui saute aux yeux de tout le monde. Si une solution immédiate existe, alors il n’y a pas à en parler, on l’applique et c’est terminé.

Alors on procède comme le Dr House : on part des symptômes (comportement incorrect de l’application, augmentation des temps de réponse, charge importante de la base de données…) pour arriver au correctif ou à l’évolution souhaitée. On fait des ateliers, ou parle au café, le midi, le soir devant l’entrée du bureau. On émet des hypothèses, on pousse une idée qui nous semble absurde jusqu’au bout afin d’en tirer les bons éléments. On pose des questions, soulève les difficultés posées par une idée, propose des scénarii du type “qu’est-ce qui se passe si le serveur reboote à ce moment précis ?” ou “que se passe-t-il quand le disque dur est plein ?”.

À la fin, notre patient est soigné et le client est content.

Alors ?

Alors, votre équipe fonctionne-t-elle comme celle du Dr House ? Tout le monde exprime-t-il ses idées les plus folles librement, challenge celles des autres ? Dans le cas contraire, qu’est-ce que vous attendez pour établir le meilleur diagnostique pour résoudre le problème qui vous préoccupe actuellement ?

Le A3 comme outil de communication avec le management

le 12 avril 2016, par Bruno Thomas

Il y a peu encore, je travaillais pour un groupe de télécom qui commercialise une messagerie instantanée d’entreprise permettant aux internautes de communiquer avec le service client depuis un site web. Il comprend une distribution des chats dans des files d’attentes, des outils d’aide pour les conseillers et des outils de supervision/administration.

Astuce - lancer un conteneur docker comme un service système

le 8 octobre 2015, par Jean-Philippe Caruana

Je ne vais pas ici vous faire une introduction à docker, ce n’est pas l’objet de ce post.

MongoDb le cluster qui bagote, la suite

le 23 septembre 2015, par Bruno Thomas

Suite de notre épisode précédent sur les bagots mongo, nous reprenons où nous nous étions arrêtés : nous avons un test d’acceptance instable et nous avons acquis la certitude que le cluster mongo en est la cause. Soit il est mal configuré soit buggué.

Être alerté en cas de OutOfMemoryException

le 7 septembre 2015, par Jean-Philippe Caruana

Un des plus grands dangers quand on exploite un service en production, c’est de ne pas être au courant qu’un problème a eu lieu. Un des problèmes graves que l’on peut rencontrer est l’arrêt d’une JVM qui n’a plus assez de mémoire disponible. D’innombrables causes peuvent en être l’origine, mais ce n’est pas le sujet de ce billet. Ici, nous allons voir comment en être alerté, afin de pouvoir réagir (relancer le service par exemple). Il faudra ensuite que l’équipe se penche sur le problème pour éviter que cela ne se reproduise.

Optimiser son client ssh

le 25 août 2015, par Jean-Philippe Caruana

Dans mon travail quotidien, je me connecte très souvent à une multitude de serveurs, que ce soit pour aller sur le serveur de logs, pour faire une mise en production ou faire de la maintenance système. Je me connecte également très souvent (sans le savoir) aux serveurs de github à chacune de mes actions git pull et git push.

Retour sur l'Agile Conférence 2015

le 8 juillet 2015, par Bruno Thomas

La semaine dernière, nous avons retrouvé les oies et les canards du chalet de la porte jaune pour la 10e édition de la conférence agile (anciennement XP Days), pour une thématique “par delà l’agilité”. Retour sur ce que nous avons retenu de l’ère post-agile, avec notre filtre forcément subjectif.

Le bagot du jour de l'an ou l'assert laxe

le 8 janvier 2015, par Bruno Thomas

Le 2 janvier est propice à la chasse au bagot : il est fréquent de rentrer encore un peu barbouillé des fêtes de fin d’années et d’être accueilli par une intégration continue rouge. Tests qui ne fonctionnent qu’en année bissextile, année codée en dur, numéro de mois qui va de 0 à 11, toutes les raisons sont bonnes.

Astuce - laisser nginx répondre robots.txt

le 7 janvier 2015, par Jean-Philippe Caruana

Sur le service sur lequel je travaille, j’ai observé de nombreuses erreurs 500 suite à des tentatives du Google Bot de trouver le fichier /robots.txt. Voici par exemple une log d’erreur de nginx :