Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Feuilles de temps: Bon ou mauvais en Agilité?

Publié par Louis-Philippe Carignan le mardi 28 mai 2013 à 17:00

Cette question m’est souvent posée depuis que j’œuvre dans le domaine des technologies de l’information. Depuis que j’agis en tant que coach Agile, j’ai un certain devoir d’éduquer mes clients à propos de la nécessité de poursuivre avec le suivi des feuilles de temps lorsque je mentionne que c’est le travail qui reste à faire qui est important et non le travail effectué jusqu’à maintenant.

Ayant moi-même été sur des projets où remplir ma feuille de temps était une perte de temps (sans jeu de mots), je peux comprendre les frustrations de certains développeurs qui désirent garder le focus sur le travail pour satisfaire le client. D’un autre côté, je comprends aussi le fournisseur de services qui doit facturer son client pour les heures passées sur son projet. Et pour pouvoir facturer correctement, le département de la facturation doit demander aux développeurs le temps passé sur le projet du dit client.

J’ai donc creusé le sujet pour connaître les opinions de certains experts reconnus dans le domaine des technologies de l’information. Voyons voir ce que ces experts ont à dire à ce sujet.

La version de Scrum Inc

D’un côté du terrain, nous avons Scrum Inc, piloté par Jeff Sutherland, qui semble contre l’idée de comptabiliser les heures dans une feuille de temps lorsqu’on fait partie d’une équipe Scrum.

Sur leur bogue, les gens de Scrum Inc. ont trois billets où un préjugé très défavorable envers les feuilles de temps est exprimé.

Ces billets, étant publié sur plusieurs années, nous permettent de conclure que c’est une opinion que Sutherland et son équipe tiennent depuis longtemps. À la lecture de ces billets, voyons voir comment Scrum Inc. apporte plusieurs de l'eau au moulin en défaveur pour la tenue des feuilles de temps en mode Agile.

Le gros bon sens selon Scrum Inc.

Tout d’abord, les arguments « gros bon sens » de Scrum Inc. contre les feuilles de temps sont tous à fait réalistes bien qu’aucune donnée vient supporter ces énoncés :

  • they demotivate developers
  • 10-15% loss of productivity is the minimum
  • developers have to fake the time to fill them out properly
  • erroneous data is used for reporting and management makes bad decisions
  • customers are deceived
  • they have nothing to do with quality code production
  • they focus the whole organization on phony data instead of production

Si vous avez déjà été membre d'une équipe Agile où il était requis de remplir votre feuille de temps, vous partagez probablement l’un (ou plusieurs) de ces énoncés. Et pourtant, comme le dit si bien Scrum Inc. certaines entreprises semblent être déterminer à remplir les feuilles de temps même si cela n’apporte aucune valeur à l’organisation.

there is a psychological dependency so strong, it is as if they are on drugs.

Une façon « Lean » de rapporter le temps restant

Lors de son passage chez PatientKeeper en tant que CIO, Jeff Sutherland a mené un sondage auprès de ses équipes Scrum pour identifier la meilleure façon de remplir les feuilles de temps. Les réponses ont été contre-intuitive où l’équipe ne voulait même pas afficher explicitement le temps restant sur chaque tâche, ce qui est habituellement encouragé en Scrum. Cela les dérangeait de leur véritable travail à faire et leur estimé restait assez variable à cause du problème à résoudre. Ils sont donc arrivés à cette façon de faire très « Lean ». 

Time remaining to Sprint completion is all that is reported publicly and the team remains focused on what it takes to get "Done" at the end of the Sprint and does not even feel the questions asked relate to time reporting in any way.

L’équipe voulait donc la confiance des gestionnaires en échange de cette façon simpliste de rapporter les heures restantes. On utilisait le temps restant de l’itération pour informer les parties prenantes et l’équipe n’était pas perturbée par aucune donnée liée à propos du temps. Elle pouvait donc se concentrer à livrer de la valeur.

Livrer de la valeur

L’un des points majeurs de l’Agilité est de livrer de la valeur à son client. Contrairement à un gestion de projet traditionnelle où l’on essaie de respecter les trois pointes du triangle de fer (temps, budget, fonctionnalités), on cherche à maximiser la valeur d’affaires livrée au client lorsqu’on fonctionne en mode Agile. On encourage les équipes Agile à penser en terme de valeur d’affaires ainsi que le retour sur l’investissement que bénéficiera la clientèle en utilisant le logiciel. Regardons de plus prêt comment ce principe est employé dans les billets de Scrum Inc. lors de leur réflexion à propos de l’utilité des feuilles de temps:

One difficulty when estimating in hours is that time measures input, and Scrum is concerned about output.

Un peu plus loin dans ce même billet, on mentionne un exemple où une firme d’avocats a surfacturé un client pour une simple question de rentabilité.

If the lawyers had instead focused on the quality of their work (the output in this case) and not billable hours, the client, rather than suing them, would have gladly paid the bill.

On sent vraiment l’influence de livrer de la valeur lorsque l’auteur affirme à la fin de ce billet que : 

Business probably won’t improve until they start to focus on quality of outcome rather than quantity of input.

Pour Scrum Inc., j’en conclu que la nécessité de comptabiliser les heures travaillées est un dérangement dans la livraison de valeur pour le client. J'en déduis qu'il faut garder les équipes concentrées sur l’objectif d’affaires et les feuilles de temps n’ont pas leur place dans cet objectif.

La version de Joel Spolsky

De l’autre côté du terrain, Joel Spolsky a une toute autre vision face à la feuille de temps. Dans son billet Evidence Based Scheduling, Spolsky présente une technique mathématique pour prédire une date de livraison en se basant sur l’historique des tâches faites par l’équipe lors d’autres projets.

Spolsky propose de garder un historique des temps estimés et actuels passé sur chaque tâche. Avec le temps, le développeur pourra s’améliorer en regardant où sont les plus grands écarts entre ces deux valeurs. Il suggère l’emploi d’une machine de Monte Carlo pour générer des probabilités quant à la livraison d’une version. Il suggère aussi l’utilisation d'un logiciel que sa compagnie vend.

Sans aller dans les détails de la technique qui est quand même compliquée, on peut voir à la lecture de ce billet que Spolsky favorise les feuilles de temps pour permettre aux développeurs de s'améliorer.

Dans ce billet, je suis d’ailleurs surpris par le concept de vélocité proposé par l'auteur. Pour Spolsky, la vélocité est la division du temps estimé sur le temps actuellement passé sur cette tâche. Premièrement, une vélocité est basée sur une unité de temps (m/s, km/h, points/itération). En divisant du temps (estimé) par du temps (actuel), on se retrouve avec un ratio sans aucune unité. Je doute fortement de l’effort de réflexion que Spolsky a effectué pour arriver à ce concept.

Et bizarrement, Joel Spolsky partage la même prémisse que Scrum Inc. quant à livrer de la valeur.

You want to be spending your time on things that get the most bang for the buck.

Cependant, son approche est différente puisque pour lui, 

Realistic schedules are the key to creating good software.

On peut donc voir une approche ortogonale à celle de Scrum Inc. et pourtant, elle semble répondre au besoin de livrer de la valeur d'affaires au client.

La version de Jurgen Appelo

L’auteur du livre Management 3.0 et auteur du blogue noop.nl a déjà écrit un billet où il se prononce sur le sujet. En quelques lignes, Appelo se situe entre Scrum Inc. et Spolsky.

Il mitige la position de Scrum Inc. puisque selon lui, il est important de mesurer la profitabilité d’un projet et les feuilles de temps permettent de déterminer cette mesure. De l’autre côté, il est contre l’idée de Spolsky de suivre chaque tâche dans un projet puisque le client n’y gagne aucune valeur et qu’habituellement, ces projets sont à coût fixe.

Il en arrive donc à la conclusion qu’il se situe entre Scrum Inc. et Spolsky : 

  • So yes, you must track time in order to track project profitability.
  • And no, you should not track time in order to improve task estimability.

La version Louis-Philippe

Mon opinion est relativement semblable à celle de Jurgen Appelo. Dans mon jeune temps, je penchais du côté de Scrum Inc. mais avec l’expérience où certaines particularités m’ont fait grandir, j’emprunte certains arguments de Jurgen (mais aucun de Spolsky).

Pour ma part, je commencerais par identifier les personnes qui vont consommer les feuilles de temps.  Par exemple, si le responsable de la paie est la seule personne qui consomme les feuilles de temps produites par les équipes Scrum, je demanderais aux équipes de rentrer deux lignes dans leur feuille de temps : 

  • Heures passés au bureau
  • Heures où vous étiez absent du bureau

Par exemple, pour que la comptabilité effectue les bonnes paies à la fin du mois, je demanderais aux équipes de rentrer leurs absences dans la feuille de temps. Cela aiderait la comptabilité à générer les paies exactes et éviter des corrections à chaque mois. Si le reste du temps est passé sur un projet de recherche et développement, je simplifierais à sa plus simple expression les heures passés au bureau pour ne pas déranger l’équipe.

Je rejoins aussi Jurgen Appelo à propos de comptabiliser les heures pour la facturation. Je comprends le point de vue de Scrum Inc. à propos de livrer de la valeur affaires pour son client et « l’interférence » causée par l’inscription des heures sur la feuille de temps. En tant que développeur dans une équipe, j’ai un « autre » client, c’est-à-dire l’organisation qui paie mon salaire pour exécuter les services à mon vrai client. Pour me payer, l’organisation pour laquelle je travaille doit facturer un client avec qui elle est liée contractuellement. Je comprends qu’il peut y avoir de l’abus dans certains cas comme le remarque Scrum Inc. où l’important devient simplement de facturer des heures imaginaires. Je préfère donc faire abstraction de cette idée peu probable et emprunter l’argument de Jurgen.

Cependant, et bien que Joel Spolsky a eu du succès avec sa technique ainsi que les projets qu’il a lancé (StackExchange, Trello), je ne vois pas l’intérêt de compiler l’historique des tâches pour chaque développeur dans l’objectif d’apporter une meilleure prévisibilité. Étant un adepte des systèmes complexes adaptatifs où un projet logiciel est complexe et impossible à prévoir d’un bout à l’autre, je préconiserais une approche où l’on fait des temps d’arrêts fréquents pour regarder où nous sommes rendus et ajuster le tir. L’approche de Spolsky semble viser un certain déterminisme que je réfute lorsqu’on parle de développement logiciel.

100% Agile ... vraiment?

Publié par Louis-Philippe Carignan le vendredi 24 mai 2013 à 19:00

Je lisais dernièrement sur une présentation de Ken Schwaber à propos d'un sondage effectué par Forrester Research auprès de 205 organisations pour connaître leur utilisation de l’Agilité. Dans sa présentation, Ken questionnait, à la diapositive #11, ce que voulait dire ce 100%. Comment a-t-on réussi à mesurer que 20% de ces organisations étaient Agile à 100%?

Forrester Research

Mais un autre point a piqué ma curiosité dans cette présentation. À la diapositive #3, on y pose la question « Who Is Responsible For Creating More Agility? ». Bien que plusieurs corps de métier soient énumérés à la gauche, un encadré à la droite pointe vers les gestionnaires. J’ai trouvé cette réflexion intéressante puisque je trouve que beaucoup d'efforts a été déployé depuis les 10 dernières années à convaincre les équipes d'adopter l'Agilité. Mais maintenant que les professionnels en T.I ont fait ce changement, qu'en est-il de l'ouverture et la compréhension de la gouvernance face à la philosophie Agile?

Who Creates Agility

Je trouve que les deux personnes les plus en vue ces dernières années en Agilité sont Lyssa Adkins et Jurgen Appelo. Et ces deux personnes visent essentiellement le management dans leur message. Avec son livre « Coaching Agile Teams », Lyssa parle aux Scrum Masters, coach Agile et gestionnaires Agile pour les aider à adopter une nouvelle posture de gestion. Elle a fondé l’institut de coaching Agile avec Michael Spayd où elle offre une série de cours qui cible ces corps de métier, quelque chose qu’on ne retrouvait pas nécessairement il y a plusieurs années. Au Canada, on retrouve maintenant le Agile Coach Camp, un évènement annuel où les coach Agile peuvent se rencontrer.

Du côté de Jurgen Appelo, son livre « Management 3.0 » vise aussi les gestionnaires à s’adapter à la philosophie Agile. Tout comme Lyssa, il offre aussi des cours basés sur son livre. 

Dans son rapport « The Shift Index » en 2011, Deloitte mentionnait qu’on se dirigeait vers du Agile de deuxième génération. Je croyais au début que la méthode Kanban de David Anderson était le candidat potentiel pour cette deuxième génération d’approches Agile.

Mais avec l’apparition du Scaled Agile Framework (SAFe) de Dean Leffingwell, le Disciplined Agile Delivery (DAD) de Scott Ambler et le Path To Agility de Ken Schwaber, je me demande si la deuxième génération d’Agilité ne sera pas plutôt axée vers l'entreprise au grand complet. Ces trois "trucs"/"approches"/"framework" semblent voulour répondre à un besoin organisationnel pour devenir de plus en plus agile face aux changements constants de notre industrie.

En ce début de cette deuxième décennie portant sur l'Agilité, notre industrie ne semble pas se ré-inventer (pour l'instant) comme elle l'a si bien fait dans le passé. En attendant de voir ce qui va arriver avec la méthode Kanban, DAD, SAFe et Path To Agility, il sera intéressant de définir un jour ce que veut dire "être une organisation 100% Agile" et si cela peut mieux se mesurer que les résultats obtenus lors du sondage de Forrester.

Un retour au testing exploratoire

Publié par Louis-Philippe Carignan le jeudi 23 mai 2013 à 15:00

Dernièrement, j’ai revisité le testing exploratoire pour aider un collègue. Sur ce sujet, je me réfère souvent aux frères Bach (Jon et James) ainsi que Cem Kaner puisque je crois qu’ils sont les représentants les plus en vue de cette approche. Pour vous initier au testing exploratoire, je vous suggère cette vidéo de 4 minutes pour voir les différentes approches du testing exploratoire du gros bouton rouge « Bureau En Gros ».

 

 

Je considère le testing exploratoire comme un style de test important. Brian Marick, dans sa matrice des tests, leur réserve une place dans l'un des quadrants comme l’explique ce billet sur son blogue.

Testing Matrix

Pour revenir aux frères Bach, ils tiennent plusieurs vidéos à jour leur site satisfice.com. Il y a d’ailleurs quelques outils de tests dont mon préféré est le log watch. Cet utilitaire s'exécute en arrière-plan où il lit un fichier de log généré par le programme à tester. À chaque fois que cet utilitaire identifie une chaîne de caractères recherchée dans le fichier de log, l’utilitaire joue un .wav. On peut donc vaquer à nos occupations et être averti quand le message recherché survient.

J’avais assisté à une conférence de James Bach il y a plusieurs années où il avait démoli un programme par le testing exploratoire. Le programme était un kiosque à l’aéroport où l’on peut naviguer sur Internet en payant avec sa carte de crédit. Le seul programme accessible était le navigateur web. James a montré que l’option pour imprimer la page web courante était encore activée. Bien qu’il n’y avait pas d’imprimantes attachées au kiosque, cette option était toujours présente dans le menu.

Et puisque le système d’exploitation était Windows XP, on pouvait choisir l’imprimante par défaut qui est le XPS Document Writer.

XPSPrinter

Et que ce passe-t-il lorsqu’on appuie sur le bouton OK une fois cette imprimante sélectionnée? Et bien on accède au système de fichiers.

Win XPFile System 

Je vous laisse deviner la suite de sa présentation ;-) 

Lors de sa présentation, James avait mentionné comment un testeur se devait d’avoir un « boneyard » d’outils pour l’aider dans son travail. Pour simplifier vos recherches, je trouve que le site www.opensourcetesting.org contient une panoplie d’outils intéressant dont certains peuvent aider les testeurs à faire du testing exploratoire. Au cours de mon expérience professionnelle, les utilitaires de Mark Russinovich (ProcessExplorer, FileMon, Junction) m’ont été très profitable. Je vous encourage d’ailleurs fortement à lire son blogue une fois par mois ou d’acheter son livre « Windows Internals » si vous avez souvent à travailler "sous la couverte de Windows". Son blogue contient d'ailleurs des articles qui datent jusqu'à mars 2005

Tout ça pour rappeler que le testing exploratoire est un aspect important à considérer en développement logiciel. Malheureusement, je considère qu'il n’est pas assez souvent mentionné au détriment du TDD et du BDD. Bien que ces styles aient fait leur preuve pour identifier et éliminer un certain type de bogues dès leur apparition, le testing exploratoire vise un tout autre ensemble de bogues. Par expérience, je trouve qu’un bon testeur aura la mentalité pour mettre en pratique ce style de tests dans son travail, ce qui rendra la solution logiciel plus fiable aux yeux du client. 

Mots-Clés :

Une firme de service-conseils TI pas comme les autres

Publié par Louis-Philippe Carignan le mercredi 22 mai 2013 à 10:00

En avril 2012, Infoq.com a publié la liste des 20 personnes les plus influentes en Agilité. En 20ième position, on retrouve Henrick Kniberg, un suédois dont la biographie mérite d’être lue avant de continuer à lire ce billet. Il est aussi co-propriétaire de Crisp, une petite firme de consultants en technologie de l’information en Suède.

En mai 2010, Henrik a publié un billet à propos de Crisp où il raconte comment ils ont découvert leur identité. Pendant des années, il trouvait que leurs rencontres de compagnie biannuelles ne donnaient pas les résultats escomptés. 

"Every conference we would spend lots of effort around a big conference room table attempting to define these things, but the only results would be a bunch of wiki pages (our intranet) with lots of different options and ideas. No clear decisions."

Une année, Henrik a donc emprunté une approche différente pour identifier leur vision. Il a fait les étapes suivantes:

  • Découvrir leur vision et la mettre en mots.
  • Rendre la vision physique.
  • Dessiner avec des crayons de plomb puisque la vision n’est jamais finale.
  • Limiter l’espace pour se forcer à choisir les bons mots.
  • L’afficher partout.
  • Obtenir l’approbation de tous.

Comparativement à d’autres organisations qui font un exercice similaire, le résultat de cette expérience a fait son bout de chemin au travers le temps. Une fois leur identité découverte avec cette vision en dessins, des éléments intéressants en ont découlé. Voici ce qu’Henrik raconte sur son blogue

Indice du bonheur – version Crisp

Maintenant outillé avec leur vision sous forme de dessins, Crisp a mis sur pied l’indice du bonheur, une simple feuille de calcul sur Google Spreadsheet qui mesure, de 1 à 5, le niveau de bonheur de chaque personne à chaque mois.

On y trace un graphique mensuel où on fait la moyenne de cet indice. Si le graphique montre une courbe négative, les gens deviennent alors concernés et travaillent ensemble pour résoudre ce qui irritent leurs collègues.

HappinessGraph.jpg 

Voici le constat d’Henrik par rapport à cette mesure :

"Crisp Happiness Index is more important than any financial metric, not only because it visualizes the aspect that matters most to us, but also because it is a leading indicator, which makes us agile. Most financial metrics are trailing indicators, making it hard to react to change in time."

Leur indice du bonheur est un bon indicateur puisqu’il donne un aperçu de ce qui va se produire dans la compagnie. En étant heureux chez Crisp, les employés rendront heureux leurs clients. Henrik fait le constat que les indicateurs financiers sont en arrière (lagging) puisqu’ils donnent une lecture après qu’une prestation de service ait été faite chez un client.

La valeur des actions chez Crisp

Leur indice du bonheur a permis une autre prise de conscience aux employés de Crisp:

"As a result of understanding our own values better, we’ve dramatically changed our partnership contract between Crisp stock owners. We’ve literally made our own stock worthless (at least from a pure monetary perspective)"

Vous avez bien lu. Leurs actions ne valent plus rien sur le plan monétaire. Ils ne veulent pas être une firme pour enrichir les actionnaires. Ils veulent être une maison pour les consultants en technologie de l’information.

Il est d’ailleurs dommage qu’il n’explique pas en détails ce volet. Je serais curieux de connaître comment Crisp gère sa comptabilité, paie ses impôts ou si un partage de revenus annuel est fait.

Et leur plan pour gérer la croissance

En continuant la lecture de l’article, on apprend que pour eux, la croissance de l’entreprise n’est tout simplement pas un paramètre qu’ils désirent contrôler. Puisqu’ils s’identifient comme étant une maison pour consultants en TI, c’est plutôt leur indice du bonheur qui indiquer si leur croissance actuelle est plaisante (ou non). J'ai entendu plusieurs fois des gestionnaires expliqués comment la croissance était importante pour aller chercher de nouvelles opportunités d'affaires. Crisp a une vision tout à fait différente de la croissance. Elle n'est pas liée aux opportunités d'affaires mais à l'indice du bonheur de ses employés.   

En conclusion

Je vous invite à consulter les deux dessins qu’Henrik présente au début de son article. Il a traduit les mots en anglais pour faciliter notre compréhension. Le premier montre la maison des consultants avec les valeurs importantes à leurs yeux. Mais c’est le dessin à la deuxième page qui est plus révélateur à mon avis. L’image « What do we do with money? » est particulièrement intéressante ainsi que la mesure du bonheur à la gauche de la feuille. Si les employés sont heureux, leurs clients le seront tout autant.

Comme le dit si bien les Poppendieck dans leur troisième excellent livre « Leading Lean Software Development » à la page 198 à propos des entreprises dans l'économie du savoir :

"In knowledge work, success comes entirely from people and the system within which they work. Results are not the point. Developing the people and the system so that together they are capable of achieving successful results is the point."

La communication non-violente

Publié par Louis-Philippe Carignan le mercredi 24 avril 2013 à 15:50

Voici moi il y a quelques années: 

« Si tu n’écris pas tes tests avant ton code de production, ton code est à chier. »

J’entendais aussi cela des fois dans les équipes de développement sur lesquels j’étais assigné : 

« Tom est un mauvais programmeur » ou « Heille man, c’est à chier ce que tu fais »

Belle façon de communiquer non? Avec les années, cette façon de communiquer m’a mené plus d’une fois directement dans un mur. On m’a reproché à plusieurs reprises mon manque de tact et pour faire l’effort nécessaire afin de corriger ce défaut, j’ai découvert entre autre la communication non-violente

J’ai donc commencé à creuser le sujet pour apprendre à mieux communiquer sans blesser les autres. J’assistais aussi dernièrement à une réunion où les participants avaient reçu une formation sur ce sujet. Je pouvais voir que c’était difficile pour eux puisque c'était contre nature mais le message était mieux communiqué (à mon avis).  

En quelques lignes, la communication non-violente se décompose en trois parties :

  • Observations : Ce que j’observe ne contribue pas à mon bien-être.
  • Émotions : Comment je me sens face à ce que j’observe?
  • Besoins : Qu’est-ce que j’ai besoin pour me sentir mieux comme personne

Tout comme le fameux gabarit de la user story, on peut aussi se faire un gabarit pour la communication non-violente : 

« Quand je <observation>, je me sens <émotion> puisque j’ai <besoin>. ».

Une fois que ces trois étapes sont formulées en une phrase, on fait une requête à la personne et non une demande. Selon la communication non-violente, une demande est plutôt un ordre tandis qu’une requête peut-être refusée par l’autre. Je concède qu’en français, la nuance entre « demande » et « requête » n’est pas aussi claire qu’en anglais, langue dans laquelle la communication non-violente a été élaborée.

Remarquer aussi le « je » qui prédomine le gabarit ci-haut. La communication non-violente met l’accent sur le « je » puisqu’on y communique nos émotions, chose qui nous appartient. Je vous invite d’ailleurs à relire les exemples au début du billet. Le « tu » est présent tandis que le « je » est absent.

Après avoir pris connaissance de ce processus pour communiquer non-violemment, voici comment je réécrirais les phrases au début de mon billet.

  • Avant : Si tu n’écris pas tes tests avant ton code de production, ton code est à chier.
  • Après :
    • Approche #1 : J’ai peur pour la qualité de ton code si tu n’écris pas tes tests.
    • Approche #2 : Quand je ne vois pas de tests unitaires couvrir du code de production, j’éprouve un certain inconfort puisque je désire livrer de la qualité à mon client.
  • Avant : Tom est un mauvais programmeur.
  • Après
    • Approche #1 : Tom a livré 5 bogues dans l’itération.
    • Approche #2 : Quand je vois plusieurs bogues à la fin de l’itération, j’éprouve une certaine culpabilité envers le livrable puisque j’aime être fier de la qualité dans la livraison à la fin de l’itération.

En somme, je vous invite à vous documenter sur le sujet si vous désirez améliorer votre savoir-être. En technologie de l'information, on nous demande souvent d'améliorer notre savoir-faire mais pour communiquer ce savoir-faire à nos collègues, je pense qu'il faut aussi un savoir-être pour bien travailler en équipe. 

Mots-Clés :

Archive