Mon chef de projet n'accepte pas les reports dans Scrum - est-ce normal?

52

Je suis un développeur travaillant sur une nouvelle application mobile pour Android et iOS avec un gros composant backend. Nous avons participé à trois sprints de ce projet et nous utilisons Scrum dans toutes ses cérémonies (raffinement, planification, quotidiens, rétrospectives, etc.).

Dans deux des sprints, l’équipe a dû faire des heures supplémentaires et des week-ends (non rémunérés), car la direction était très inquiète de ne pas remplir l’engagement du sprint à temps. Tout le monde a travaillé dur, mais certaines dépendances externes et des estimations optimistes nous ont fait du mal à accomplir toutes les histoires de sprint.

D'après mon expérience, avoir un petit pourcentage d'histoires non terminées lors de certains sprints est quelque peu normal, et on peut les aborder dans le prochain. Mais notre chef de projet dit que c'est de notre faute puisque nous avons fait l'estimation nous-mêmes. Nous devrions donc compléter tous les éléments du sprint.

  1. Est-ce une variante acceptable / commune de Scrum dont je ne suis pas au courant?

  2. Comment suggérez-vous que je devrais agir à ce sujet?

MrAn3
la source
66
.. de plus, lorsque votre contrat de travail autorise des heures supplémentaires non rémunérées et des week-ends de travail et que vos supérieurs peuvent vous le demander de leur propre gré, je crains que le meilleur plan d'action soit d'ajouter une marge de sécurité d'au moins un facteur de 2 à chaque sprint eastimation, ou pour trouver un employeur différent.
Doc Brown le
59
Non, ce n'est pas une pratique acceptable depuis l'abolition de la galère romaine. Il s’agit d’une attaque de panique typique d’un chef de projet dont les compétences pourraient encore se développer. Tirer des coups de pied dans le cul en supposant qu’ils ne font pas ce qui est le mieux sans remettre en cause les estimations et la situation n’aidera pas à sortir de ce pétrin. Mais cette question est beaucoup trop vaste pour être discutée ici ...
Christophe
27
Demandez-vous quelle serait la vue de la direction si vous complétiez votre «engagement» de sprint à l'avance. L’équipe retirera-t-elle le reste du sprint (y compris son salaire)?
Qwerky
13
Un chef de projet n’est pas normal dans Scrum. Le Guide Scrum est assez explicite sur les rôles: Scrum Master, Propriétaire du produit, Scrum Team. Pas de PM mentionné. En fait, de nombreuses personnes (y compris la plupart des signataires du Manifeste Agile) ont à plusieurs reprises affirmé que les projets nuisaient à l’agilité. De plus, vous êtes le seul à décider que cela est acceptable. Si ce n'est pas acceptable pour vous, peaufinez votre CV et cherchez une meilleure entreprise.
Blueriver
5
Deux choses: les engagements sont pris par l’équipe, et non par le Premier ministre, alors engagez-vous à moins que la solution immédiate, mais le plus gros problème est ce qui se passe si vous ne livrez pas? Quelle est la conséquence? Généralement, les PM, les TPM, les Scrum Master, les propriétaires de produits, etc. sont encouragés à travailler avec l'équipe car… ils n'ont aucune autorité réelle sur l'équipe dans la structure matricielle à laquelle Agile / SCRUM se prête. Il ne s’agit donc peut-être que de @ essayer de faire avancer leur carrière aux dépens des autres.
RandomUs1r

Réponses:

75

Quelques choses se démarquent pour moi.

L’idée selon laquelle la direction a décidé que l’équipe s’engage dans un ensemble de travaux va à l’encontre des dernières versions du Scrum Guide. Le mot "commit" ou "engagement" n'est utilisé que deux fois dans la version la plus récente (novembre 2017) du Guide Scrum - une fois lorsque vous énumérez les valeurs Scrum et une autre pour indiquer que "les personnes s'engagent personnellement pour atteindre les objectifs de l'équipe Scrum. ".

L'idée de buts est importante pour Scrum. Non seulement les organisations et les équipes ont des objectifs généraux, mais dans Scrum, chaque sprint a un objectif de sprint défini dans Sprint Planning comme une collaboration entre le responsable produit et l'équipe de développement. L'objectif Sprint est atteint en mettant en œuvre des éléments du backlog de produits, mais il ne s'agit pas simplement de "terminer ce travail" et souvent, cela ne représente pas l'intégralité du backlog de sprint. En d’autres termes, vous devriez pouvoir atteindre l’objectif Sprint sans avoir rempli chaque élément de backlog de produit sélectionné pour le sprint ou chaque élément du backlog de sprint. Ma pensée actuelle est que le travail nécessaire pour atteindre l'objectif Sprint devrait se situer autour de 60 à 70% de la capacité de votre équipe, quelle que soit votre capacité. Différentes organisations seront différentes, cependant, mais

Les heures supplémentaires et les week-ends constituent également une pratique anti-agile en développement de logiciels. L'un des principes sous-jacents est que toutes les parties prenantes d'un effort sont capables de travailler à un rythme durable. Les journées et les week-ends prolongés, même s'ils étaient payés, ne sont pas viables pour une équipe.

À ce stade, il y a quelques prochaines étapes. L'équipe Scrum Master de l'équipe devrait éduquer la direction sur les valeurs et les principes du développement logiciel Scrum et Agile (tels que "l'engagement" et le "rythme durable"). L’équipe doit travailler sur sa capacité à prévoir les travaux et à en négocier la portée avec le responsable du produit. L’équipe doit également identifier les obstacles qui ont conduit à cette situation (éliminer ou réduire l’impact des dépendances externes) et s’attacher à les résoudre.

Thomas Owens
la source
2
Excellente réponse - vous pouvez même l'améliorer en soulignant ou en soulignant les points les plus importants: l'engagement ne peut venir que du développeur lui-même et le travail doit être durable
Falco
De plus, si vous avez des retards dus à la dépendance d’autres équipes, le temps pendant lequel vous êtes bloqué devrait être visible par votre équipe.
luizfzs le
2
Je crois qu'ils ont changé le libellé en 'prévision'; tout comme une prévision météorologique, elle peut être fausse, elle a des niveaux de certitude et les récits complétés lors d'un sprint aident l'équipe à améliorer ses estimations à l'avenir.
George Stocker le
1
@GeorgeStocker Oui - le mot "prévision" est utilisé au lieu de "commettre" en ce qui concerne le backlog de sprint et des tâches spécifiques. Cependant, "engager" et "engagement" sont utilisés par rapport aux objectifs de l'équipe.
Thomas Owens
1
et aussi oui, 9 femmes ne peuvent pas faire 1 bébé en 1 mois :)
Michael Durrant
33

La situation que vous décrivez, dans laquelle la direction demande à l’équipe de faire des heures supplémentaires pour terminer tous les récits planifiés, est l’une des raisons pour lesquelles la littérature Scrum a cessé d’utiliser le terme «engagement». Un véritable engagement ne peut être pris que lorsque toutes les incertitudes ont été levées, notamment sur les dépendances vis-à-vis des tiers, le volume de travail de chaque élément, le temps dont tout le monde disposera compte tenu de la maladie, etc.

L'une des idées de base de Scrum est que l'équipe travaille à un rythme soutenu, ce qui signifie essentiellement des heures normales de travail sans heures supplémentaires (rémunérées ou non). Cela signifie directement que vous ne rencontrez pas une variation acceptable de Scrum.

Ce que vous pouvez faire dépend de votre rôle.

Si vous êtes un développeur, le mieux que vous puissiez faire est

  • (collectivement, en tant qu'équipe de développement) refusent de "s'engager" sur plus de travail que vous n'êtes absolument certain de pouvoir livrer dans un sprint. Ce sera probablement beaucoup moins que ce que la direction vous demande de faire.
  • concentrez-vous sur la fin des travaux plutôt que sur de nouvelles tâches. Si vous constatez que certains travaux ne peuvent pas être terminés, indiquez-le le plus tôt possible pour que les plans puissent être ajustés.

Si vous êtes un Scrum master, vous pouvez véritablement prouver votre valeur en informant la direction de Scrum. Quelques points qui me caractérisent:

  • Comme indiqué dans le premier paragraphe, l'équipe ne prend pas d'engagement lors de la planification du sprint, mais donne une prévision du travail qu'elle s'attend à avoir terminé.
  • Même si l'équipe doit éviter d'avoir du travail inachevé à la fin d'un sprint, cette situation est presque inévitable au début d'un projet (ou après un changement de composition de l'équipe). La quantité de travail que l'équipe peut accomplir de manière réaliste lors d'un sprint ne peut être déterminée qu'en fonction des chiffres historiques des derniers sprints de l'équipe dans cette composition. Au début du projet, de tels personnages historiques n'existent tout simplement pas. Une équipe qui accomplit exactement les 3 premiers sprints est donc plus accidentelle qu'une bonne planification. Après environ 5 sprints à un rythme soutenu, il y a suffisamment de données pour avoir une idée raisonnable de la somme de travail que l'équipe peut terminer de manière réaliste dans un sprint.
Bart van Ingen Schenau
la source
Oui, et l’incertitude n’est levée que lorsque le projet est terminé :-)
Christophe
3
La plupart des gens sont très doués pour les prédictions. La seule exception concerne l'avenir.
Michael Durrant le
21

Votre PM n'a rien à faire avec votre mêlée.

Votre PM n'a pas à vous demander des heures supplémentaires non rémunérées.

La chose évidente à faire est d'estimer toutes les tâches de manière à pouvoir garantir qu'elles seront terminées à temps. Ensuite, vous devriez pouvoir aller au pub de la deuxième façon, car clairement si sous-estimer une tâche signifie que vous la terminez gratuitement, alors surestimer signifie que vous avez du temps sans travail.

gnasher729
la source
1
"Votre Premier ministre n'a rien à faire avec votre mêlée." Sous certaines méthodologies Agiles (DSDM), ils le font. Pure Scrum ne reconnaît même pas "Project Manager" comme un rôle existant.
nick012000
3
Si le contrat de travail stipule qu'il peut y avoir des heures supplémentaires non payées, le Premier ministre a sûrement une entreprise qui le demande. Et si l’équipe est terminée plus tôt que prévu, c’est encore une "erreur" de la part de l’équipe, il n’ya donc aucune raison d’être paresseux par la suite. Mieux vaut commencer à estimer le prochain sprint pour que les estimations ne soient pas aussi éloignées ^^ ). Je ne suis pas d'accord avec la façon dont la direction gère cela, mais vos arguments ne tiennent pas non plus (sauf que le premier ministre est impliqué dans Scrum, en fonction de certaines contraintes - en tant que partie prenante, il peut être impliqué, mais pas de la manière il est actuellement).
Frank Hopkins
L'autre réponse logique à l'obligation de s'engager dans des estimations est de prévoir du temps pour rechercher toutes les inconnues avant de pouvoir estimer la tâche réelle.
Robin Bennett le
Je n'ai jamais travaillé nulle part où Scrum / Agile fonctionne de la même manière, mais dans les grandes lignes, bien que le Premier ministre ne soit pas reconnu comme un rôle spécifique, il gère souvent le budget et les risques. Le corollaire de cela est tout à fait qu'ils n'ont un intérêt particulier dans la façon bien / mal le développement va et ils peuvent demander des heures supplémentaires non rémunérées mais dans un arrangement de bonne volonté. La façon dont cela est facilité au sein de l'équipe variera énormément d'un magasin à l'autre. Dans certains endroits, ils cèdent strictement au scrum master, dans d’autres ils participent au stand up (contrairement à la pratique courante).
Robbie Dee le
DSDM n’est pas une méthodologie agile, c’est une pile volumineuse de **** ********************** implication dans le processus.
gbjbaanb le
12

Il y a plusieurs aspects à cela, mais à un niveau élevé, oui, le Premier ministre voudra absolument comprendre clairement pourquoi le travail prévu n'a pas été achevé. Cependant, ceci devrait être évoqué (et résolu) dans la rétrospective. Du côté des développeurs, de nombreux facteurs peuvent contribuer aux échecs du sprint.

Quelques points à considérer:

Trop dans le sprint

Si vous vous engagez régulièrement dans trop de travail, les sprints échoueront. La vitesse du sprint doit être suivie dans le temps pour déterminer le nombre optimal de points (ou de jours).

Allocation de ressources

Assurez-vous que la planification du sprint prend correctement en compte les activités autres que le développement telles que les cérémonies, les vacances, la formation, l'administration, le soutien, etc., en supposant automatiquement que tout le monde se développe à chaque minute, chaque heure qu'il passe physiquement au bureau n'est tout simplement pas pratique et immédiatement. vous mettre sur le pied arrière dès le départ.

Estimation de la variation

Vous faites du raffinement, mais y a-t-il certaines sortes de tâches qui sont toujours surchargées? Celles-ci sont généralement dues à des exigences manquantes ou vagues. Si les exigences sont floues, l’histoire ne devrait même pas faire partie du sprint sans avoir été suffisamment peaufinée ou planifiée.

Rapidité

Si la vitesse est correctement suivie, le nombre réel d'histoires devrait devenir clair. Cela ne veut pas dire qu'ils seront toujours faits à temps, mais cela devrait rendre les choses beaucoup plus faciles.

Bonne volonté

Sur tout projet, la bonne volonté est limitée. Si vous travaillez constamment en dehors des heures de travail, le moral en souffrira et les développeurs en épuisement - ceci est un échec de la gestion de projet . Comme je l'ai déjà indiqué, assurez-vous que la planification des sprints ne planifie qu'un nombre réaliste d'étages en utilisant la vélocité et les pics pour vous aider tout au long du processus.

Pointes

Si un élément est mal raffiné ou simplement laineux, n'hésitez pas à mettre une pointe pour fournir une meilleure estimation pour les sprints ultérieurs. Oui, certaines personnes sont simplement mauvaises à l’évaluation mais la plupart du temps, les faits ne sont pas connus à ce jour. Idéalement, cela aurait dû être traité dans le raffinement ou repris tôt par le PO, mais parfois, il peut glisser dans un sprint. Les développeurs devraient avoir du mal à y parvenir, car ceux-ci peuvent facilement torpiller un sprint qui, autrement, se passe bien.

Robbie Dee
la source
2
Je ne suis pas sûr que "repousser de la PM" est le cadrage le plus utile. L’ensemble de l’équipe, dans son ensemble, devrait vouloir améliorer son processus - c’est le but de la rétrospective - et toutes les questions que vous avez identifiées sont d’excellentes choses à prendre en compte dans le cadre de cette discussion, mais je pense qu’il est très utile de penser "Comment l’équipe peut-elle contribuer à ce que les estimations fournies par les objectifs de sprint soient plus utiles à l’avenir?" plutôt qu'un chef de projet repoussant l'équipe pour ne pas accomplir ses tâches.
Zach Lipton
1
Je pense que vous allez au coeur du problème. Le Premier ministre doit évoquer cela de manière vitale pour comprendre pourquoi le projet est en retard, mais la raison numéro un sera "les estimations étaient fausses", quelle qu'en soit la raison. (et la raison n ° 1 pour cela serait que le Premier ministre n'aime pas les estimations élevées!)
Ewan
Pour moi, c'est clairement la meilleure réponse à ce jour. +1
angryITguy
Que diriez-vous que nous appelons «refoulement» (ce qui implique une approche potentiellement antagoniste) des "questions" qui me paraissent plus neutres et efficaces?
Michael Durrant le
1
@ MichaelDurrant et al. Très bien, j'ai modifié le libellé du premier paragraphe.
Robbie Dee
10

Non, ce n'est pas une forme reconnue d'Agile , pour une raison très importante: si vous vous engagez à tout fournir , vous ne faites pas Agile, vous faites Waterfall - et si vous pensez que vous faites Agile à la place. , vous faites probablement mal la cascade , à cela. Je suis sûr que vous avez entendu la vieille scie "bon, rapide, pas cher, choisissez-en deux", non? Avec le développement logiciel, cela ressemble plus à "toutes les fonctionnalités livrées, dans les délais, dans le budget, choisissez la première ou les deux autres". Waterfall choisit le premier et Agile choisit les deux autres.

Si vous voulez être agile, vous avez besoin de flexibilité pour supprimer des histoires du sprint que vous ne pouvez pas terminer à temps. Une façon possible de le faire est de demander à votre responsable de produit d'évaluer les récits en utilisant la hiérarchisation MoSCoW. Cela impliquerait de ne pas sélectionner plus de 60% des récits (en nombre total de points de scénario) comme éléments indispensables qui seront complétés, 20% comme les éléments à compléter avant la fin du projet et la sortie du produit Minimum Viable, 20% Peut-être que Haves peut être complété si vous avez le temps, et que tout ce qui dépasse le cadre de la version actuelle est Won't Haves. Il est également important de noter que, une fois combinés, les produits indispensables doivent avoir suffisamment de chair pour créer le produit minimal viable sans qu'il soit nécessaire d'inclure des articles des autres catégories.

Déterminer s'il faut ou non supprimer des éléments du carnet de commandes Sprint incombe au propriétaire du produit, une fois que l'équipe en a fait la demande. Tous les articles supprimés du carnet de commandes Sprint sont évalués par le propriétaire du produit, puis sont soit entièrement retirés du projet ou placés dans le carnet de commandes dans une position convenablement classée.

Dans ce cas, je suppose que votre responsable de produit est votre gestionnaire de projet, n'est-ce pas? Ce serait à lui de déterminer les tâches à abandonner. Il ne devrait donc certainement pas vous en vouloir, car ce serait son travail de laisser tomber ces tâches pour compenser cela, et il semble qu'il ne le fasse pas.

nick012000
la source
Partout où j'ai jamais vu Scrum utilisé, sa cascade.
gbjbaanb le
6

Il a raison, il ne devrait pas y avoir de report entre les sprints. Les équipes Scrum ayant un report entre sprints est un anti-motif et non pas quelque chose que Scrum canonique accepte comme résultat valide.

Mais son approche n'est pas bonne.

Pendant un sprint, l’équipe doit surveiller en permanence le travail effectué et s’ils peuvent garder leur engagement de planifier le sprint pour finir les histoires sélectionnées. Si l'équipe identifie qu'elle ne peut pas terminer toutes les histoires, elle doit rencontrer le bon de commande et sélectionner une histoire à supprimer du sprint. Ce faisant, chacun arrête de travailler sur l'histoire et s'attache à terminer les histoires restantes. Rappelez-vous: il est toujours préférable de terminer une histoire complètement que d'avoir deux histoires à moitié terminées.

Les problèmes de dépendances externes et d’estimations imprécises expliquent précisément pourquoi les rétrospectives existent. Pendant Retro, l’équipe doit réfléchir et identifier ces problèmes. Et l'équipe doit ensuite trouver et mettre en œuvre des solutions à ces problèmes. Les estimations peuvent être rendues plus précises en connaissant mieux le système et en ayant une expérience simple. Les dépendances externes sont plus difficiles, mais pas impossibles à corriger.

Votre PM ( que PM fait-il même dans une équipe Scrum? ) Ne devrait pas être autorisé par Scrum Master à vous obliger à finir toutes les histoires. Au lieu de cela, s'il s'est plaint, il devrait les garder pour la rétrospective. Et mieux encore, devrait faire partie de la résolution des problèmes qui empêchaient les histoires d’être terminées à temps.

Euphorique
la source
Je ne suis pas d'accord avec le commentaire "résultat non valide". Bien que le résultat ne soit pas souhaitable , les équipes Scrum doivent comprendre qu'il est parfaitement raisonnable que certaines histoires ne soient pas terminées de temps en temps. Cela ne devrait certainement pas être un résultat normal, si vous ne terminez pas plus d'une histoire, vous montrez que vous faites quelque chose de mal, mais dire que ce n'est pas toujours un résultat valable est un peu fort à mon avis. Je préférerais que les équipes choisissent un peu trop de travail à faire, mais pas assez.
Bryan Oakley le
5

Est-ce une variante acceptable / commune de Scrum dont je ne suis pas au courant?

Non . C'est complètement faux. Je pourrais peut - être sympathiser avec les heures supplémentaires rémunérées , si l'OP commettait l'erreur de divulguer les estimations comme des faits avant la fin du sprint, mais les heures supplémentaires non rémunérées sont complètement ridicules et me feraient chercher un autre emploi dès que possible.

Comment suggérez-vous que je devrais agir à ce sujet?

D'après mon expérience, les gens qui sont si nombreux dans le secteur ferroviaire n'écoutent pas les arguments logiques. La seule façon pour eux de voir à quel point c'est brisé est de montrer , pas de dire. Alors, la prochaine fois que vous estimez et commettez, engagez-vous pour le moins possible . Engagez-vous à finir un petit billet d’ici la fin du sprint. Un que vous pourriez faire en un jour. Voyez comment votre PM réagit. Ensuite, commencez une discussion à partir de là pour savoir à quoi sert le système et à quoi il devrait servir.

nvoigt
la source
upvoted, bien que la perspective des heures supplémentaires impayées puisse être raisonnable si le contrat est formulé de cette manière (et que la rémunération générale en tient compte, c'est-à-dire supérieure à la moyenne - ou s'il existe d'autres avantages).
Frank Hopkins
4

Généralement, au début du projet, lorsque nous décidons de la vélocité de l'équipe, nous optons pour un nombre conservateur (inférieur à la normale), compte tenu du fait qu'il s'agit d'une nouvelle équipe, il faudrait un peu de temps à l'équipe pour s'installer. , se comprennent, comprennent les exigences fonctionnelles et NFR, etc. En gros, après les premiers sprints, nous optimisons la vitesse de l’équipe et, bien entendu, la vitesse ne fera que s’améliorer à partir de ce point.

Il ne sert à rien d’engager une vitesse plus élevée au début et d’amener l’équipe à la réaliser.

Une autre chose est que, dans un scénario ponctuel, où il existe un engagement de livraison à ne pas manquer, les responsables de projet peuvent faire pression sur l'équipe pour qu'elle s'étire, travaille tard et pendant les week-ends. Mais alors cela doit être considéré comme une exception et non comme une norme de travail. Travailler de la sorte pourrait augmenter la vitesse à court terme, mais à long terme, ce serait contre-productif, car cela pourrait entraîner des problèmes de qualité du code, d'épuisement professionnel des équipes, une équipe malheureuse avec une faible motivation, etc.

Rajesh Nair
la source
1
Agréable! +1 Au risque de couper les cheveux en deux, vous ne "décidez" pas de vitesse, c’est juste quelque chose qui sort du lavis après plusieurs sprints, mais oui, avec le sprint 0 (ou quelle que soit votre numérotation) - vous empilez le tableau avec autant d'histoires que vous croyez réalisables.
Robbie Dee le
2

FAQ sur l'engagement

Ce comportement est-il normal?

Je ne suis pas sûr.

Est-ce surprenant?

Non. Certaines personnes comprendront toujours que «engagement» signifie que tout dans l'engagement doit être complété.

Est-ce que c'est une bonne idée?

Le développement agile a pour thème central la durabilité : travaillez seulement autant que vous le souhaitez, aussi longtemps que vous le pouvez, indéfiniment. C'est une idée sensée la plupart du temps. (Si votre direction n'accepte pas cela, ils ne doivent pas appeler leur organisation agile.)

Que devrions nous faire?

  • Expliquez que le contenu du sprint est basé sur une estimation . "Estimation" signifie que cela ne sera parfois que correct - et généralement erroné. Quand c'est faux, c'est parfois trop bas et parfois trop haut.
  • Expliquez qu'il est beaucoup plus facile de changer le comportement d'estimation que la vitesse de travail.
  • Expliquez que lorsque l’équipe est punie pour ses estimations trop élevées, elle ne fera qu’une estimation plus basse et la direction perdra beaucoup plus de progrès de cette manière que de pousser occasionnellement une partie du contenu d’un sprint à un autre.

La bonne chose est que: votre chef de projet saura déjà toutes ces choses et les reconnaîtra comme ayant raison. C'est seulement qu'à court terme, on peut préférer les ignorer.

Lutz Prechelt
la source
2

Je ne suis pas d'accord avec votre équipe de direction. Ils n'auraient pas dû vous faire travailler des heures supplémentaires pour terminer le sprint.

Cependant, l'idée que des engagements sont impossibles provient d'une incompréhension du développement logiciel. J'ai vu de nombreuses équipes essayer de prédire les histoires qu'elles peuvent terminer dans un sprint en fonction du nombre de points d'histoire qu'elles ont terminées lors des sprints précédents. Si cela était possible, le développement de logiciel serait linéaire, c'est-à-dire que si je travaille deux heures, je fais deux fois plus de travail qu'en une heure.

Le développement logiciel est créatif et n'est donc pas linéaire. Il est préférable pour l'équipe de dire aux dirigeants ce qu'ils peuvent faire dans un sprint, puis de raconter ces histoires. Si vous manquez constamment vos engagements, vous ne saviez pas du tout quelle était la portée de l'histoire ou votre propriétaire du produit vous incitait à en faire plus.

Dans le premier cas, vous devez vous assurer de bien comprendre la portée de l'histoire avant d'accepter de la prendre en charge. Si c'est le dernier cas, vous avez un problème de culture et il y a peu de choses à faire.

John Douma
la source