Comment suivez-vous ce que vous et votre équipe travaillez quotidiennement?

61

J'ai du mal à savoir ce que moi-même et les membres de mon équipe faisons chaque jour. J'obtiens une bonne image en parcourant chaque semaine les cartes terminées et les stand-ups aident un peu, mais j'ai l'impression que je ne maîtrise pas bien le travail quotidien de mon équipe. Les cartes resteront en circulation pendant des jours sans mise à jour quotidienne, et certains ingénieurs pensent que mon équipe n’est pas très communicative.

J'ai envisagé de mettre en place une sorte de journal quotidien que tout le monde remplit (via une liste de diffusion ou un document partagé Google), mais cela semble assez lourd et manuel.

Surveiller l'activité de GitHub fait un travail correct mais peut être un peu pénible avec le nombre de courriels qu'il envoie chaque jour. J'ai pensé à essayer de construire un système de digestion, mais je n'ai pas le temps.

Quelles stratégies avez-vous mises en place pour rester au courant de ce que votre équipe fait chaque jour afin de pouvoir mesurer le travail effectué sur les tâches en cours?

Brian Brunner
la source
5
Ce serait mieux de demander à lieu de travail.se.
mattnz
39
@mattnz - je ne sais pas. La réponse variera considérablement entre un programmeur et un joueur de basket-ball et un facteur.
Telastyn
17
Cela devrait être couvert dans le stand-up quotidien. Là où je travaille, chacun de nos développeurs indique ce sur quoi nous travaillons actuellement et ce sur quoi nous avons l’intention de travailler demain. Le truc, c’est que les participants ne doivent pas avoir l’impression d’être «suivis», si vous pensez qu’un développeur risque de prendre du retard, ne le mentionnez pas dans le stand-up, mais gardez cette conversation privée.
JuStDaN
5
@mattnz - D'accord, remplacez les exemples par Accountant and Lawyer. Ou docteur et homme politique. Ou plombier et secrétaire. En fin de compte, il n’ya pas de solution unique pour savoir ce que fait une équipe de professionnels, car différentes professions ont besoin d’approches différentes - et ne sont donc pas parfaitement adaptées au lieu de travail.
Telastyn

Réponses:

108

Je leur parle.

La technologie ne peut pas résoudre les problèmes sociaux. Vous avez de brefs relèvements matinaux. Qu'est-ce que vous avez fait hier? Que vas-tu faire aujourd'hui? Des obstacles?

Si quelque chose semble louche (ou si je suis curieux), je m'arrête et pose des questions: "Vous travailliez sur XYZ hier, comment cela s'est-il passé?". Cela oblige les gens à faire attention et à savoir réellement ce qui se passe. Cela vous permet également de garder l’équipe en tête (en prêtant attention et en sachant ce qui se passe). Cela doit être à l'heure et court (10 minutes maximum ). Tout le reste et les gens ne vont pas "ranger" le travail. Ils s'arrêtent et attendent le stand-up, puis prennent le temps de recommencer. Certains le feront quand même, mais c'est en grande partie inévitable.

Ensuite, je passe à tout le monde dans l'après-midi. Pas tous les après-midi (bien que cela puisse être plus que chaque après-midi pour les nouvelles personnes), pas à la même heure, mais à peu près à la même heure (c'est donc à la fois informel et régulier). "Des problèmes? Des obstacles?"

Vous serez surpris de la fréquence à laquelle vous rencontrerez des problèmes lorsque les gens se rencontreront seuls.

Si les gens n'ont pas de problèmes, tant mieux; retourne travailler. S'ils n'ont pas de problèmes toute la semaine ? Problème. Vous ne les défiez pas assez, ou ils ne s'ouvrent pas. Demandez comment XYZ (qu'ils ont mentionné en stand-up) va. Faites-leur expliquer les choses.

Ce n'est pas de la microgestion. Vous ne leur dites pas comment faire leur travail. Vous ne les gardez pas. Vous êtes là pour éliminer les obstacles de leur vie quotidienne. Vous avez besoin d'informations pour le faire. Tant que vous gardez votre équipe en dehors des réunions et les chefs de projet en dehors de leurs cubes, une personne qui s'arrête pour aider une fois par jour ne leur causera pas de chagrin. Mais toutes ces interactions doivent provenir de la veine "Je suis ici pour vous aider".

Une autre chose que je ferai est d’examiner les changesets (par moi-même, de manière informelle). Je peux ensuite voir à quelle fréquence les gens vérifient, quelle est la taille de leurs ensembles de modifications, comment cela correspond à ce qu'ils ont signalé, à quelle fréquence ils refont des choses, combien de corrections de bogues ils ont, etc. Un élément de travail qui passe à l'état "terminé" n'a presque pas de sens. Regarde le code. Cela semble-t-il terminé?

note: un point extrêmement grave: quelle est la taille de votre équipe? Est-ce plus de 7 personnes? Bien sûr, vous ne pourrez pas suivre tout ce qui se passe si votre équipe est trop grande.

Telastyn
la source
31
+1 Les équipes qui ne communiquent pas ne sont pas des équipes et ne travaillent pas.
11
J'aime ça. "Vous êtes là pour éliminer les obstacles de leur quotidien. Vous avez besoin d'informations pour le faire." Nous pourrions être meilleurs là où je travaille.
Robert Harvey
33
Sensationnel. Révolutionnaire! Dois-je réellement parler? Ou puis-je avoir une application pour ça?
andy256
7
@Snowman: Votre commentaire n'est rien d'autre qu'une fausse platitude. J'ai fait partie de nombreux types d'équipes au fil des ans et je n'ai pas vu votre platitude être un facteur clé du succès ou de l'échec de ces équipes. Certaines équipes ont été extrêmement efficaces et ont très bien réussi à piquer du nez, à le faire, ne me dérange pas (en fait, les équipes les plus performantes dans lesquelles je suis allé ont été comme ça). Tandis que d'autres équipes ont eu des échecs complets avec la communication jusqu'à la Ying-Yang.
Dunk
5
RE: "S'ils n'ont pas de problèmes toute la semaine? Problème." - Il se peut aussi que vous ne soyez pas la bonne personne pour résoudre le problème. Peut-être qu'un autre développeur, Internet ou quelque chose d'autre travaille déjà pour éliminer l'obstacle.
Sixtyfootersdude
143

Ne micro-gérez pas vos développeurs!

Le développement de logiciels productifs nécessite de longs efforts mentaux concentrés. Il n'est pas réaliste de s'attendre à ce qu'ils produisent une production constante. Si vous commencez à les mesurer quotidiennement, ils restructureront leur travail de manière à toujours produire des artefacts discernables que vous pourrez voir chaque jour. Cela peut ou non avoir un impact positif sur la qualité de votre logiciel. Cela aura presque certainement un impact négatif sur l'efficacité de vos développeurs.

Robert Harvey
la source
27
Malheureusement, je n'ai qu'un vote positif pour cela! "Si vous commencez à les mesurer quotidiennement, ils restructureront leur travail de manière à toujours produire des artefacts discernables que vous pourrez voir chaque jour.": Pour les tâches complexes, même un point de contrôle hebdomadaire (sprints d'une semaine) peut avoir cette information. effet: vous finissez par travailler pour produire un résultat visible au lieu de vous concentrer sur la résolution des vrais problèmes.
Giorgio
4
Arrive le moment venu, je passe le premier jour à cueillir les fruits à portée de main pour jouer au jeu des chiffres. Regardez combien nous avons fait en un jour! Je garde un peu moins de temps que d’autres jours pour pouvoir répondre à vos besoins le plus tôt le matin, puis passer le reste de la journée à travailler sur des tâches importantes .
6
On pourrait soutenir que le travail sans artefact visible n'est pas utile pour vos clients, et donc pour votre avocat </ devil
>>
14
@Telastyn: Il est clair que vous avez besoin d'artefacts visibles pour être utiles à vos clients. Le point est combien de fois vous et votre client en avez besoin. Il n'y a pas de règle générale mais un suivi trop étroit du processus de développement peut perturber le processus lui-même, le ralentir et réduire la qualité des résultats. Comme exemple provocateur, lorsque vous marchez, vérifiez-vous que vous allez dans la bonne direction après chaque étape?
Giorgio
3
Je suis d'accord avec le contenu, mais je ne suis pas d'accord pour dire que c'est une réponse à la question. Je surveille les progrès quotidiens, mais la gestion est un processus interactif. Cette interaction est généralement réservée à la fin du sprint. Même si vous gérez des statistiques de haut niveau, ces statistiques sont établies en rassemblant des points de données individuels. Ils n'apparaissent pas comme par magie sur mon bureau.
MSalters
9

Comme Robert Harvey le suggère , ne gérez pas votre équipe de manière micro. Confiez à l'équipe des tâches prioritaires avec une valeur commerciale concrète et laissez votre équipe déterminer le meilleur moyen de générer cette valeur commerciale.

Si l'équipe apporte une valeur commerciale, vous devriez être heureux. La façon dont ils s'y prennent pour s'assurer de fournir les fonctionnalités demandées devrait leur appartenir.

Pourtant:

Les cartes resteront en circulation pendant des jours sans mise à jour au stand-up quotidien

Cela pourrait indiquer qu'il y a une lacune dans le processus.

Cela pourrait être l’équipe qui ne fonctionne pas vraiment en équipe et qui n’intervient pas pour s’entraider quand elle est bloquée. Cela pourrait aussi être la communication avec l'entreprise. Les tâches sont trop lourdes, il devient donc difficile de déterminer ce qui est nécessaire. Les spécifications ne sont pas claires.

Il se pourrait aussi qu’il n’y ait aucun problème réel. Peut-être que l'équipe fonctionne bien avec des cartes représentant des tâches majeures qui prennent des jours à compléter, et peut-être que l'équipe travaille bien pour y parvenir.

Je pense qu'il est valable d'utiliser la rétrospective comme plate-forme pour exprimer votre préoccupation. Parfois, recevoir des observations de l'extérieur est une bonne chose.

Mais laissez l'équipe déterminer s'il y a un problème et quelle en est la cause. Et soyez prêt à accepter le fait que vous devez peut-être adapter la manière dont les tâches sont livrées à l'équipe.

Rappelez-vous que le travail quotidien est un outil pour aider l'équipe à organiser son travail. ce n'est PAS un outil pour les gestionnaires pour garder une trace de ce que l'équipe fait.

Pete
la source
6

La «messagerie push» ne «tire pas la messagerie»

Un développeur accédera souvent à l’un des états suivants qui vous intéressent:

  1. Yaaay, j'ai fait X!
  2. Je travaille sur X, mais il semble que cela prendra du temps ...
  3. Je suis bloqué sur le problème Y, je le recherche mais j'ai peut-être besoin de conseils;
  4. Je suis bloqué parce que j'attends A, B et C.

Idéalement, vous souhaitez disposer d'informations relativement à jour sur ces statuts sans perturber la productivité réelle. Constant "Sommes-nous encore là?" est contre-productif, mais il se peut que vous puissiez faire quelque chose d’utile pour les États 2 à 4, vous devez donc vous informer à leur sujet.

Ce qui fonctionnera est une culture de "messagerie push", de préférence de manière automatisée. Vous n'aurez peut-être pas besoin de consulter le journal de commit complet, mais vous pouvez créer un "tableau de bord" où vous verrez le dernier commit ou le dernier ticket résolu (pour les bogues ou les fonctionnalités) de chaque membre de l'équipe. Pour le reste des situations, vous pouvez les envoyer par e-mail de manière proactive avec de telles mises à jour (espérons qu'elles sont plus rares que les commits) ou leur demander si vous ne constatez pas de progrès continus sur un tableau de bord, si vous avez un problème. accord interne que se coincer doit être soulevé (il se peut qu'une fonctionnalité ne soit pas nécessaire s'il s'avère que cela coûte 80 heures et non 8 heures), soit ils vous tiendront au courant, soit vous ennuierez.

Alternativement, vous pouvez créer une culture basée sur des rapports quotidiens tels que https://idonethis.com/ envoyés à l’ensemble de l’équipe, afin que les autres utilisateurs soient également sur la même page.

Peter est
la source
1
Nous avons (essayé d'utiliser) idonethis pendant environ 2 mois. Cela n'a pas fonctionné - car vous deviez prendre un moment pour aller ailleurs et pour mettre à jour votre statut, la plupart d'entre nous ont oublié qu'il existait
Izkata
J'utilise bien sûr nos systèmes de suivi des problèmes et de gestion du changement lors de la rédaction de rapports de milieu et d'année sur ce que je fais, et nous utilisons le "tableau de bord" de Jazz pour gérer les activités en tant que services et projets dans leur ensemble. Les réunions Scrum communiquent ce sur quoi nous travaillons en ce moment mais ne conservent pas un historique détaillé. Pour mon propre intérêt, j'ai également trouvé utile de créer ensemble un petit outil en ligne de commande qui me permet de créer rapidement une note horodatée d'une ligne. c'est utile pour enregistrer une activité et des détails difficiles à voir avec les autres systèmes.
keshlam
@ Izkata Je ressens la même chose à propos du logiciel de gestion du temps que j'utilise à mon emplacement actuel. J'ai finalement configuré un rappel pour qu'il se déclenche à 16h (les jours commençant tôt) et à 18h (les jours où je commence tard), tous les jours. rappelle-moi de mettre à jour le système. Jusqu'à présent, j'ai beaucoup moins oublié de mettre à jour le système. Cela vaut peut-être la peine d’envisager si vous souhaitez continuer à utiliser un tel système.
Scragar
5

Une alternative à certaines des autres réponses (axées sur la communication) est que les tâches de vos cartes de correspondance peuvent être divisées en éléments plus petits sur lesquels vous pourrez ensuite obtenir un retour plus tôt.

Avec des morceaux plus petits, l’équipe a l’impression d’ accomplir chaque jour quelque chose qui devrait se refléter dans le stand-up.

L'inconvénient est que ces cartes séparées vont probablement beaucoup s'appuyer l'une sur l'autre. Une équipe qui est capable de communiquer très facilement les uns avec les autres est bénéfique ici, ou les pièces peuvent ne pas se combiner aussi bien qu’elles le devraient. Vous devrez peut-être également retenir certaines cartes si vous devez faire certaines choses en premier.

Cela étant dit, les gens resteront bloqués ou découvriront qu'une tâche est beaucoup plus difficile que ce qu'ils ou vous attendaient de temps en temps. C'est pourquoi il est toujours utile de discuter ouvertement des problèmes dans le stand-up où d'autres peuvent donner des conseils sans juger la personne qui a des problèmes.

Pour répondre à la question de la micro-gestion, comme le soulignent certaines des autres réponses: même si les personnes accomplissent de petites tâches chaque jour, il leur faudra avoir une vision plus globale du travail accompli pour avoir une idée du travail réellement accompli par chaque personne, plutôt que de les juger par leurs réalisations quotidiennes.

Je suggère cela parce que je travaille sur une équipe de 8 personnes, où la communication est très facile et les gens très accessibles. On nous confie des tâches qui ne dureront jamais plus de deux jours. Parfois, ces tâches sont étroitement liées et nous devons nous tenir mutuellement au courant de la façon dont nous abordons notre propre travail. Nous sommes tous responsables de rendre compte de notre travail toutes les deux semaines à notre responsable.


Après avoir relu la question, je me rends compte que vous posez peut-être cette question en tant que membre de l'équipe, et non en tant que chef de file. Vous risquez donc de ne pas avoir le contrôle de vos tâches.

  1. Vous pouvez suggérer à votre chef de répartir les tâches plus
  2. Si votre travail est bloqué ou dépend du travail d'un autre membre de l'équipe, n'hésitez pas à le consulter et à prendre une autre tâche si vous en avez besoin.
Double double
la source
1
Diviser les choses en une hiérarchie d'éléments plus petits et suivre les dépendances entre eux est l'une des choses que Jazz / RTC fait bien.
keshlam
3

Tout d'abord, vous devez vous analyser en termes de temps et de compétences. Si vous êtes un technicien possédant une expérience pratique antérieure, les choses peuvent être différentes de celles dans lesquelles vous êtes simplement un responsable ( vous ne disposez pas de connaissances techniques approfondies sur ce sur quoi travaillent réellement vos développeurs) qui doivent simplement s'assurer que les délais sont respectés. .

Le point commun dans les deux cas est que vous devez être capable de faciliter votre équipe et de créer un sentiment de confiance. Vous ne jugez pas leur performance mais essayez d'être empathique et utile pour rendre leur expérience amusante et facile.

Supposons maintenant que vous n’êtes qu’un simple gestionnaire, comme je l’ai dit plus haut. Dans ce cas, même si un développeur est réellement confronté à un problème sérieux lié au développement, vous ne pourrez peut-être pas l’aider. Le problème peut prendre beaucoup de temps et nécessitera également une concentration. En outre, en supposant que le développeur est vraiment sincère dans son travail et paye à temps plein (même du temps supplémentaire) pour résoudre ce problème mais ne peut malheureusement pas le résoudre. Et dans une telle situation (lorsque vous n'êtes même pas en mesure de comprendre complètement le problème), vous continuez à poser des questions sur le problème en prenant les progrès tous les jours et même de manière informelle deux fois par jour. Le résultat serait une frustration extrême et une gêne pour le développeur. Que ce soit une application pour recueillir les progrès quotidiens ou sa réunion stand-up quotidienne, tous les deux peuvent être frustrants.

D'un autre côté, en gardant tous les autres facteurs identiques, supposez simplement que vous possédez de solides connaissances techniques et que vous avez déjà travaillé sur les mêmes technologies. Dans ce cas, il est très utile de suivre les progrès quotidiens ou d’organiser des réunions informelles. Les développeurs auront sûrement confiance en vous et en votre expertise et seront à l'aise pour discuter du grand défi auquel ils sont confrontés. Vous ferez des suggestions qui peuvent être utiles ou même si elles ne le sont pas directement, elles vous aideront à proposer des approches alternatives.

Toutefois, dans tous les cas, des réunions journalières avec stand-up doivent donner l'impression que vous êtes un membre de l'équipe et non un responsable / responsable / responsable. À moins que les membres de votre équipe ne vous considèrent au même niveau qu'ils ne le sont, ils ne pourront pas communiquer leurs préoccupations / suggestions / problèmes / réactions, etc.
Un autre point à prendre en comptecorrespond à la taille de votre équipe et au temps dont vous disposez pour les gérer, avant de penser à utiliser un logiciel de suivi de progression automatisé ou à augmenter votre interaction. Vous devez vous assurer que, quelles que soient les préoccupations exprimées par votre équipe, vous serez en mesure de les résoudre au plus vite. Un facteur démotivant majeur pour un membre de l'équipe est que ses préoccupations / suggestions / commentaires ne sont pas pris au sérieux ou ne sont pas valorisés. Il est important de connaître les progrès quotidiens, mais seulement si vous êtes pleinement impliqué dans le travail en équipe. Si vous êtes également impliqué dans certaines activités annexes, n'essayez pas d'interagir davantage avec votre équipe. Pensez à une situation dans laquelle la réponse de votre équipe est écrasante et qu'elle soumet ses tâches bien à l’avance, soulevant des préoccupations et des requêtes, mais vous ne pouvez pas fournir de commentaires et d’évaluations en temps voulu. Dans une telle situation,

arj
la source
2

Créez et utilisez les différentes salles de conversation par messagerie instantanée pour les différentes configurations. Certains peuvent être larges comme @engineers et d'autres peuvent être spécifiques comme @newFeatureA

Pensez à faire en sorte que chaque client fasse une évaluation quotidienne des billets d'avion.

Utilisez un environnement ouvert prenant en charge la collaboration et assurez-vous que QE et le propriétaire du produit principal sont placés au milieu des développeurs. Vous entendrez beaucoup de choses et vous aurez une idée en voyant des écrans autour de vous.

Comme Robert le fait remarquer, il ne faut surtout pas considérer la micro-gestion (notez l'utilisation de «soyez vu», c’est-à-dire quelle que soit votre intention réelle).

En fin de compte, nous suivons ce qui est accompli au fil du temps et voyons quelle est notre vitesse. Se concentrer sur les progrès de la journée est contre-productif car les gens vont devenir démoralisés et / ou partir.

Michael Durrant
la source
2

Je suis surpris que personne ici n'ait encore mentionné la messagerie de référentiel "suivi" ou "étoilé" intégrée à des systèmes tels que GitHub ou BitBucket.

Nos parties prenantes techniques (responsables de projets, responsables du développement et du support) suivent toutes notre problème et engagent des historiques de mise à jour de leurs projets respectifs. Nous avons une petite équipe (15 ETP + contractants), mais cela semble fonctionner pour nous

Personne n’est évalué sur ces points, mais en plus des rapports de situation hebdomadaires des chefs de projet, cela donne un aperçu quotidien du projet pour au moins informer tout le monde des domaines sur lesquels on travaille, afin que personne ne manque de visibilité.

Cela a également contribué à accroître la transparence entre les développeurs, les sous-traitants et nos liaisons commerciales, ce qui permet à tous de rendre compte de leurs calendriers de produits à livrer.

Combinés aux flux RSS associés à des référentiels spécifiques ou à l'ensemble de notre organisation, nous avons été en mesure de limiter les e-mails (là où ils étaient recherchés) et d'offrir un ensemble similaire de données en temps réel et sous forme de résumé via des lecteurs RSS. Pour certains utilisateurs, il s’agit d’Outlook; il s’agit donc en principe d’un courrier électronique, bien que légèrement différent, mais pour d’autres utilisateurs, ils utilisent un client RSS à part entière avec tout le filtrage supplémentaire dont ils ont besoin pour le personnaliser en fonction de leurs besoins.

Au début, nous avions des préoccupations similaires concernant le volume des e-mails, mais nos utilisateurs finaux ont mis au point le système RSS sans que l’organisation d’ingénierie n’ait à faire grand-chose, en plus de suggérer des clients à ceux qui n’utilisent pas Outlook. A travaillé pour nous, là encore environ 20 à 30 ETP + Entrepreneurs tout au long de l’année répartis dans plusieurs bureaux et fuseaux horaires YMMV, évidemment.

Bryan 'BJ' Hoffpauir Jr.
la source
4
Le PO signale qu’il suit les digests github et c’est accablant. D'après mon expérience, c'est une vision vraiment superficielle des choses qui donne un faux sentiment de sécurité.
Telastyn
2
C'est assez vrai si vous suivez toutes les activités sur GitHub. Pour être honnête, nous utilisons BitBucket pour notre société et elle semble offrir un contrôle suffisamment fin sur le niveau de mises à jour par e-mail pour nos équipes de petite taille. Vous ne savez pas si GitHub offre le même niveau de granularité, peut-être que quelqu'un pourrait le comparer à BitBucket si ils ont utilisé les deux pour aider à qualifier la configuration et la taille des équipes qui en font un bon ajustement? Le fait de ne suivre que des mises à jour dans GitHub génèrerait-il vraiment trop d’activité? Cela ne semble pas être dans BitBucket ... et c'est suffisant pour nos chefs de gouvernement et responsables
Bryan 'BJ' Hoffpauir Jr.
Ajout d'un commentaire sur les récents développements concernant l'utilisation de clients RSS (ou même Outlook dans certains cas) pour réduire le volume des e-mails et permettre aux utilisateurs d'auto-filtrer leurs données, tout en les conservant à la fois en temps réel et en tant que résumé / fin de journée / fin de la semaine comme ils veulent. Cela semble bien fonctionner pour ceux qui ne veulent pas qu'un flot constant de courriels soit ajouté à leur boîte de réception existante ...
Bryan 'BJ' Hoffpauir Jr.
0

C'est un ajout très marginal (et ce n'est pas spécifique au programme), mais j'ai eu beaucoup de succès avec Asana dans les projets récents.

Pour une intégration avec les outils de collaboration en ligne existants, ne cherchez pas plus loin que Slack . Il est construit autour d'un forum de discussion, mais il constitue un hub assez minimaliste pour d' autres outils, notamment Asana, GitHub et Bitbucket. Il possède une collection décente de ces "intégrations", à la fois prédéfinies et communautaires , en utilisant l'API qui vous permet bien sûr de créer la vôtre.

shadowtalker
la source
J'aimerais savoir pourquoi cela a été réduit. Je comprends la question qui concerne les "stratégies" plutôt que les "outils", mais "utiliser un bon outil" n'est-il pas en soi une stratégie viable?
shadowtalker
voir Comment répondre . « Lisez attentivement la question Qu'est - ce, en particulier, est la question demandant Assurez - vous que votre réponse prévoit que -.? Ou une alternative viable ... Brevity est acceptable, mais plus complètes explications sont mieux ... »
moucheron
Je suis venu ici pour suggérer d'utiliser Slack . C'est un excellent outil pour suivre ce que l'équipe fait au jour le jour . Ce qui, au fait, est exactement la question. Mais après avoir regardé cette réponse et les commentaires, je ne comprends peut-être pas comment fonctionne programmers.stackexchange.com (même si j'ai beaucoup de points de réputation sur d'autres sites).
Denilson Sá Maia
@gnat que voudriez-vous avoir de plus dans cette réponse? Je ne vois pas grand chose ici qui admette une explication "plus complète"
shadowtalker